Re: [PATCH v1 2/2] misc: adps990x: convert to OF

[Svyatoslav Ryhel]

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
>