On 4/13/2021 3:57 PM, Andrew Lunn wrote:
Ok, we can agree that there will not be a perfect naming. Would it be a
possibility to rename the existing TJA11xx driver to TJA1100-1-2 or is that
unwanted?
It is generally a bad idea. It makes back porting fixing harder if the
file changes name.
If
On 4/13/2021 3:30 PM, Andrew Lunn wrote:
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
Hi Andrew,
On 4/12/2021 6:52 PM, Andrew Lunn wrote:
So what you are say is, you don't care if the IP is completely
different, it all goes in one driver. So lets put this driver
Hi Andrew,
On 4/12/2021 6:52 PM, Andrew Lunn wrote:
So what you are say is, you don't care if the IP is completely
different, it all goes in one driver. So lets put this driver into
nxp-tja11xx.c. And then we avoid all the naming issues.
Andrew
As this seems to be a key question, let
On Tue, May 19, 2020 at 12:58:55PM +0200, Oleksij Rempel wrote:
> On Tue, May 19, 2020 at 10:55:20AM +0200, Michal Kubecek wrote:
> > On Tue, May 19, 2020 at 09:51:59AM +0200, Oleksij Rempel wrote:
> > I'm also a bit worried about hardcoding the 0-7 value range. While I
> > understand that it's
Hi Andrew,
> On Wed, May 13, 2020 at 03:39:00PM +0200, Andrew Lunn wrote:
>> On Thu, May 14, 2020 at 02:09:59PM +0200, Oleksij Rempel wrote:
>> ETHTOOL_A_CABLE_RESULT_CODE_ACTIVE_PARTNER - the link partner is active.
>>
>> The TJA1102 is able to detect it if partner link is master.
>>
>
On Tue, May 14, 2020 at 08:28:00AM +, Oleksij Rempel wrote:
> On Thu, May 14, 2020 at 07:13:30AM +0000, Christian Herber wrote:
> > On Tue, May 12, 2020 at 10:22:01AM +0200, Oleksij Rempel wrote:
> >
> > > So I think we should pass raw SQI value to user space, at
On Tue, May 12, 2020 at 10:22:01AM +0200, Oleksij Rempel wrote:
> So I think we should pass raw SQI value to user space, at least in the
> first implementation.
> What do you think about this?
Hi Oleksij,
I had a check about the background of this SQI thing. The table you reference
with
On May 11, 2020 4:33:53 PM Andrew Lunn wrote:
>
> Are the classes part of the Open Alliance specification? Ideally we
> want to report something standardized, not something proprietary to
> NXP.
>
>Andrew
Hi Andrew,
Such mechanisms are standardized and supported by pretty much all
On October 16, 2019 10:37:30 AM Lucas Stach wrote:
> On Fr, 2019-08-16 at 22:59 +0200, Heiner Kallweit wrote:
>> On 15.08.2019 17:32, Christian Herber wrote:
>> > This patch adds basic support for BASE-T1 PHYs in the framework.
>> > BASE-T1 PHYs main area of
On 24.08.2019 17:03, Heiner Kallweit wrote:
>
> On 22.08.2019 09:18, Christian Herber wrote:
>> On 21.08.2019 20:57, Andrew Lunn wrote:
>>>
>>>> The current patch set IMO is a little bit hacky. I'm not 100% happy
>>>> with the implicit assumption t
On 21.08.2019 20:57, Andrew Lunn wrote:
>
>> The current patch set IMO is a little bit hacky. I'm not 100% happy
>> with the implicit assumption that there can't be devices supporting
>> T1 and classic BaseT modes or fiber modes.
>
>> Andrew: Do you have an opinion on that?
>
> Hi Heiner
>
> I
On 20.08.2019 21:22, David Miller wrote:
>
> From: Christian Herber
> Date: Mon, 19 Aug 2019 15:19:52 +
>
>> v1 patchset can be found here:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F8%2F15%2F626data=02%7C01%7Cch
On 19.08.2019 21:07, Heiner Kallweit wrote:
> Caution: EXT Email
>
> On 19.08.2019 08:32, Christian Herber wrote:
>> On 16.08.2019 22:59, Heiner Kallweit wrote:
>>> On 15.08.2019 17:32, Christian Herber wrote:
>>>> This patch adds basic support for BASE-T1 PHYs
always Clause-45 managed.
Therefore, this patch extends phy-c45.c.
While for some functions like auto-neogtiation different registers are
used, the layout of these registers is the same for the used fields.
Thus, much of the logic of basic Clause-45 devices can be reused.
Signed-off-by: Christian Herber
with this patchset.
Christian Herber (1):
net: phy: Added BASE-T1 PHY support to PHY Subsystem
drivers/net/phy/phy-c45.c| 106 +++
drivers/net/phy/phy-core.c | 4 +-
drivers/net/phy/phy_device.c | 12
include/linux/phy.h | 1 +
include/uapi
On 16.08.2019 23:13, Heiner Kallweit wrote:
>
> On 15.08.2019 17:32, Christian Herber wrote:
>> BASE-T1 is a category of Ethernet PHYs.
>> They use a single copper pair for transmission.
>> This patch add basic support for this category of PHYs.
>> It coveres the di
On 16.08.2019 22:59, Heiner Kallweit wrote:
> On 15.08.2019 17:32, Christian Herber wrote:
>> This patch adds basic support for BASE-T1 PHYs in the framework.
>> BASE-T1 PHYs main area of application are automotive and industrial.
>> BASE-T1 is standardized in IEEE 802.3, nam
On 15.08.2019 18:34, Heiner Kallweit wrote:
> Caution: EXT Email
>
> On 15.08.2019 17:56, Andrew Lunn wrote:
>> On Thu, Aug 15, 2019 at 03:32:29PM +0000, Christian Herber wrote:
>>> BASE-T1 is a category of Ethernet PHYs.
>>> They use a single copper pair for
On 15.08.2019 17:56, Andrew Lunn wrote:
> Caution: EXT Email
>
> On Thu, Aug 15, 2019 at 03:32:29PM +, Christian Herber wrote:
>> BASE-T1 is a category of Ethernet PHYs.
>> They use a single copper pair for transmission.
>> This patch add basic support for this cate
prepared for 100/1000BASE-T1 and works
with this patch. 10BASE-T1 needs to be added to ethtool.
Christian Herber (1):
Added BASE-T1 PHY support to PHY Subsystem
drivers/net/phy/phy-c45.c| 113 +++
drivers/net/phy/phy-core.c | 4 +-
include/uapi/linux
always Clause-45 managed.
Therefore, this patch extends phy-c45.c.
While for some functions like auto-neogtiation different registers are
used, the layout of these registers is the same for the used fields.
Thus, much of the logic of basic Clause-45 devices can be reused.
Signed-off-by: Christian Herber
21 matches
Mail list logo
