On Mon, 2007-12-10 at 13:06 -0500, Jon Smirl wrote:
>
> I can't see an easy way to do this. The basic problem is that the i2c
> drivers are assumed to be cross platform. I would need to add a path
> through the i2c core for getting a void pointer from the bus to the
> device But then when the dev
On Mon, 2007-12-10 at 10:42 -0600, Scott Wood wrote:
> On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
> > The more I think about it, the more I tend to agree that tagging isn't
> > necessary and you are right. We should just match the name against the
> > "compatible" prop
On 12/10/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I can't see an easy way to do this. The basic problem is that the i2c
> > drivers are assumed to be cross platform.
>
> It'd be a small binding-specific portion, similar to an of_platform stub
> on a generic driver. It coul
Jon Smirl wrote:
> I can't see an easy way to do this. The basic problem is that the i2c
> drivers are assumed to be cross platform.
It'd be a small binding-specific portion, similar to an of_platform stub
on a generic driver. It could probably wait until an actual need
arises, though.
> I woul
On 12/10/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
> > The more I think about it, the more I tend to agree that tagging isn't
> > necessary and you are right. We should just match the name against the
> > "compatible" propert
On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
> The more I think about it, the more I tend to agree that tagging isn't
> necessary and you are right. We should just match the name against the
> "compatible" property of the OF nodes (which mean we need to support
> multiple
On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
>
> > +static struct i2c_device_id rs5c372_id[] = {
> > + {"rtc-rs5c372", rtc_rs5c372a},
> > + {"rs5c372a", rtc_rs5c372a},
> > + {"rs5c372b", rtc_rs5c372b},
> > + {"rv5c386", rtc_rv5c386},
> > + {
On 12/9/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > +static struct i2c_device_id rs5c372_id[] = {
> > + {"rtc-rs5c372", rtc_rs5c372a},
> > + {"rs5c372a", rtc_rs5c372a},
> > + {"rs5c372b", rtc_rs5c372b},
> > + {"rv5c386", rtc_rv5c386},
> > + {"rv5c387a",
> +static struct i2c_device_id rs5c372_id[] = {
> + {"rtc-rs5c372", rtc_rs5c372a},
> + {"rs5c372a", rtc_rs5c372a},
> + {"rs5c372b", rtc_rs5c372b},
> + {"rv5c386", rtc_rv5c386},
> + {"rv5c387a", rtc_rv5c387a},
> + DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
> +
On 12/9/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-12-09 at 15:57 -0500, Jon Smirl wrote:
> >
> > Are there technical concerns with this series? The white space can be
> > fixed in a few minutes.
> >
> > Adding a tag to differentiate matching types has implications that
On Sun, 2007-12-09 at 15:57 -0500, Jon Smirl wrote:
>
> Are there technical concerns with this series? The white space can be
> fixed in a few minutes.
>
> Adding a tag to differentiate matching types has implications that are
> broader than just i2c. Shouldn't we do this first with the existing
On 12/9/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> > What is the status of this series, is there anything I can do to help
> > get this into the i2c subsystem?
>
> I think there were a few comments such as whitespace issues and Sc
On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I think there were a few comments such as whitespace issues and Scott
had a comment about a tag to differenciate matching type.
Thus the
On Sun, Dec 09, 2007 at 03:24:55PM -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I never saw the comments about whitespace cleanups being addressed. If
you run them through checkpatch you'll see quite a few things
What is the status of this series, is there anything I can do to help
get this into the i2c subsystem?
On 12/3/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> The following series implements standard linux module aliasing for i2c modules
> It then converts the mpc i2c driver from being a platform drive
15 matches
Mail list logo
