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] [day] [month] [year] [list]
Date:   Mon, 11 May 2020 23:02:30 +0300
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Santosh Shilimkar <ssantosh@...nel.org>,
        Tero Kristo <t-kristo@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Lokesh Vutla <lokeshvutla@...com>,
        DTML <devicetree@...r.kernel.org>,
        Dave Gerlach <d-gerlach@...com>, Sekhar Nori <nsekhar@...com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nishanth Menon <nm@...com>
Subject: Re: [PATCH v3 2/2] soc: ti: add k3 platforms chipid module driver

Hi Arnd,

On 11/05/2020 15:43, Arnd Bergmann wrote:
> On Mon, May 11, 2020 at 1:11 PM Grygorii Strashko
> <grygorii.strashko@...com> wrote:
>>
>> Hi Arnd,
>>
>> On 09/05/2020 01:17, Arnd Bergmann wrote:
>>> On Fri, May 8, 2020 at 12:01 PM Grygorii Strashko
>>> <grygorii.strashko@...com> wrote:
>>>
>>>> +static int __init k3_chipinfo_init(void)
>>>> +{
>>>> +       struct soc_device_attribute *soc_dev_attr;
>>>> +       struct soc_device *soc_dev;
>>>> +       struct device_node *node;
>>>> +       struct regmap *regmap;
>>>> +       u32 partno_id;
>>>> +       u32 variant;
>>>> +       u32 jtag_id;
>>>> +       u32 mfg;
>>>> +       int ret;
>>>> +
>>>> +       node = of_find_compatible_node(NULL, NULL, "ti,am654-chipid");
>>>> +       if (!node)
>>>> +               return -ENODEV;
>>>
>>> This will fail the initcall and print a warning when the kernel runs on any
>>> other SoC. Would it be possible to just make this a platform_driver?
>>>
>>> If not, I think you should silently return success when the device
>>> node is absent.
>>
>> Thank you for your report.
>> Can' make it platform drv., as the SoC info need to be accessible by divers early.
> 
> Which drivers in particular? In most cases you should be able to still do this
> right by relying on initcall ordering as long as this one can only be built-in
> (or possibly only a module for compile-testing).

Thanks for you review.

As I'm aware of right now, it's going to be: ringacc, dma, net drv and mmc.
So, It seems should work with platform_driver and subsys_initcall.
I'll try it.

-- 
Best regards,
grygorii

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ