linux-kernel - Re: [PATCH v2 1/2] dt-bindings: gpio: add SAMA5D2 PIOBU support

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: <2600b55c-f8fd-ab82-6372-a75f22e382f8@microchip.com>
Date:   Wed, 5 Dec 2018 11:06:35 +0000
From:   <Andrei.Stefanescu@...rochip.com>
To:     <robh@...nel.org>
CC:     <linus.walleij@...aro.org>, <gregkh@...uxfoundation.org>,
        <Nicolas.Ferre@...rochip.com>, <mark.rutland@....com>,
        <Ludovic.Desroches@...rochip.com>, <Cristian.Birsan@...rochip.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-gpio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: gpio: add SAMA5D2 PIOBU support

Hello Rob,

Thank you for your feedback.

I will add a bit of context regarding the secumod. The 
"atmel,sama5d2-secumod"
compatible string is not used for loading a driver. It is used by atmel 
securam
driver (drivers/misc/sram.c) which has access to secumod's registers via:

     syscon_regmap_lookup_by_compatible("atmel,sama5d2-secumod")

So the secumod exports multiple hardware functions, eg: the securam, the 
PIOBU
pins which can be used as GPIO pins.

My initial patch had the "microchip,sama5d2-piobu" compatible appended 
to the
secumod's compatible e.g.:

secumod@...40000 {
     compatible = "syscon", "microchip,sama5d2-piobu";
...

Taking into consideration Linus Walleij's advice I arrived to the current
version. I thought this was a good idea because it separates the secumod 
node
from the GPIO controller node. Please notice that securam node is already
separated from secumod node (it is a separate node in the device tree).

I have a few questions because I am not sure of the best approach:

1. Is it ok to have the GPIO controller as a child node?
2. I used simple-mfd because it was the only way I could think of in 
order to
    get the driver probed.
3. Should I add a register range? I thought that because the driver uses 
syscon
    it is not necessary to add the register range. Also, the register 
range would
    have been a subset of the secumod's register range.