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: <CACRpkdatiELF3WK9qE_Mgcq3iCgv5w3X22xp1=232JJq9sWggQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ