linux-kernel - Re: [PATCH] gpio: Add device driver for GRGPIO cores

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <510F6CF8.3000700@gaisler.com>
Date:	Mon, 04 Feb 2013 09:10:32 +0100
From:	Andreas Larsson <andreas@...sler.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	linux-kernel@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	software@...sler.com
Subject: Re: [PATCH] gpio: Add device driver for GRGPIO cores

On 2013-02-02 16:16, Linus Walleij wrote:
>> +#if defined(__BIG_ENDIAN)
>> +static inline u32 grgpio_read_reg(u32 __iomem *reg)
>> +{
>> +       return ioread32be(reg);
>> +}
>> +
>> +static inline void grgpio_write_reg(u32 __iomem *reg, u32 val)
>> +{
>> +       iowrite32be(val, reg);
>> +}
>> +#else
>> [...]
>
> Where is this __BIG_ENDIAN flag coming from?
>
> And do you really have and test this regularly on both LE and BE hardware?
> I am worrying a bit about maintenance...

I am more than happy to drop that. I will most probably never test this 
on LE hardware.

>> +static void grgpio_set_sbit(struct grgpio_priv *priv, u32 __iomem *reg,
>> +                          unsigned offset, int val, u32 *shadow)
>> +{
>> +       unsigned long flags;
>> +
>> +       spin_lock_irqsave(&priv->lock, flags);
>> +
>> +       if (val)
>> +               *shadow |= (1 << offset);
>> +       else
>> +               *shadow &= ~(1 << offset);
>> +       grgpio_write_reg(reg, *shadow);
>> +
>> +       spin_unlock_irqrestore(&priv->lock, flags);
>> +}
>
> This is all very basic stuff. Please make a best effort to reuse or
> augment and reuse this:
> drivers/gpio/gpio-generic.c
>
> IIRC this one also handles endianness issues, but I could be wrong.

Sure, many of the initial functions do small basic tasks and resembles 
functions in gpio-generic. But that does not make the hardware itself a 
good candidate to use gpio-generic IMHO:

1) This core is generally running on SPARC, that is BE, but even on 
SPARC, readl and writel (that would be used in gprio-generic) deals with 
LE accesses and my registers are BE.

2) The grgpio_to_irq function is very hardware specific, and there is of 
course no gpio_to_irq support in gpio-generic.

3) Running on SPARC, I get Open Firmware information from prom, so there 
is no platform data to access in the probe function. Of course general 
Open Firmware support could be added to gpio-generic, but in addition my 
probe needs to set up very hardware specific things for gpio_to_irq.

Thank you for the feedback!

Cheers,
Andreas Larsson

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/