linux-kernel - Re: [PATCH v3 2/2] iio: adc: mcp3911: add support for the whole MCP39xx family

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <74abc9e0-ba9a-d7ec-4f1c-815f8e351701@linaro.org>
Date:   Tue, 8 Aug 2023 09:49:43 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Marcus Folkesson <marcus.folkesson@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Kent Gustavsson <kent@...oris.se>,
        Jonathan Cameron <jic23@...nel.org>,
        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>,
        Cosmin Tanislav <demonsingur@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        ChiYuan Huang <cy_huang@...htek.com>,
        Haibo Chen <haibo.chen@....com>,
        Ramona Bolboaca <ramona.bolboaca@...log.com>,
        Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
        ChiaEn Wu <chiaen_wu@...htek.com>,
        William Breathitt Gray <william.gray@...aro.org>,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] iio: adc: mcp3911: add support for the whole
 MCP39xx family

On 08/08/2023 09:22, Marcus Folkesson wrote:

>>
>> ...
>>
>>> -	ret = mcp3911_config(adc);
>>> +	ret = device_property_read_u32(&adc->spi->dev, "microchip,device-addr", &adc->dev_addr);
>>
>> Why not spi->dev? Ditto for other uses like this.
> 
> After all, I think it is better to stick sith adc->spi-dev to be
> consistent with the rest of the probe function. Change to spi->dev
> should probably be a seperate patch.
> Do you agree?
> 

You can first simplify the usages and then add new family support
already using spi->dev.

Best regards,
Krzysztof