On Wed, Jan 04, 2017 at 02:00:30PM -0800, Dmitry Torokhov wrote: > On Wed, Jan 04, 2017 at 10:55:47PM +0100, Wolfram Sang wrote: > > > > > From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001 > > > From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > Date: Wed, 4 Jan 2017 09:33:43 -0800 > > > Subject: [PATCH] i2c: do not enable fall back to Host Notify by default > > > > > > Falling back unconditionally to HostNotify as primary client's interrupt > > > breaks some drivers which alter their functionality depending on whether > > > interrupt is present or not, so let's introduce a board flag telling I2C > > > core explicitly if we want wired interrupt or HostNotify-based one: > > > I2C_CLIENT_HOST_NOTIFY. > > > > > > For DT-based systems we introduce "host-notofy" property that we convert > > > to I2C_CLIENT_HOST_NOTIFY board flag. > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > > Yay, this looks better to me. One nit: > > > > > +Alternatively, devices supporting SMbus Host Notify, and connected to > > > +adapters that support this feature, may use "host-notify" property. I2C > > > +core will create a virtual interrupt for Host Notify and assign it as > > > +primary interrupt for the slave. > > > > This paragraph sounds Linux-ish while binding docs should be OS > > agnostic. Maybe we can shorten the second sentence to "It will be > > assigned then as the primary interrupt for the slave."? > > Heh, I just sent out patch to DT folks. Provided that they are fine with > the new property I can either send V2 or you could edit when applying, > whatever is easier for you. That said, both variants are Linux-ish to me: I do not believe that "primary slave interrupt" for I2C devices is a generic concept. Is it? Do BSD and Windows use it? Also, it matches the paragraph above that also talks about I2C core. In any case, it is your decision, I'm just making random noise here. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
