On 2017-05-18 19:43, Andy Shevchenko wrote:
> On Thu, May 18, 2017 at 5:59 PM, Jan Kiszka <jan.kis...@siemens.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
