[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83279eaf-69aa-333c-58b8-202d221375d3@siemens.com>
Date: Sun, 21 May 2017 13:43:13 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Walleij <linus.walleij@...aro.org>,
Alexandre Courbot <gnurou@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>,
Sascha Weisenberger <sascha.weisenberger@...mens.com>
Subject: Re: [PATCH v2 5/6] gpio-exar/8250-exar: Make set of exported GPIOs
configurable
On 2017-05-18 19:43, Andy Shevchenko wrote:
> On Thu, May 18, 2017 at 5:59 PM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>> On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
>> rest is required to operate the UART. To allow modeling this case,
>> expand the platform device data structure to specify a (consecutive) pin
>> subset for exporting by the gpio-exar driver.
>
>> + unsigned int first_gpio;
>
> Perhaps pin?
> Or shift?
>
> Because first_gpio a bit confusing with Linux side of GPIO.
Ack, going for "pin".
>
>> - unsigned int bank = offset / 8;
>> - unsigned int addr;
>> + struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
>> + unsigned int bank, addr;
>>
>> + offset += exar_gpio->first_gpio;
>> + bank = offset / 8;
>
> Can't we instead do something like the following:
>
> struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> unsigned int bank = (offset + exar_gpio->pin) / 8;
> unsigned int line = (offset + exar_gpio->pin) % 8;
>
OK, I'm using this pattern now:
unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
unsigned int bit = (offset + exar_gpio->first_pin) % 8;
>
>> + pdata.first_gpio = first_gpio;
>> + pdata.ngpio = ngpio;
>
> Still thinking about device properties ("ngpios" and something like
> "exar8250,gpio-start").
Changed back to properties, removing all platform data.
But what's the purpose of prefixing the name here? This does not have
anything to do with device trees. It's a private parameter channel
between the creating device driver and the gpio driver, and there will
be no other bindings.
>
>> + unsigned int first_gpio;
>> + unsigned int ngpio;
>
> u16 ?
>
If we do that, then we would rather have to choose u8. But this is
pointless restriction. I prefer to stay with the native type.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Powered by blists - more mailing lists