Hi, On Fri, Jun 9, 2023 at 2:27 AM Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > > > I suspect that it's not worth it, but I'll do this if you feel > > strongly about it. > > > > I guess the simplest way I can think of to move this to its own file > > would be to put the whole private data structure (struct i2c_hid) in a > > private header file and then add prototypes for i2c_hid_core_resume() > > and i2c_hid_core_suspend() there. Then I could add something like > > i2c_hid_core_handle_panel_follower() that would have all the > > registration logic. I'd still need special cases in the core > > suspend/resume/remove code unless I add a level of abstraction. While > > the level of abstraction is more "pure", it also would make the code > > harder to follow. > > > > Unless I hear a strong opinion (or if this series changes > > significantly), I'll plan to keep things in the same file and just use > > a Kconfig. > > > > Right, a separate file might not be the best then :( > > Do you envision this to be used on the ACPI side of i2c-hid? Because > if this is OF only, then maybe it would be interesting to put it there > (in i2c-hid-of.c), instead of having it in the core. IIRC i2c-hid-of > also has ways to set up/down regulators, so maybe it'll be better > there? There is no reason why this problem would be limited to devices using devicetree. Even if ACPI could somehow magically power sequence the touchscreen and panel together, doing it behind the back of the kernel driver would be a bad idea anyway so folks using ACPI would need the same code. I don't have tons of experience with ACPI nor how to hook this up there, but I purposely made the API for registering the panel follower such that the client doesn't pass anything devicetree specific. If someone could figure out how to detect a link between a panel and a touchscreen for ACPI and add this code to drm_panel_add_follower() then it would automatically work for the ACPI case as well. -Doug
