lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ