| Message ID | CAMpxmJW5WNF2zE+fjmpDxubAYA_A67iQhNGTvSAL-MD-6dFTCw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Sep 12, 2016 at 5:33 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, Sep 12, 2016 at 05:16:14PM +0200, Bartosz Golaszewski wrote: >> AFAIK there is no clean way to tell that a GPIO is used by an I2C >> multiplexer at probe time. Linus, Alexandre could you confirm? Nominally, the GPIO descriptors are just abstract resources such as regulators or clocks, they can be used for a lot but just like a clock, regulator, dma channel etc does not know who is using it and for what, it does not know this, no. > You cannot inspect the device tree while probing? Of course it *can* but we would end up encoding a special case every time something like this happens, tied to just device tree, then another bolt-on for ACPI etc. I have a hard time following the problem really, I'm afraid I'm simply just not smart enough :( Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 15, 2016 at 9:51 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Tue, Sep 13, 2016 at 02:29:24PM +0200, Linus Walleij wrote: >> On Mon, Sep 12, 2016 at 5:33 PM, Peter Zijlstra <peterz@infradead.org> wrote: >> > On Mon, Sep 12, 2016 at 05:16:14PM +0200, Bartosz Golaszewski wrote: >> >> >> AFAIK there is no clean way to tell that a GPIO is used by an I2C >> >> multiplexer at probe time. Linus, Alexandre could you confirm? >> >> Nominally, the GPIO descriptors are just abstract resources such >> as regulators or clocks, they can be used for a lot but just like >> a clock, regulator, dma channel etc does not know who is using >> it and for what, it does not know this, no. >> >> > You cannot inspect the device tree while probing? >> >> Of course it *can* but we would end up encoding a special >> case every time something like this happens, tied to just >> device tree, then another bolt-on for ACPI etc. >> >> I have a hard time following the problem really, I'm >> afraid I'm simply just not smart enough :( > > Why would this be DT or ACPI specific? Linux itself has a tree/graph of > all busses and devices right? That's what all this drivers/base/ stuff > is on about. > > So can't you walk up that and see if you encounter the exact same driver > again? > > Something like: > > for (nr = 0, parent = dev->parent; parent; parent = parent->parent) { > if (parent->device_driver == &pca953x_driver.driver) > nr++; > } Oh clever. Of course. Bartosz can you try out this approach? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-09-15 14:41 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>: > On Thu, Sep 15, 2016 at 9:51 AM, Peter Zijlstra <peterz@infradead.org> wrote: >> On Tue, Sep 13, 2016 at 02:29:24PM +0200, Linus Walleij wrote: >>> On Mon, Sep 12, 2016 at 5:33 PM, Peter Zijlstra <peterz@infradead.org> wrote: >>> > On Mon, Sep 12, 2016 at 05:16:14PM +0200, Bartosz Golaszewski wrote: >>> >>> >> AFAIK there is no clean way to tell that a GPIO is used by an I2C >>> >> multiplexer at probe time. Linus, Alexandre could you confirm? >>> >>> Nominally, the GPIO descriptors are just abstract resources such >>> as regulators or clocks, they can be used for a lot but just like >>> a clock, regulator, dma channel etc does not know who is using >>> it and for what, it does not know this, no. >>> >>> > You cannot inspect the device tree while probing? >>> >>> Of course it *can* but we would end up encoding a special >>> case every time something like this happens, tied to just >>> device tree, then another bolt-on for ACPI etc. >>> >>> I have a hard time following the problem really, I'm >>> afraid I'm simply just not smart enough :( >> >> Why would this be DT or ACPI specific? Linux itself has a tree/graph of >> all busses and devices right? That's what all this drivers/base/ stuff >> is on about. >> >> So can't you walk up that and see if you encounter the exact same driver >> again? >> >> Something like: >> >> for (nr = 0, parent = dev->parent; parent; parent = parent->parent) { >> if (parent->device_driver == &pca953x_driver.driver) >> nr++; >> } > > Oh clever. Of course. > > Bartosz can you try out this approach? > I think it may be more complicated than that, depending on the hw topology, but the general idea seems reasonable. I'll try this. Thanks, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-09-15 16:38 GMT+02:00 Peter Zijlstra <peterz@infradead.org>: > On Thu, Sep 15, 2016 at 04:08:52PM +0200, Bartosz Golaszewski wrote: >> 2016-09-15 15:39 GMT+02:00 Peter Zijlstra <peterz@infradead.org>: > >> > In any case, if this fails, we can always punt and simply count the >> > total number of instances of this driver on the system and go with that. >> > >> >> But for __mutex_init() to work with the key argument you need to know >> it at compile time, right? > > You can do something like: > > mutex_init(&mutex); > lockdep_set_subclass(&mutex, nr); > > which will of course fail at runtime the moment nr >= 8, but is that > really a concern? > > Equally you can do: > > static struct lock_class_key my_keys[NR]; > > mutex_init(&mutex); > BUG_ON(nr > NR); > lockdep_set_class(&mutex, my_keys + nr); > > and have a bigger limit. Thanks, I was not aware of this API. Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-09-16 12:56 GMT+02:00 Peter Zijlstra <peterz@infradead.org>: > On Thu, Sep 15, 2016 at 03:39:22PM +0200, Peter Zijlstra wrote: > >> In any case, if this fails, we can always punt and simply count the >> total number of instances of this driver on the system and go with that. > > One caveat with that approach is that if this is s module, someone doing > rmmod, insmod a number of times gets tricky. The whole thing is a bit more complicated - I'm trying to figure out the code behind it, but the first expander has four parents whose driver == pca953x, while the second has five of them. There is no device name, but kobj->name corresponds with the i2c device sub-directories on correct addresses and busses (1-0021 for the first one and 4-0020 for the second on my board). With both devices having pca953x parents I still can't tell one from another. Still working on it. Thanks, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-09-16 13:14 GMT+02:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>: > > The whole thing is a bit more complicated - I'm trying to figure out > the code behind it, but the first expander has four parents whose > driver == pca953x, while the second has five of them. There is no > device name, but kobj->name corresponds with the i2c device > sub-directories on correct addresses and busses (1-0021 for the first > one and 4-0020 for the second on my board). Actually nevermind my last e-mail - I did a braindead mistake when obtaining logs. Thanks, Bartosz -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-09-15 14:41 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>: > > Oh clever. Of course. > > Bartosz can you try out this approach? > > Yours, > Linus Walleij Hi Linus, I submitted a patch reusing a routine already present in i2c.h that allows to test if an i2c adapter's parent is also an i2c adapter, which is the case for adapters behind a multiplexer. Also Cc'ed linux-i2c and Wolfram Sang to let him take a look if the API is used correctly. Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 5e3be32..40b96bf 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -739,6 +739,7 @@ static const struct of_device_id pca953x_dt_ids[]; static int pca953x_probe(struct i2c_client *client, const struct i2c_device_id *id) { + struct lock_class_key *lock_key = (struct lock_class_key *)id; struct pca953x_platform_data *pdata; struct pca953x_chip *chip; int irq_base = 0; @@ -783,7 +784,7 @@ static int pca953x_probe(struct i2c_client *client, chip->chip_type = PCA_CHIP_TYPE(chip->driver_data); - mutex_init(&chip->i2c_lock); + __mutex_init(&chip->i2c_lock, "chip->i2c_lock", lock_key); /* initialize cached registers from their original values. * we can't share this chip with another i2c master.