Hi, I read the following GPIO description, but I don't understand the line with '##'. Are there some connection with the above paragraph? Thanks, .............................. Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler, and those accessors must be used instead of spinlock-safe accessors without the cansleep() name suffix. Other than the fact that these accessors might sleep, and will work on GPIOs that can't be accessed from hardIRQ handlers, these calls act the same as the spinlock-safe calls. ** IN ADDITION ** calls to setup and configure such GPIOs must be made from contexts which may sleep, since they may need to access the GPIO controller chip too: (These setup calls are usually made from board setup or driver probe/teardown code, so this is an easy constraint.) gpio_direction_input() gpio_direction_output() gpio_request() ## gpio_request_one() ## gpio_request_array() ## gpio_free_array() gpio_free() gpio_set_debounce()
What meaning of the line code with '##'?
Started by ●September 22, 2015
Reply by ●September 22, 20152015-09-22
On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote:> Hi, > > I read the following GPIO description, but I don't understand the line > with > '##'. Are there some connection with the above paragraph? > > > Thanks, > > > > > .............................. > Accessing such GPIOs requires a context which may sleep, for example a > threaded IRQ handler, and those accessors must be used instead of > spinlock-safe accessors without the cansleep() name suffix. > > Other than the fact that these accessors might sleep, and will work on > GPIOs that can't be accessed from hardIRQ handlers, these calls act the > same as the spinlock-safe calls. > > ** IN ADDITION ** calls to setup and configure such GPIOs must be made > from contexts which may sleep, since they may need to access the GPIO > controller chip too: (These setup calls are usually made from board > setup or driver probe/teardown code, so this is an easy constraint.) > > gpio_direction_input() gpio_direction_output() > gpio_request() > > ## gpio_request_one() > ## gpio_request_array() > ## gpio_free_array() > > gpio_free() gpio_set_debounce()What language? I don't think a double hash mark would compile in that context in regular ol' C or C++. (Inside a #define -- yes. Outside -- no.) -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 22, 20152015-09-22
On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote:> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: > > > Hi, > > > > I read the following GPIO description, but I don't understand the line > > with > > '##'. Are there some connection with the above paragraph? > > > > > > Thanks, > > > > > > > > > > .............................. > > Accessing such GPIOs requires a context which may sleep, for example a > > threaded IRQ handler, and those accessors must be used instead of > > spinlock-safe accessors without the cansleep() name suffix. > > > > Other than the fact that these accessors might sleep, and will work on > > GPIOs that can't be accessed from hardIRQ handlers, these calls act the > > same as the spinlock-safe calls. > > > > ** IN ADDITION ** calls to setup and configure such GPIOs must be made > > from contexts which may sleep, since they may need to access the GPIO > > controller chip too: (These setup calls are usually made from board > > setup or driver probe/teardown code, so this is an easy constraint.) > > > > gpio_direction_input() gpio_direction_output() > > gpio_request() > > > > ## gpio_request_one() > > ## gpio_request_array() > > ## gpio_free_array() > > > > gpio_free() gpio_set_debounce() > > What language? I don't think a double hash mark would compile in that > context in regular ol' C or C++. (Inside a #define -- yes. Outside -- > no.) > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.comIt is plain C, for a Linux device driver. I thought whether it was for comment out, but I don't know what connection with the above paragraph description. Thanks,
Reply by ●September 22, 20152015-09-22
On Tue, 22 Sep 2015 16:09:01 -0700, Robert Willy wrote:> On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote: >> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: >> >> > Hi, >> > >> > I read the following GPIO description, but I don't understand the >> > line with >> > '##'. Are there some connection with the above paragraph? >> > >> > >> > Thanks, >> > >> > >> > >> > >> > .............................. >> > Accessing such GPIOs requires a context which may sleep, for example >> > a threaded IRQ handler, and those accessors must be used instead of >> > spinlock-safe accessors without the cansleep() name suffix. >> > >> > Other than the fact that these accessors might sleep, and will work >> > on GPIOs that can't be accessed from hardIRQ handlers, these calls >> > act the same as the spinlock-safe calls. >> > >> > ** IN ADDITION ** calls to setup and configure such GPIOs must be >> > made >> > from contexts which may sleep, since they may need to access the GPIO >> > controller chip too: (These setup calls are usually made from board >> > setup or driver probe/teardown code, so this is an easy constraint.) >> > >> > gpio_direction_input() gpio_direction_output() >> > gpio_request() >> > >> > ## gpio_request_one() >> > ## gpio_request_array() >> > ## gpio_free_array() >> > >> > gpio_free() gpio_set_debounce() >> >> What language? I don't think a double hash mark would compile in that >> context in regular ol' C or C++. (Inside a #define -- yes. Outside -- >> no.) >> >> -- >> >> Tim Wescott Wescott Design Services http://www.wescottdesign.com > > It is plain C, for a Linux device driver. I thought whether it was for > comment > out, but I don't know what connection with the above paragraph > description. > Thanks,Hey wait a minute -- there's no semicolons, either. This looks like some scripting language, not C. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 22, 20152015-09-22
On Tue, 22 Sep 2015 16:09:01 -0700 (PDT), Robert Willy <rxjwg98@gmail.com> wrote:>On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote: >> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: >> >> > Hi, >> > >> > I read the following GPIO description, but I don't understand the line >> > with >> > '##'. Are there some connection with the above paragraph? >> > >> > >> > Thanks, >> > >> > >> > >> > >> > .............................. >> > Accessing such GPIOs requires a context which may sleep, for example a >> > threaded IRQ handler, and those accessors must be used instead of >> > spinlock-safe accessors without the cansleep() name suffix. >> > >> > Other than the fact that these accessors might sleep, and will work on >> > GPIOs that can't be accessed from hardIRQ handlers, these calls act the >> > same as the spinlock-safe calls. >> > >> > ** IN ADDITION ** calls to setup and configure such GPIOs must be made >> > from contexts which may sleep, since they may need to access the GPIO >> > controller chip too: (These setup calls are usually made from board >> > setup or driver probe/teardown code, so this is an easy constraint.) >> > >> > gpio_direction_input() gpio_direction_output() >> > gpio_request() >> > >> > ## gpio_request_one() >> > ## gpio_request_array() >> > ## gpio_free_array() >> > >> > gpio_free() gpio_set_debounce() >> >> What language? I don't think a double hash mark would compile in that >> context in regular ol' C or C++. (Inside a #define -- yes. Outside -- >> no.) >> > >It is plain C, for a Linux device driver. I thought whether it was for comment > out, but I don't know what connection with the above paragraph description.As Tim said, this may be inside a macro or something. In any event, we're not seeing something - note that the actual (apparent) function calls don't have a terminator. If those are macro invocations, they'd be OK, but for the token pasting operator to be valid, there would still need to be line continuations. Are you sure this is *exactly* the code, and all of the relevant context?
Reply by ●September 22, 20152015-09-22
On 23/09/2015 01:26, Robert Wessel wrote:> On Tue, 22 Sep 2015 16:09:01 -0700 (PDT), Robert Willy > <rxjwg98@gmail.com> wrote: > >> On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote: >>> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote:>> >> It is plain C, for a Linux device driver. I thought whether it was for comment >> out, but I don't know what connection with the above paragraph description. > > As Tim said, this may be inside a macro or something. In any event, > we're not seeing something - note that the actual (apparent) function > calls don't have a terminator. If those are macro invocations, they'd > be OK, but for the token pasting operator to be valid, there would > still need to be line continuations. > > Are you sure this is *exactly* the code, and all of the relevant > context? >Probably not C/C++, but ## is the C "token pasting" operator. # starts a comment in Python (and other languages).
Reply by ●September 23, 20152015-09-23
On Tuesday, September 22, 2015 at 8:41:27 PM UTC-4, Tim wrote:> On 23/09/2015 01:26, Robert Wessel wrote: > > On Tue, 22 Sep 2015 16:09:01 -0700 (PDT), Robert Willy > > <rgmail.com> wrote: > > > >> On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote: > >>> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: > > >> > >> It is plain C, for a Linux device driver. I thought whether it was for comment > >> out, but I don't know what connection with the above paragraph description. > > > > As Tim said, this may be inside a macro or something. In any event, > > we're not seeing something - note that the actual (apparent) function > > calls don't have a terminator. If those are macro invocations, they'd > > be OK, but for the token pasting operator to be valid, there would > > still need to be line continuations. > > > > Are you sure this is *exactly* the code, and all of the relevant > > context? > > > > Probably not C/C++, but ## is the C "token pasting" operator. # starts a > comment in Python (and other languages).I should give the link earlier, excuse me. It is an instruction on GPIO device driver on embedded Linux. https://www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt
Reply by ●September 23, 20152015-09-23
On 23/09/15 13:05, Robert Willy wrote:> On Tuesday, September 22, 2015 at 8:41:27 PM UTC-4, Tim wrote: >> On 23/09/2015 01:26, Robert Wessel wrote: >>> On Tue, 22 Sep 2015 16:09:01 -0700 (PDT), Robert Willy >>> <rgmail.com> wrote: >>> >>>> On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott wrote: >>>>> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: >> >>>> >>>> It is plain C, for a Linux device driver. I thought whether it was for comment >>>> out, but I don't know what connection with the above paragraph description. >>> >>> As Tim said, this may be inside a macro or something. In any event, >>> we're not seeing something - note that the actual (apparent) function >>> calls don't have a terminator. If those are macro invocations, they'd >>> be OK, but for the token pasting operator to be valid, there would >>> still need to be line continuations. >>> >>> Are you sure this is *exactly* the code, and all of the relevant >>> context? >>> >> >> Probably not C/C++, but ## is the C "token pasting" operator. # starts a >> comment in Python (and other languages). > > I should give the link earlier, excuse me. It is an instruction on GPIO device > driver on embedded Linux. > > https://www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt >That is a text file, containing a mixture of descriptions and code. You can, I think, assume that this part is just documentation - and that the ## lines are comments (# is a comment character in scripts and many languages).
Reply by ●September 23, 20152015-09-23
On Wed, 23 Sep 2015 13:45:02 +0200, David Brown wrote:> On 23/09/15 13:05, Robert Willy wrote: >> On Tuesday, September 22, 2015 at 8:41:27 PM UTC-4, Tim wrote: >>> On 23/09/2015 01:26, Robert Wessel wrote: >>>> On Tue, 22 Sep 2015 16:09:01 -0700 (PDT), Robert Willy <rgmail.com> >>>> wrote: >>>> >>>>> On Tuesday, September 22, 2015 at 5:13:22 PM UTC-4, Tim Wescott >>>>> wrote: >>>>>> On Tue, 22 Sep 2015 13:58:05 -0700, Robert Willy wrote: >>> >>> >>>>> It is plain C, for a Linux device driver. I thought whether it was >>>>> for comment out, but I don't know what connection with the above >>>>> paragraph description. >>>> >>>> As Tim said, this may be inside a macro or something. In any event, >>>> we're not seeing something - note that the actual (apparent) function >>>> calls don't have a terminator. If those are macro invocations, >>>> they'd be OK, but for the token pasting operator to be valid, there >>>> would still need to be line continuations. >>>> >>>> Are you sure this is *exactly* the code, and all of the relevant >>>> context? >>>> >>>> >>> Probably not C/C++, but ## is the C "token pasting" operator. # starts >>> a comment in Python (and other languages). >> >> I should give the link earlier, excuse me. It is an instruction on GPIO >> device driver on embedded Linux. >> >> https://www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt >> >> > That is a text file, containing a mixture of descriptions and code. You > can, I think, assume that this part is just documentation - and that the > ## lines are comments (# is a comment character in scripts and many > languages).Indeed. If it's just stuff interspersed in a web page, then you can't assume that you can just cut it and paste it into a program file and have it work. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
