linux-kernel - Re: [PATCH v2] i2c: designware: add support for pinctrl for recovery

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: <49384d62-7c5c-41d7-bbbd-b9aee5d1d0a3@linux.intel.com>
Date:   Fri, 18 Aug 2023 16:51:57 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     Yann Sionneau <yann@...nneau.net>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jan Dabros <jsd@...ihalf.com>,
        Andi Shyti <andi.shyti@...nel.org>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        Yann Sionneau <ysionneau@...ray.eu>
Subject: Re: [PATCH v2] i2c: designware: add support for pinctrl for recovery

On 8/17/23 17:27, Yann Sionneau wrote:
> Hi
> 
> Le 17/08/2023 à 10:07, Jarkko Nikula a écrit :
>> Hi
>>
>> On 8/16/23 12:50, Yann Sionneau wrote:
>>> From: Yann Sionneau <ysionneau@...ray.eu>
>>>
>>> Currently if the SoC needs pinctrl to switch the SCL and SDA
>>> from the I2C function to GPIO function, the recovery won't work.
>>>
>>> scl-gpio = <>;
>>> sda-gpio = <>;
>>>
>>> Are not enough for some SoCs to have a working recovery.
>>> Some need:
>>>
>>> scl-gpio = <>;
>>> sda-gpio = <>;
>>> pinctrl-names = "default", "recovery";
>>> pinctrl-0 = <&i2c_pins_hw>;
>>> pinctrl-1 = <&i2c_pins_gpio>;
>>>
>>> The driver was not filling rinfo->pinctrl with the device node
>>> pinctrl data which is needed by generic recovery code.
>>>
>>> Tested-by: Yann Sionneau <ysionneau@...ray.eu>
>>> Signed-off-by: Yann Sionneau <ysionneau@...ray.eu>
>>
>> Tested-by from author is needless. Expectation is that author has 
>> tested the patch while not always true :-)
> Ok, I just wanted to emphasize the fact that I have the device and I 
> tested the change with the device. Ack!
>>
>>> @@ -905,6 +906,15 @@ static int i2c_dw_init_recovery_info(struct 
>>> dw_i2c_dev *dev)
>>>           return PTR_ERR(gpio);
>>>       rinfo->sda_gpiod = gpio;
>>>   +    rinfo->pinctrl = devm_pinctrl_get(dev->dev);
>>> +    if (IS_ERR(rinfo->pinctrl)) {
>>> +        if (PTR_ERR(rinfo->pinctrl) == -EPROBE_DEFER)
>>> +            return PTR_ERR(rinfo->pinctrl);
>>> +
>>> +        rinfo->pinctrl = NULL;
>>> +        dev_info(dev->dev, "can't get pinctrl, bus recovery might 
>>> not work\n");
>>
>> I think dev_dbg() suits better here or is it needed at all? End user 
>> may not be able to do anything when sees this in dmesg. I.e. more like 
>> development time dev_dbg() information.
> I agree dev_dbg() is a better idea.
>>
>> Does i2c-core-base.c: i2c_gpio_init_pinctrl_recovery() already do 
>> dev_info() print when pinctrl & GPIO are set properly making above 
>> also kind of needless?
> 
> Thanks for the review. In fact I had to use gdb to understand why the 
> recovery was not working. Because as you said, it only prints something 
> to say "everything looks ok!".
> 
> I kind of prefer when it prints when something goes wrong.
> 
> But I let you decide what you think is the best.
> 
Fair enough, dev_dbg() is justified when it makes developer's life 
easier :-)