linux-kernel - Re: [PATCH v2] mfd: tqmx86: IO controller with i2c, wachdog and gpio

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: <20181221212831.GF5023@lunn.ch>
Date:   Fri, 21 Dec 2018 22:28:31 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mfd: tqmx86: IO controller with i2c, wachdog and gpio

> > +static int tqmx86_create_platform_device(const struct dmi_system_id *id)
> 
> This blows my mind.
> 
>  - The normal module_init() calls are initiated calling for a DMI scan
>  - Then the DMI device init()s
>  - You use the DMI init() to register this device as a platform device
>  - Then this platform device then probes
> 
> That seems very incestuous.
> 
> What is the reason for all the hoop jumping?

Hi Lee

It does seem like a lot of hoops to jump through. But i don't see a
way to avoid it. When you are matching on DMI tables, all you appear
to be able to do is register a callback to be called. This callback
cannot be used as a driver probe, you cannot return -EPROBE_DEFER and
expect it to be called again, etc. So if you do want to create a
device, you need to go via a platform_device.

If you know of a better way, i would be happy to implement it.

   Thanks
	Andrew