Some SPI host controllers do not support full-duplex SPI and are
marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.
For such controllers use half duplex transactions but retain full
duplex transactions for the controllers that can handle those.
Signed-off-by: Tim Harvey
On Fri, Jul 17, 2020 at 10:08 AM Andrew Lunn wrote:
>
> On Fri, Jul 17, 2020 at 08:58:26AM -0700, Tim Harvey wrote:
> > Greetings,
> >
> > We make embedded boards that often have on-board PCIe based NIC's that
> > have MAC addresses stored in an EEPROM (not with
Greetings,
We make embedded boards that often have on-board PCIe based NIC's that
have MAC addresses stored in an EEPROM (not within NIC's NVRAM). I've
struggled with a way to have boot firmware assign the mac's via
device-tree and I find that only some drivers support getting the MAC
from device-
On Thu, May 28, 2020 at 8:28 AM Tim Harvey wrote:
>
> Some SPI host controllers do not support full-duplex SPI and are
> marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.
>
> For such controllers use half duplex transactions but retain full
> duplex tr
If a valid mac address is present in dt, use that before using
CSR's or a random mac address.
Signed-off-by: Tim Harvey
---
drivers/net/ethernet/microchip/lan743x_main.c | 41 ---
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/net/eth
Without a MODULE_DEVICE_TABLE the attributes are missing that create
an alias for auto-loading the module in userspace via hotplug.
Signed-off-by: Tim Harvey
---
drivers/net/ethernet/microchip/lan743x_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/microchip
Some SPI host controllers do not support full-duplex SPI and are
marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.
For such controllers use half duplex transactions but retain full
duplex transactions for the controllers that can handle those.
Signed-off-by: Tim Harvey
On Fri, Dec 22, 2017 at 4:30 PM, David Daney wrote:
> On 12/22/2017 04:22 PM, Tim Harvey wrote:
>>
>> BGXX_GMP_GMI_TXX_INT[UNDFLW] is getting set when the issue is
>> triggered. From CN80XX-HM-1.2P this is caused by:
>>
>> "In the unlikely event that P2X
On Fri, Dec 22, 2017 at 3:00 PM, David Daney wrote:
> On 12/22/2017 02:19 PM, Tim Harvey wrote:
>>
>> On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
>>>
>>> On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
>>>>
>>>
On Fri, Dec 22, 2017 at 2:45 PM, Andrew Lunn wrote:
>> Currently I'm not using the DP83867_PHY driver (after verifying the
>> issue occurs with or without that driver).
>>
>> It does not occur if I limit UDP (ie 950mbps). I disabled all offloads
>> and the issue still occurs.
>
>> I'm told that th
On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
> On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
>> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>> >> The nic appears to work fine (pings, TCP etc) up until a performance
>> >> test
On Thu, Dec 14, 2017 at 12:45 AM, Andrew Lunn wrote:
> On Wed, Dec 13, 2017 at 03:28:33PM -0800, Tim Harvey wrote:
>> On Wed, Dec 13, 2017 at 3:10 AM, Andrew Lunn wrote:
>> >> +void xcv_init_hw(int phy_mode)
>> >> {
>> >> u64 cfg;
>>
On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>> The nic appears to work fine (pings, TCP etc) up until a performance
>> test is attempted.
>> When an iperf bandwidth test is attempted the nic ends up in a state
>> where truncated-ip packets are being sent out (per a tcpdump from
>> another
On Wed, Dec 13, 2017 at 3:10 AM, Andrew Lunn wrote:
>> +void xcv_init_hw(int phy_mode)
>> {
>> u64 cfg;
>>
>> @@ -81,12 +81,31 @@ void xcv_init_hw(void)
>> /* Wait for DLL to lock */
>> msleep(1);
>>
>> - /* Configure DLL - enable or bypass
>> - * TX no bypass, RX bypa
Greetings,
We are experiencing an issue on a CN80XX with an SGMII interface
coupled to a TI DP83867IS phy. We have the same PHY connected to the
RGMII interface on the same board design and everything is working as
expected on that nic both before and after triggering the hang.
The nic appears to
The XCV_DLL_CTL is being configured with the assumption that
phy-mode is rgmii-txid (PHY_INTERFACE_MODE_RGMII_TXID) which is not always
the case.
This patch parses the phy-mode property and uses it to configure CXV_DLL_CTL
properly.
Signed-off-by: Tim Harvey
---
drivers/net/ethernet/cavium
On Wed, Aug 30, 2017 at 6:46 PM, Andrew Lunn wrote:
>> >/* Report late collisions as a frame error. */
>> > if (status & (BD_ENET_RX_NO | BD_ENET_RX_CL))
>> > ndev->stats.rx_frame_errors++;
>> >
>> > I don't see anywhe
On Wed, Aug 30, 2017 at 3:06 PM, Andrew Lunn wrote:
> On Wed, Aug 30, 2017 at 12:53:56PM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I'm seeing RX frame errors when using the mv88e6xxx DSA driver on
>> 4.13-rc7. The board I'm using is a GW5904 [1] which ha
Greetings,
I'm seeing RX frame errors when using the mv88e6xxx DSA driver on
4.13-rc7. The board I'm using is a GW5904 [1] which has an IMX6 FEC
MAC (eth0) connected via RGMII to a MV88E6176 with its downstream
P0/P1/P2/P3 to front panel RJ45's (lan1-lan4).
What I see is the following:
- bring up
On Wed, Apr 12, 2017 at 9:26 AM, Fabio Estevam wrote:
> Hi Tim,
>
> On Wed, Apr 12, 2017 at 1:15 PM, Tim Harvey wrote:
>>
>> Andrew,
>>
>> Thanks for the reply. Your talking about suspend/resume power
>> management right? The users reporting this were
On Sun, Apr 9, 2017 at 6:42 PM, Andy Duan wrote:
> From: Tim Harvey Sent: Friday, April 07, 2017 10:47 PM
>>To: netdev
>>Cc: Fabio Estevam ; Lucas Stach
>>; Andy Duan ; Koen
>>Vandeputte
>>Subject: IMX6 FEC connection drops occasionally with 'MDIO read ti
On Fri, Apr 7, 2017 at 9:09 AM, Andrew Lunn wrote:
> On Fri, Apr 07, 2017 at 07:47:17AM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I've had a couple of users report that they are getting occasional
>> link drops when using IMX6 FEC on our boards which ar
Greetings,
I've had a couple of users report that they are getting occasional
link drops when using IMX6 FEC on our boards which are using a Marvell
88E1510 PHY:
[ 9348.474418] fec 2188000.ethernet eth0: MDIO read timeout
[ 9350.478804] fec 2188000.ethernet eth0: Link is Down
If they bring the i
On Fri, Sep 23, 2016 at 9:29 AM, Florian Fainelli wrote:
> On 09/23/2016 08:40 AM, Tim Harvey wrote:
>> Greetings,
>>
>> I've got a TI DP83867 GbE phy that requires some register writes to
>> configure its refclock output. Is there a generic device-tree API for
&
Greetings,
I've got a TI DP83867 GbE phy that requires some register writes to
configure its refclock output. Is there a generic device-tree API for
writing to raw registers or is that something that would be need to be
added to a specific phy driver with a device-tree binding? There is a
DP83867
this patch yourself, or should I send it
> to the ARM contacts?
Krzysztof,
Go ahead and send it. You can add my:
Acked-by: Tim Harvey
I know Shawn would be happy to pick this up as well as he has an
imx-fixes tree:
http://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/log/?h=imx/soc
On Tue, Dec 8, 2015 at 6:13 AM, Krzysztof Hałasa wrote:
> Tim Harvey writes:
>
>> It sounds like your saying this controls whether the phy is in charge
>> of delay vs the MAC. I have never needed to set this and haven't found
>> where its actually used (in at
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
> status = "okay";
> };
>
> --
> Krzysztof Halasa
>
> Industrial Research Institute for Automation and Measurements PIAP
> Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Krzysztof,
It sounds like
On Wed, Sep 30, 2015 at 2:40 PM, Andrew Lunn wrote:
>> > information to the NIC's device driver. Better would be to have a
>> > small shim driver which is loaded on your PCI_ID/DEVICE_ID. That would
>> > instantiate the NIC driver, and insert a DSA platform device.
>>
>> I was thinking of this as
On Wed, Sep 30, 2015 at 2:12 PM, Andrew Lunn wrote:
> On Wed, Sep 30, 2015 at 01:44:52PM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I'm working on adding DSA support for a PCIe expansion card (designed
>> by us) that has common PCIe NIC connected via its m
h is to program the NIC's EEPROM on our board
with a PCI_ID/DEVICE_ID of ours, add support for those ID's to the
NIC's driver, and within the NIC's driver create and register dsa
platform device when our ID is encountered?
Thanks for any advise,
Tim
Tim Harvey - P
31 matches
Mail list logo
