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]
Message-ID: <b0727f9f-2837-51bb-a8b7-d11bdc9af110@gmail.com>
Date:   Tue, 5 Nov 2019 21:48:49 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Dan Murphy <dmurphy@...com>, andrew@...n.ch, f.fainelli@...il.com,
        davem@...emloft.net
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] net: phy: dp83869: Add TI dp83869 phy

On 05.11.2019 21:26, Dan Murphy wrote:
> Heiner
> 
> On 11/5/19 2:20 PM, Heiner Kallweit wrote:
>> On 05.11.2019 21:02, Dan Murphy wrote:
>>> Heiner
>>>
>>> On 11/5/19 1:55 PM, Heiner Kallweit wrote:
>>>> On 05.11.2019 19:18, Dan Murphy wrote:
>>>>> Add support for the TI DP83869 Gigabit ethernet phy
>>>>> device.
>>>>>
>>>>> The DP83869 is a robust, low power, fully featured
>>>>> Physical Layer transceiver with integrated PMD
>>>>> sublayers to support 10BASE-T, 100BASE-TX and
>>>>> 1000BASE-T Ethernet protocols.
>>>>>
>>>>> Signed-off-by: Dan Murphy <dmurphy@...com>
>>>>> ---
>>>>>    drivers/net/phy/Kconfig              |   6 +
>>>>>    drivers/net/phy/Makefile             |   1 +
>>>>>    drivers/net/phy/dp83869.c            | 439 +++++++++++++++++++++++++++
>>>>>    include/dt-bindings/net/ti-dp83869.h |  43 +++
>>>>>    4 files changed, 489 insertions(+)
>>>>>    create mode 100644 drivers/net/phy/dp83869.c
>>>>>    create mode 100644 include/dt-bindings/net/ti-dp83869.h
>> [...]
>>
>>>>> +static int op_mode;
>>>>> +
>>>>> +module_param(op_mode, int, 0644);
>>>>> +MODULE_PARM_DESC(op_mode, "The operational mode of the PHY");
>>>>> +
>>>> A module parameter isn't the preferred option here.
>>>> You could have more than one such PHY in different configurations.
>>>> Other drivers like the Marvell one use the interface mode to
>>>> check for the desired mode. Or you could read it from DT.
>>>>
>>> We do read the initial mode from the DT but there was a request to be able to change the mode during runtime.
>> Maybe we need to understand the use case better to be able to advise.
>> Will this be needed in production? Or was it requested as debug feature?
>> There's the option to set PHY registers from userspace, e.g. with phytool.
>> This could be used for reconfiguring the PHY.
> 
> This was a customer request that they be able to modify the op_mode from user space.
> 
> This was all I was given for a requirement.  The customers use case was proprietary.
> 
If the module parameter serves just a (unknown) proprietary use case,
then it should not be in mainline. You could provide a patch with this
parameter separately to the client.

> Dan
> 
> 
>> Heiner
>>
>>
>>
>> [...]
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ