From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5D54C0015E for ; Tue, 1 Aug 2023 18:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229814AbjHASKh (ORCPT ); Tue, 1 Aug 2023 14:10:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjHASKh (ORCPT ); Tue, 1 Aug 2023 14:10:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E14A10E; Tue, 1 Aug 2023 11:10:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C80FA6166F; Tue, 1 Aug 2023 18:10:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53358C433C8; Tue, 1 Aug 2023 18:10:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690913435; bh=k+dw7L8vyhlKn9VUzSf3b0oQlhLBaS6C3SxWnN9fOtE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CYBT9DHsBKKt9Bi/j8BCn+CAiaCy7IlCYCqH9uG+v13meObZ99nkdddt8wMex3qH7 YHKoGShoUTU/K8cNCDrigmfM4AAZwh346CH/bF1Uv21pSo+t9oM/pfqqFVNcacKilT wKuJsr3d2qUSLoZoHXrCkMS6JM2zWRUUeq5h+6xY9eDIb1gJeo3r0L9KCO8WqOoqOo z2d08kkwlGECnUiwWBN1/vfiIC8x26d7vwGAgEw7sB5WS4lSyXhmpSBkugV3+9vrdK dyd8JkyZLhgDf5TmzU0mdtd8h4X6/4A6IJ3+xAlLYSXYVqRak/B3RofT+jeCg+tcXA 6aMYt/R6Vq7gw== Date: Tue, 1 Aug 2023 19:10:26 +0100 From: Jonathan Cameron To: "Arnd Bergmann" Cc: "Svyatoslav Ryhel" , "Lars-Peter Clausen" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Greg Kroah-Hartman" , "Samu Onkalo" , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/2] misc: adps990x: convert to OF Message-ID: <20230801191026.02512438@jic23-huawei> In-Reply-To: References: <20230731110239.107086-1-clamor95@gmail.com> <20230731110239.107086-3-clamor95@gmail.com> <7C51AA15-DEBE-486B-9788-F84B260F8880@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 31 Jul 2023 17:38:59 +0200 "Arnd Bergmann" wrote: > On Mon, Jul 31, 2023, at 16:58, Svyatoslav Ryhel wrote: > > 31 =D0=BB=D0=B8=D0=BF=D0=BD=D1=8F 2023 =D1=80. 16:18:16 GMT+03:00, Arnd= Bergmann =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(-=D0= =BB=D0=B0): =20 > >>On Mon, Jul 31, 2023, at 13:02, Svyatoslav Ryhel wrote: =20 > >>> Add ability to use device tree bindings keeping existing setup. =20 > >> > >>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. =20 > > > > Thank you very much for your review, but is it mandatory to drop pdata= =20 > > in this particular patch set? To be honest this driver needs serious=20 > > upgrades and refactoring, and I have no dedication to invest my time=20 > > into refactoring it, moreover, I am not a maintainer of this driver,=20 > > nor a full time kernel maintainer of any kind. I am doing what I am=20 > > doing only because one of my devices uses this als but it is not=20 > > something crucial. =20 >=20 > 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. >=20 > 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. >=20 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? 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