linux-kernel - Re: [PATCH v5 2/5] mfd: Add support for the Lantiq PEF2256 framer

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: <6d39e9c3-fb6a-4b2a-9889-8fe8d86716d5@linaro.org>
Date:   Fri, 31 Mar 2023 11:13:30 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Herve Codina <herve.codina@...tlin.com>, Lee Jones <lee@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, alsa-devel@...a-project.org,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v5 2/5] mfd: Add support for the Lantiq PEF2256 framer

On 31/03/2023 09:42, Herve Codina wrote:
> Hi Lee,
> 
> On Thu, 30 Mar 2023 17:05:10 +0100
> Lee Jones <lee@...nel.org> wrote:
> 
>> On Tue, 28 Mar 2023, Herve Codina wrote:
>>
>>> The Lantiq PEF2256 is a framer and line interface component designed to
>>> fulfill all required interfacing between an analog E1/T1/J1 line and the
>>> digital PCM system highway/H.100 bus.  
>>
>> My goodness!
>>
>> It's been a long time since I've seen anything quite like this.
> 
> Yes, old things but working on recent kernel.
> 
>>
>> My suggestion to you:
>>
>> * Split this up into components that fit functional subsystems
> 
> It is done. The audio part is present in ASoC subsystem (path 5 in this
> series). pinctrl function is implemented in this driver and, as I don't
> want to share registers, I would prefer to keep this function inside this
> driver.

The amount of defines and huge functions like pef2256_setup_e1()
contradict it.

Even the pef2256_setup_e1() really does not follow Linux coding style -
you know the size requirement, right?

pef2256_get_groups_count, struct pinmux_ops and others - this is
pinctrl, not MFD! They cannot be in MFD driver.

> 
> Also, I sent a RFC related to HDLC and PHY. In this RFC, the pef2256 is
> considered as a PHY and handled in the PHY subsystem.
>   https://lore.kernel.org/linux-kernel/20230323103154.264546-1-herve.codina@bootlin.com/
> 
>> * Run checkpatch.pl
> 
> I did.

There are tons of weird indentation,e.g.:
+#define     PEF2256_2X_PC_XPC_XLT	(0x8 << 0)
        ^^^^ there is only one space after #define

... and other style issues:

CHECK: Please don't use multiple blank lines
CHECK: spaces preferred around that '+' (ctx:VxV)
CHECK: Alignment should match open parenthesis
CHECK: Macro argument reuse '_groups' - possible side-effects?
CHECK: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
CHECK: spaces preferred around that '/' (ctx:VxV)


> 
>> * Remove all of the debug prints
> 
> I can do that in the next iteration if really needed.
> 
>> * Move all of the defines out to a header file
> 
> These defines are related to registers. As I don't want to share these
> registers, is it really necessary to use a header file for them ?
> 
>> * Be more verbose in your documentation / comments
> 
> I can improve the API documentation present in include/mfd/pef2256.h.
> Do you thing that is necessary ? Only a few devices will use this API.
> 
Krzysztof