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: <efabae13-9018-1570-8daf-4401fa146441@linaro.org>
Date:   Tue, 14 Feb 2023 10:32:48 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Ryan Chen <ryan_chen@...eedtech.com>, Jeremy Kerr <jk@...abs.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] i2c: aspeed: support ast2600 i2c new register mode
 driver

On 14/02/2023 09:57, Ryan Chen wrote:
> Hello Krzysztof,
> 
>>
>> On 14/02/2023 07:12, Ryan Chen wrote:
>>> Hello Krzysztof,
>>>>
>>>>> On 02/02/2023 10:16, Ryan Chen wrote:
>>>>>>>>> +static struct platform_driver ast2600_i2c_global_driver = {
>>>>>>>> +       .probe  = ast2600_i2c_global_probe,
>>>>>>>> +       .driver = {
>>>>>>>> +               .name = KBUILD_MODNAME,
>>>>>>>> +               .of_match_table =
>>>> ast2600_i2c_global_of_match,
>>>>>>>> +       },
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static int __init ast2600_i2c_global_init(void) {
>>>>>>>> +       return
>>>>>>>> +platform_driver_register(&ast2600_i2c_global_driver);
>>>>>>>> +}
>>>>>>>> +device_initcall(ast2600_i2c_global_init);
>>>>>>>
>>>>>>> Maybe module_platform_driver() instead?
>>>>>>
>>>>>> Due to i2c global is top of all i2c bus like the scu, it make sure
>>>>>> the driver is
>>>>> before the i2c bus driver probe.
>>>>>> It is needed use device_initcal function.
>>>>>
>>>>> No, we do not do such ordering. device links and proper resource
>>>>> sharing handle the order. This must be module_platform_driver()
>>>>> (assuming we do not drop entire submission).
>>>>
>>>>
>>>> If global driver use module_platform_driver, does i2c driver will
>>>> latter the global driver probe?
>>>> If yes, I think it will workable.
>>>>>
>>> I find a good way instead.
>>> subsys_initcall(ast2600_i2c_global_init); is better ?
>>
>> Not really, this is not a subsystem. This is module platform driver so use it.
>>
> But, I need i2c-global to be early then i2c-ast2600 driver. The subsys_initcall is needed.
> I2c-global driver to initial full i2c clock and reset, after this, i2c bus driver(i2c-ast2600.c) can work. 

I wrote already what gives you the proper ordering. Why they do not or
cannot work here?

> So I suggest to use subsys_initcall in i2c global driver. Is it ok?

So for the third time - no. I gave reason what is the proper solution.
Manual ordering of drivers is error prone, not portable, easy to break
and actually does not work later when the platform grows.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ