On Thu, Jul 28, 2016 at 4:01 AM, Phil Reid <preid@xxxxxxxxxxxxxxxxx> wrote: > G'day Rob, > > Just another thought. > > On 28/07/2016 10:11, Phil Reid wrote: >> >> G'day Karl / Rob, >> >> On 28/07/2016 05:08, Karl-Heinz Schneider wrote: >>> >>> Am Mittwoch, den 27.07.2016, 09:46 -0500 schrieb Rob Herring: >>>> >>>> On Mon, Jul 25, 2016 at 03:50:03PM +0800, Phil Reid wrote: >>>>> >>>>> This patch added irq support for the SMBALERT pin and notification of >>>>> the battery removal / insertion. The sbs manager would typically be >>>>> used with the corresponding sbs-battery driver that currently uses a >>>>> gpio input for battery presence and interrupt. To remain compatible >>>>> with >>>>> that existing driver this patch implements GPIO inputs with interrupt >>>>> support. IRQ masking is performed in software as the hardware does not >>>>> support masking of notifications from each battery. >>>>> In addition a power_supply change notification is generated for the sbs >>>>> manager device when the AC present flag is changed. >>>>> Tested with LTC1760 and dual sbs compatible batteries. >>>> >>>> >>>> Please don't submit a binding and immediately turn around and add to it. >>>> While that is often preferred for drivers or kernel features, bindings >>>> should be complete as possible and not evolve. Combine this with your >>>> previous patch add sbs-mgr if that hasn't been accepted yet. >> >> That was from Karl. I'm happy to have this combined if he is. Indeed it was. Still, it should be combined. You can leave the driver implementation as multiple patches, just combine all the binding to a single patch by itself. >>>> IMO, the sbs-bat should just be a interrupt and making it and this >>>> binding a GPIO is overkill. Since batteries nodes using this will be >>>> new, there's no reason the driver can't be updated to support >>>> interrupts. > > I did consider this and didn't go that way as: > 1) the current sbs-battery driver didn't support it. > 2) Then there's also the problem of reporting the presence of the battery > to the battery driver. > Without the GPIO support you resort to polling and looking for a NACK. Which > didn't seem that nice. The ability to read the current irq signal state with the irq api would be nice. Of course you can't really count on being able to on all irqs. Anyway, we shouldn't really design the binding around kernel limitations. As I understand how SMBALERT works, you have to poll the devices anyway to determine which device is asserting the irq and to ack the irq. Of course, here you are doing point to point connections, but you still need to know which batteries are present by reading the sbs-mgr registers. Wouldn't switching the driver to level irq allow you to get the state immediately without a gpio read? After all, the gpio read and irq handler are reading the same register. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
