On 08/11/2016 16:41, Mason wrote:
> On 31/10/2016 16:29, Mason wrote:
>
>> I'm using these net drivers:
>>
>> drivers/net/ethernet/aurora/nb8800.c
>> drivers/net/phy/at803x.c
>>
>> With a smp8758 board, they work great.
>> I've been trying to use them on a different board:
>>
>> same eth PH
On 31/10/2016 16:29, Mason wrote:
> I'm using these net drivers:
>
> drivers/net/ethernet/aurora/nb8800.c
> drivers/net/phy/at803x.c
>
> With a smp8758 board, they work great.
> I've been trying to use them on a different board:
>
> same eth PHY (Atheros AR8035)
> same eth MAC (Aurora S
On 04/11/2016 17:55, Måns Rullgård wrote:
> Florian Fainelli writes:
>
>> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>>> Andrew Lunn writes:
>>>
On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
> Andrew Lunn writes:
>
I agree with you. But fixing it is lik
Florian Fainelli writes:
> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>> Andrew Lunn writes:
>>
>>> On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
Andrew Lunn writes:
>>> I agree with you. But fixing it is likely to break boards which
>>> currently have "rgm
On 11/04/2016 08:22 AM, Måns Rullgård wrote:
> Andrew Lunn writes:
>
>> On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
>>> Andrew Lunn writes:
>>>
>> I agree with you. But fixing it is likely to break boards which
>> currently have "rgmii", but actually need the delay i
Andrew Lunn writes:
> On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
>> Andrew Lunn writes:
>>
>> >> > I agree with you. But fixing it is likely to break boards which
>> >> > currently have "rgmii", but actually need the delay in order to work.
>> >>
>> >> Does the internal del
On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
> Andrew Lunn writes:
>
> >> > I agree with you. But fixing it is likely to break boards which
> >> > currently have "rgmii", but actually need the delay in order to work.
> >>
> >> Does the internal delay here refer to the PHY or th
Andrew Lunn writes:
>> > I agree with you. But fixing it is likely to break boards which
>> > currently have "rgmii", but actually need the delay in order to work.
>>
>> Does the internal delay here refer to the PHY or the MAC? It's a
>> property of the MAC node after all.
>
> It is the PHY whi
On 11/04/2016 02:57 PM, Andrew Lunn wrote:
>> Considering the ethernet DT bindings:
>>
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt
>>
>> Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid",
>> "rgmii-txid".
>>
>> Assuming that "rxid" (rx internal de
> > I agree with you. But fixing it is likely to break boards which
> > currently have "rgmii", but actually need the delay in order to work.
>
> Does the internal delay here refer to the PHY or the MAC? It's a
> property of the MAC node after all.
It is the PHY which applies the delay.
The phy
On 04/11/2016 15:04, Måns Rullgård wrote:
> Andrew Lunn writes:
>
>>> Considering the ethernet DT bindings:
>>>
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt
>>>
>>> Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid",
>>> "rgmii-txid".
>>>
>>> As
Andrew Lunn writes:
>> Considering the ethernet DT bindings:
>>
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt
>>
>> Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid",
>> "rgmii-txid".
>>
>> Assuming that "rxid" (rx internal delay) and "rx clock
> Considering the ethernet DT bindings:
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt
>
> Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid".
>
> Assuming that "rxid" (rx internal delay) and "rx clock delay" are
> in fact the same co
On 04/11/2016 14:40, Måns Rullgård wrote:
> Mason writes:
>
>> On 31/10/2016 17:28, Mason wrote:
>>
>>> On 31/10/2016 16:53, Andrew Lunn wrote:
>>>
> I'll add a log for the request_irq call.
And take a look at /proc/interrupts
>>>
>>> You're right, there does seem to be something w
Mason writes:
> On 31/10/2016 17:28, Mason wrote:
>
>> On 31/10/2016 16:53, Andrew Lunn wrote:
>>
I'll add a log for the request_irq call.
>>>
>>> And take a look at /proc/interrupts
>>
>> You're right, there does seem to be something wrong with the interrupts.
>
> Having fixed that, I'm s
On 31/10/2016 17:28, Mason wrote:
> On 31/10/2016 16:53, Andrew Lunn wrote:
>
>>> I'll add a log for the request_irq call.
>>
>> And take a look at /proc/interrupts
>
> You're right, there does seem to be something wrong with the interrupts.
Having fixed that, I'm still unable to ping a box on
On 31/10/2016 16:53, Andrew Lunn wrote:
>> I'll add a log for the request_irq call.
>
> And take a look at /proc/interrupts
You're right, there does seem to be something wrong with the interrupts.
# cat /proc/interrupts
CPU0
20: 26285 GIC-0 29 Edge twd
IPI0:
> I'll add a log for the request_irq call.
And take a look at /proc/interrupts
Andrew
On 31/10/2016 16:37, Andrew Lunn wrote:
>> The regnum=5,4,1,1,a,9 logs keep repeating, endlessly.
>> Is that expected?
>
> Yes, that is expected, if you are not using interrupts. The phylib
> state machine polls the state of the PHY once per second to see if
> there has been a link up/down.
Inte
On Mon, Oct 31, 2016 at 04:29:25PM +0100, Mason wrote:
> Hello everyone,
>
> I'm using these net drivers:
>
> drivers/net/ethernet/aurora/nb8800.c
> drivers/net/phy/at803x.c
>
> With a smp8758 board, they work great.
> I've been trying to use them on a different board:
>
> same eth PHY (A
> The regnum=5,4,1,1,a,9 logs keep repeating, endlessly.
> Is that expected?
Yes, that is expected, if you are not using interrupts. The phylib
state machine polls the state of the PHY once per second to see if
there has been a link up/down.
Andrew
Hello everyone,
I'm using these net drivers:
drivers/net/ethernet/aurora/nb8800.c
drivers/net/phy/at803x.c
With a smp8758 board, they work great.
I've been trying to use them on a different board:
same eth PHY (Atheros AR8035)
same eth MAC (Aurora SSN8800)
different SoC (same base add
22 matches
Mail list logo
