> We are embedding reset logic here about the delays and polarity, while > there is now a proper abstraction for this within the reset controller > subsystem under drivers/reset/core.c. Could we utilize that facility > instead which would make us more robust wrt. non-GPIO reset lines (for > instance some SF2 switches on DSL gateways could definitively benefit > from this). > > There does not seem to be a reset controller GPIO binding and generic > driver, but this seems like an appropriate candidate?
Hi Florian That was my first thought as well. But then i went searching and found http://permalink.gmane.org/gmane.linux.ports.arm.kernel/257149 where Mark Rutland says no to the idea. reset-gpios should be handle by the device. Anyway, delays are hard coded, but polarity not. That is in the generic device tree binding for a GPIO, you can say GPIO_ACTIVE_LOW or GPIO_ACTIVE_HIGH. The delays are also hard coded in the Marvell specific part, so should not cause a problem to other manufactures chips. Andrew -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
