linux-kernel - Re: Re: Re: [RFC PATCH] i2c: at91: Fix pinmux after devm_gpiod

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 9 Jun 2020 11:43:10 +0000
From:   <Codrin.Ciubotariu@...rochip.com>
To:     <wsa@...-dreams.de>
CC:     <linux-gpio@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <Ludovic.Desroches@...rochip.com>,
        <Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <kamel.bouhara@...tlin.com>, <linux@...linux.org.uk>,
        <linus.walleij@...aro.org>, <alan@...tiron.com>
Subject: Re: Re: Re: [RFC PATCH] i2c: at91: Fix pinmux after devm_gpiod_get()
 for bus recovery

On 20.05.2020 19:27, Wolfram Sang wrote:
> 
>>> This will do for 5.7. For 5.8 or 5.9, I can imagine to take the two
>>> pinctrl_state pointers into bus_recovery_info and handle all this in the
>>> core. I will try this later this week if noone is super-eager to try it
>>> out before.
>>>
>>
>> By 'all this' you mean to move the entire function in the core, right?
>> Having just these two pointers bus_recinovery_info won't help much. I
>> can try it, if you haven't already started...
> 
> I mean to add those two pointers to bus_recinovery_info and if they are
> populated, then the I2C core is doing the necessary magic (or maybe just
> the pinctrl handle and assume the states have fixed names?). Russell
> just sent patches to add it to the PXA driver, so we could now double
> check how much could be factored out.
> 
> I haven't started yet, let's keep in touch who started first :)
> 

I started working at this. I added the pinctrl state initialization at 
the beginning of the i2c_init_recovery(). Due to the pinmux state issue 
with the GPIOs, the GPIO part needs to be also moved. The problem I ran 
in to now is the fact that, even if we can ignore if the GPIOs are not 
available, we should at least treat EPROBE_DEFER error. To do this, the 
I2C bus drivers should take into account the fact that 
i2c_register_adapter() can return -EPROBE_DEFER. Is this something to 
consider?

Thanks and best regards,
Codrin