[RFC] Compound GPIO driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Resending this since I had the wrong ML address. Sorry Linus for the spam.

Hi,

I was hoping to get some feedback for a GPIO driver that I'm considering writing.

Background:
Having SOC GPIOs exposed to end users of a product may not always be a good idea. F.ex. I may want to have +-60V tolarant IOs that can source/sink hundreds of mA.
One way to solve that is to put more robust FETs (or something), in some configuration, between the user accessible pin and the SOC pad. Reconstructing the SOC GPIO block outside the chip in a way. Having dedicated SOC GPIOs for  pull-up/down, input and output and so on.

Now this makes it a task for user space, or the drivers using the compound GPIOs, to handle the input/output/pull GPIOs as separate.

Proposed solution:
Having a driver that, controlled by DT, could build Linux GPIOs from groups of GPIOs with different functions.

Maybe this already exists? I have a hard time believing that we are the only ones building rugged GPIOs like this.

Are there any obvious gotchas with this approach that I'm missing (I'm fairly new in kernel development).

Best regards,
Einar Vading
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux