Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: YtuHFa1QpFSXBc+dZh1+nU+AF2kEbGLOJCzU4D9wWqKOWGwdy2kKJeKhaUvBE/nWp6Lxi7AB7S
 glcaBnzp7YGKjtTMNzsf7Qbdo7DcxO8/zgO6rlpErrgmRyZBrTPCPuUN7hD1oJq32G3CMpXvuM
 htF99qq0OnnssBHQvCCWZD9QNpU97pImoWB9kx3Dq6Qhqr3ntwooTEGIe+qCAS1TJ3JD/gZFM1
 bh/nOhzjOEZF40b4L+D71SLAVqVhRwi3JZ4F6BjHau04HqntQ/lGuFJIqiyt/hWjL64ausEQUk
 Sok=
From:   <Codrin.Ciubotariu@microchip.com>
To:     <wsa@the-dreams.de>
CC:     <linux-gpio@vger.kernel.org>, <linux-i2c@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <Ludovic.Desroches@microchip.com>,
        <Nicolas.Ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
        <kamel.bouhara@bootlin.com>, <linux@armlinux.org.uk>,
        <linus.walleij@linaro.org>, <alan@softiron.com>
Subject: Re: Re: Re: [RFC PATCH] i2c: at91: Fix pinmux after devm_gpiod_get()
 for bus recovery
Thread-Topic: Re: Re: [RFC PATCH] i2c: at91: Fix pinmux after devm_gpiod_get()
 for bus recovery
Thread-Index: AQHWEvR+GtAbavRk40KvRq7DN8dZF6iZuWYAgAxN9wCAC1nQAIAfHzQA
Date:   Tue, 9 Jun 2020 11:43:10 +0000
Message-ID: <e08c1cb7-351a-8874-44fc-2e44752b170f@microchip.com>
References: <20200415070643.23663-1-codrin.ciubotariu@microchip.com>
 <20200505151256.GF2468@ninjato>
 <c7a35978-03dd-3c73-6e7d-15ed40b5c57c@microchip.com>
 <20200520162724.GG5759@ninjato>
In-Reply-To: <20200520162724.GG5759@ninjato>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2E64A4B358CB5D4492DD10456E9F8B8A@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d939d02-5617-459a-fa30-08d80c6a48eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 11:43:10.0407
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: r2ZkjbgETA6/oPc8xhVPJnXHKvQPsCsZu0jMsNz4D9jCgQLQTh30NdcEZIzfUTRqngv7IbA/Q1U5p7YaqeZ2F1t6KhNVmcG75YoQgOi70sE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1287
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 20.05.2020 19:27, Wolfram Sang wrote:
>=20
>>> 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 th=
e
>>> 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...
>=20
> 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.
>=20
> I haven't started yet, let's keep in touch who started first :)
>=20

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

Thanks and best regards,
Codrin