> I don't think you are following the big picture of what I am saying. I
> was trying to follow Florian's intention (first make sure I understand
> it) and suggest that the FCS checking code in the patch he submitted
> is not doing what it was intended to. I am getting apparent FCS
> mismatches rep
On Fri, 18 Oct 2019 at 16:54, Russell King - ARM Linux admin
wrote:
>
> On Fri, Oct 18, 2019 at 04:37:55PM +0300, Vladimir Oltean wrote:
> > On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> > > >
On Fri, Oct 18, 2019 at 04:37:55PM +0300, Vladimir Oltean wrote:
> On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin
> wrote:
> >
> > On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> > > Hi Andrew,
> > >
> > > On Fri, 18 Oct 2019 at 16:01, Andrew Lunn wrote:
> > > >
>
On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin
wrote:
>
> On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> > Hi Andrew,
> >
> > On Fri, 18 Oct 2019 at 16:01, Andrew Lunn wrote:
> > >
> > > > Well, that's the tricky part. You're sending a frame out, with no
> > > >
On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> Hi Andrew,
>
> On Fri, 18 Oct 2019 at 16:01, Andrew Lunn wrote:
> >
> > > Well, that's the tricky part. You're sending a frame out, with no
> > > guarantee you'll get the same frame back in. So I'm not sure that any
> > > identifi
Hi Andrew,
On Fri, 18 Oct 2019 at 16:01, Andrew Lunn wrote:
>
> > Well, that's the tricky part. You're sending a frame out, with no
> > guarantee you'll get the same frame back in. So I'm not sure that any
> > identifiers put inside the frame will survive.
> > How do the tests pan out for you? Do
> Well, that's the tricky part. You're sending a frame out, with no
> guarantee you'll get the same frame back in. So I'm not sure that any
> identifiers put inside the frame will survive.
> How do the tests pan out for you? Do you actually get to trigger this
> check? As I mentioned, my NIC drops
On Fri, 18 Oct 2019 at 01:22, Florian Fainelli wrote:
>
>
>
> On 10/17/2019 3:06 PM, Vladimir Oltean wrote:
> >> +static int phy_rgmii_debug_rcv(struct sk_buff *skb, struct net_device
> >> *dev,
> >> + struct packet_type *pt, struct net_device *unused)
> >> +{
> >> +struct ph
On 10/17/2019 3:06 PM, Vladimir Oltean wrote:
>> +static int phy_rgmii_debug_rcv(struct sk_buff *skb, struct net_device
>> *dev,
>> + struct packet_type *pt, struct net_device *unused)
>> +{
>> + struct phy_rgmii_debug_priv *priv = pt->af_packet_priv;
>> + u32 fcs;
>> +
>
Hi Florian,
[sorry, I started writing this before you sent out a v2]
On 10/16/19 1:49 AM, Florian Fainelli wrote:
RGMII connections are always troublesome because of the need to add
delays between the RX or TX clocks and data lines. This can lead to a
fair amount of breakage that upsets users.
> If all is well, we stop iterating over all possible RGMII combinations
> and offer the one that is deemed suitable which is what an user should
> be trying by configuring the platform appropriately.
Hi Florian
I like the idea, however...
I think it would be good to always iterate over all poss
From: Florian Fainelli
Date: Oct/15/2019, 23:49:53 (UTC+00:00)
> The function phy_rgmii_debug_probe() could also be used by an Ethernet
> controller during its selftests routines instead of open-coding that
> part.
I can add it to stmmac selftests then :)
> +int phy_rgmii_debug_probe(struct phy
RGMII connections are always troublesome because of the need to add
delays between the RX or TX clocks and data lines. This can lead to a
fair amount of breakage that upsets users.
Introduce a new sysfs write only attribute which can be set to 1 to
instruct the PHY library to attempt to probe what
13 matches
Mail list logo
