linux-kernel - Re: [PATCH 1/4 v2] mfd: add STw481x driver

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]

Date:	Mon, 16 Sep 2013 14:44:35 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nel.org>, Wolfram Sang <wsa@...-dreams.de>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Cc:	Lee Jones <lee.jones@...aro.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Wang Shilong <wangshilong1991@...il.com>
Subject: Re: [PATCH 1/4 v2] mfd: add STw481x driver

On Mon, Sep 16, 2013 at 12:40 PM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, Sep 16, 2013 at 10:19:56AM +0100, Lee Jones wrote:
>
>> Can't you just NULL .id_table?

No. That is not OK with the I2C core. It's
not easy to get rid of the requirement for .id_table
not to be NULL either.

>> Here's the code which would use it:
>> > /* match on an id table if there is one */
>> > if (driver->id_table)
>> >         return i2c_match_id(driver->id_table, client) != NULL;
>
>> Matching for "dummy" will just waste cycles.
>
> i2c_device_probe() will return -ENODEV if id_table is NULL before we get
> to actually matching.  We could remove that check though...

Copy+pasting from my own reply earlier:

I've tried to fix this for DT-only I2C devices
and this very driver was the reason.

But a tiresome regression due to drivers relying on this
i2c_device_id not being NULL and inability to remove it from the I2C
core without refactoring the world ensued, see:
commit c80f52847c50109ca248c22efbf71ff10553dca4

Reverted in:
commit 661f6c1cd926c6c973e03c6b5151d161f3a666ed

For this reason I think:
http://marc.info/?l=linux-next&m=137148411231784&w=2

I have tentatively given up getting pure DT I2C drivers
to probe, I don't think I have the whole picture, but
Wolfram has serious doubts about this and say we have
to be careful ....

Wolfram, do you have some ideas on how we should
proceed or ar you happy with merging this as-is?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/