[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8A489018-9C77-4013-B055-89853ACBF8C6@gmail.com>
Date: Tue, 01 Aug 2023 21:13:30 +0300
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Jonathan Cameron <jic23@...nel.org>, Arnd Bergmann <arnd@...db.de>
CC: Lars-Peter Clausen <lars@...afoo.de>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Samu Onkalo <samu.p.onkalo@...ia.com>,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] misc: adps990x: convert to OF
1 серпня 2023 р. 21:10:26 GMT+03:00, Jonathan Cameron <jic23@...nel.org> написав(-ла):
>On Mon, 31 Jul 2023 17:38:59 +0200
>"Arnd Bergmann" <arnd@...db.de> wrote:
>
>> On Mon, Jul 31, 2023, at 16:58, Svyatoslav Ryhel wrote:
>> > 31 липня 2023 р. 16:18:16 GMT+03:00, Arnd Bergmann <arnd@...db.de> написав(-ла):
>> >>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
>
Powered by blists - more mailing lists