[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a523bd4-952f-4f2e-a60d-2899ae7d1316@microchip.com>
Date: Fri, 24 May 2024 10:48:33 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>
CC: <steve.glendinning@...well.net>, <UNGLinuxDriver@...rochip.com>,
<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <netdev@...r.kernel.org>, <linux-usb@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: usb: smsc95xx: configure external LEDs function for
EVB-LAN8670-USB
Hi Andrew,
On 23/05/24 6:13 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Thu, May 23, 2024 at 08:51:54AM +0000, Parthiban.Veerasooran@...rochip.com wrote:
>> Hi Andrew,
>>
>> On 22/05/24 10:14 pm, Andrew Lunn wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Wed, May 22, 2024 at 07:38:17PM +0530, Parthiban Veerasooran wrote:
>>>> By default, LAN9500A configures the external LEDs to the below function.
>>>> nSPD_LED -> Speed Indicator
>>>> nLNKA_LED -> Link and Activity Indicator
>>>> nFDX_LED -> Full Duplex Link Indicator
>>>>
>>>> But, EVB-LAN8670-USB uses the below external LEDs function which can be
>>>> enabled by writing 1 to the LED Select (LED_SEL) bit in the LAN9500A.
>>>> nSPD_LED -> Speed Indicator
>>>> nLNKA_LED -> Link Indicator
>>>> nFDX_LED -> Activity Indicator
>>>
>>> What else can the LEDs indicate?
>> There is no other indications.
>
> O.K. So it is probably not worth going the direction of using the
> netde LED infrastructure to allow the use to configure the LED.
>
>>>> + /* Set LED Select (LED_SEL) bit for the external LED pins functionality
>>>> + * in the Microchip's EVB-LAN8670-USB 10BASE-T1S Ethernet device which
>>>
>>> Is this a function of the USB dongle? Or a function of the PHY?
>> It is the function of USB dongle.
>
> So an OEM designing a dongle could make the LEDs do different things?
Yes.
>
> You are solving the problem only for your reference design, and OEMs
> are going to have to solve the same problem for their own design?
>
> This is why i'm asking is it a function of the PHY or the board. If it
> is the PHY, we could have one generic solution for everybody using
> that PHY.
OK, it is a function of the board not PHY and also that depends on the
board design based on the requirement I guess.
Best regards,
Parthiban V
>
> Andrew
Powered by blists - more mailing lists