On Thu 15 Jun 09:26 PDT 2017, Sebastian Reichel wrote: > Hi, > > On Mon, Jun 12, 2017 at 04:32:03PM -0700, Bjorn Andersson wrote: [..] > > As such if we split the non-input related handling into another driver > > we would need to make the input driver create a subdevice during probe - > > or create a new pon-driver with a new compatible that internally spawns > > the pwrkey driver. Neither seems desirable to me... > > The pon-driver would have been the proper solution, but with the > binding already being defined that's no longer a nice option :( > We have a binding for the "qcom,pm8941-pwrkey", but as long as we maintain the compatibility in the input driver with this we could come up with a new binding for the "pon" block. > > The features of the PON block not yet shown on LKML are status registers > > to indicate the reason for powering up the PMIC and a watchdog (which I > > don't believe is used or exposed today). > > So we have a block, which has watchdog, powerdown, reboot, boot-reason, > reboot-mode and power key. To me that does not look like it should be > one driver. > Unfortunately I do agree with this. It would make sense to describe the pon in a single DT-node and have a pon-driver spawning off individual driver for each functionality. That way we get a clean representation in DT and we get clean implementation of each component... Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
