linux-kernel - FYI: [patch 2.6.20-rc1 0/6] I2C driver model updates, part II

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 18 Dec 2006 16:37:19 -0800
From:	David Brownell <david-b@...bell.net>
To:	Linux Kernel list <linux-kernel@...r.kernel.org>
Cc:	Jean Delvare <khali@...ux-fr.org>
Subject: FYI: [patch 2.6.20-rc1 0/6] I2C driver model updates, part II

This is just a heads-up to the folk who read LKML more than more specialized
Linux lists ... there's work afoot to clean up the I2C core and make it fit
the driver model better.  (Some would say "overdue work...".)

The most interesting/useful part (IMO) is summarized in the appended message;
you can read list archives starting at:

  http://lists.lm-sensors.org/pipermail/i2c/2006-December/000633.html

The "part I" stuff gets rid of i2c_adapter.dev (it was pretty pointless),
which opens the door to eliminating even more of the redundancy between
i2c-core and the driver model.  It also lets I2C device drivers use the
standard driver model suspend()/resume()/shutdown mechanisms.  Innocuous,
despite the number of i2c_adapter.dev users that needed to change.

The "part II" bits basically leave "legacy" I2C drivers alone; they add
support for "new style" drivers.  The difference is that legacy drivers
create their own device nodes, and their probe() routines look at busses;
while new style drivers work like any other driver in current Linux,
with probe() being handed a pre-created device node (i2c_client).

I think the plan is to get this into MM soonish; "part I" being nearly
ready, and "part II" probably still needs a bit of tweaking.  (I have
my own notions, and suspect at least one person on LKML will have some
opinions to share...)  There are already OpenFirmware conversion patches,
and driver/platform conversions will as usual take a while to sort out.

- Dave

----------  Forwarded Message  ----------

Subject: [patch 2.6.20-rc1 0/6] I2C driver model updates, part II
Date: Monday 18 December 2006 2:59 pm
From: David Brownell <david-b@...bell.net>
To: i2c@...sensors.org

As promised, the second set of patches ... adding "new style" driver
probe support.  This will help at least

 - Embedded I2C in general (which need IRQs, and board-specific config)
 - OMAP (where I2C can't use SMBUS_QUICK)
 - RTCs (which for various reasons often can't use SMBUS_QUICK probing)
 - OpenFirmware (which provides tables of I2C devices)
 - DVB (I'm told the probing is problematic there too)

These patches apply after the latest "part I" patches (sent to this list,
with three updates posted after feedback from Jean).  The patches are:

 - Support probe(), and hotplug/coldplug
 - Support remove()
 - Document the "new style" driver model probe() and remove()
 - Drive new style driver binding by {bus#, dev#, info} device declarations
 - Update the i2c-omap adapter driver to use bus# matching chip docs
 - Update one OMAP board, and a driver, to use the new infrastructure

I expect that last patch will get split in two; for this series it's
best viewed as an example.

- Dave

-------------------------------------------------------
-
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/