1 серпня 2023 р. 21:10:26 GMT+03:00, Jonathan Cameron <jic23@xxxxxxxxxx> написав(-ла): >On Mon, 31 Jul 2023 17:38:59 +0200 >"Arnd Bergmann" <arnd@xxxxxxxx> wrote: > >> On Mon, Jul 31, 2023, at 16:58, Svyatoslav Ryhel wrote: >> > 31 липня 2023 р. 16:18:16 GMT+03:00, Arnd Bergmann <arnd@xxxxxxxx> написав(-ла): >> >>On Mon, Jul 31, 2023, at 13:02, Svyatoslav Ryhel wrote: >> >>> Add ability to use device tree bindings keeping existing setup. >> >> >> >>I see that there are no more in-tree users of the old >> >>apds990x_platform_data, so I think it would be best to completely >> >>remove that codepath and merge that structure into struct >> >>apds990x_chip, to simplify the probing and avoid the extra >> >>allocation. >> > >> > Thank you very much for your review, but is it mandatory to drop pdata >> > in this particular patch set? To be honest this driver needs serious >> > upgrades and refactoring, and I have no dedication to invest my time >> > into refactoring it, moreover, I am not a maintainer of this driver, >> > nor a full time kernel maintainer of any kind. I am doing what I am >> > doing only because one of my devices uses this als but it is not >> > something crucial. >> >> We have a lot of drivers that are lacking the cleanup I'm asking >> for, so I don't think I'd mandate it at this point, but I don't >> actually expect the patch to be any more complicated in the end, >> so just try it out. >> >> I think at the minimum, please remove the include/platform_data >> header and move the contents into the driver itself, I'd be fine >> with that. If you can easily do further cleanup by dropping >> the separate allocation and folding the apds990x_fw_probe() >> function back into apds990x_probe(), please do that, just stop >> at the point where you feel it gets too complicated. >> > >It's a long shot, but this looks pretty close in register map to >the apds9960 in IIO. > >Maybe try adding the ID to that driver and cross your fingers? If you pay me for a broken phone or repair if smth goes wrong, sure, why not. >There is some stuff going on around the register address / commands >that I haven't figured out but it looks similar for the byte access >path and that may be all the IIO driver is using. > >If you are fine testing, it's possible someone else might do the >leg work (if me I'll emulate just enough to convince myself I didn't >break it too badly). Won't be high on my list, but maybe I'll get >a boring wet weekend sometime... > >Jonathan > >> Arnd >
