[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a31329e-ca83-84de-7958-4c795c2ccda6@amazon.com>
Date: Thu, 15 Dec 2022 16:25:24 +0200
From: "Hawa, Hanna" <hhhawa@...zon.com>
To: Linus Walleij <linus.walleij@...aro.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: Wolfram Sang <wsa@...nel.org>, <jarkko.nikula@...ux.intel.com>,
<mika.westerberg@...ux.intel.com>, <jsd@...ihalf.com>,
<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<dwmw@...zon.co.uk>, <benh@...zon.com>, <ronenk@...zon.com>,
<talel@...zon.com>, <jonnyc@...zon.com>, <hanochu@...zon.com>,
<farbere@...zon.com>, <itamark@...zon.com>
Subject: Re: [PATCH v2 1/1] i2c: designware: set pinctrl recovery information from
device pinctrl
On 12/15/2022 4:06 PM, Linus Walleij wrote:
>> Getter with a stub sounds better to me, so you won't access some device core
>> fields.
>>
>> Linus, what do you think about all these (including previous paragraph)?
> A getter may be a good solution, it depends, it can also be pushed
> somewhere local in the designware i2c driver can it not?
> I am thinking that the rest of the code that is using that field is
> certainly not going to work without pinctrl either.
the compilation failure occurs on platform which not define the
CONFIG_PINCTRL , most of the pinctrl APIs are wrapped with PINCTRL
config, for example pinctrl_select_state() or devm_pinctrl_get().
In addition if we add the getter in pinctrl/devinfo.h other drivers may
access the pins field without re-call devm_pinctrl_get().
Thanks,
Hanna
Powered by blists - more mailing lists