On 8/6/20 8:54 PM, wanghai (M) wrote:
Thanks for your suggestion. May I fix it like this?
Yes, this is what I had in mind. Thanks.
Acked-by: Timur Tabi
On 8/6/20 9:06 AM, Wang Hai wrote:
In emac_clks_phase1_init() of emac_probe(), there may be a situation
in which some clk_prepare_enable() succeed and others fail.
If emac_clks_phase1_init() fails, goto err_undo_clocks to clean up
the clk that was successfully clk_prepare_enable().
Good catch,
On 11/8/18 5:23 PM, Andrew Lunn wrote:
I don't know much about ACPI. I do know DT. MDIO busses can have
multiple PHYs on them. Is the following valid to list two PHYs?
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
On 10/25/18 9:18 PM, Wang, Dongsheng wrote:
But when I was reading Documentation/acpi/DSD-properties-rules.txt, my
understanding is we should try to conform to DT bindings. So maybe ACPI
doesn't have such a document, just DT bindings.
There was an attempt to document DSDs, but it was abandoned
On 9/19/18 10:20 AM, Andrew Lunn wrote:
I suspect that is not going to be easy. Last time i looked, the ACPI
standard had nothing about MDIO busses or PHYs. Marcin Wojtas did some
work in this area a while back for the mvpp2, but if i remember
correctly, he worked around this by simply not having
On 9/19/18 7:25 AM, Andrew Lunn wrote:
ACPI is completely separate and should not affect the DT binding.
I've not yet looked at the ACPI changes you added.
Just FYI, there is no device tree platform on which the upstream EMAC
driver works. All of the DT code in the driver is theoretical. It
On 9/13/18 7:42 AM, Andrew Lunn wrote:
This is a pretty big patch, and is hard to review. Could you try to
break it up into a number of smaller patches. You could for example
first refactor emacs_phy_config(), without making any functional
changes. Then add the sharing. Maybe do OF an ACPI in dif
On 5/25/18 7:22 PM, Timur Tabi wrote:
-phy->open = emac_sgmii_open;
-phy->close = emac_sgmii_close;
-phy->link_up = emac_sgmii_link_up;
-phy->link_down = emac_sgmii_link_down;
I'll take it look at it next week when I'm back in the office.
I posted a
Commit "net: qcom/emac: Encapsulate sgmii ops under one structure"
introduced the sgmii_ops structure, but did not correctly initialize
it on device tree platforms. This resulted in compiler warnings when
ACPI is not enabled.
Reported-by: Arnd Bergmann
Signed-off-by: Timur Tabi
--
On 5/25/18 4:37 PM, Arnd Bergmann wrote:
+#ifdef CONFIG_ACPI
static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits)
{
struct emac_sgmii *phy = &adpt->phy;
@@ -288,6 +289,7 @@ static struct sgmii_ops qdf2400_ops = {
.link_change = emac_sgmii_common_link_change,
On 5/17/18 3:28 AM, Hemanth Puranik wrote:
Currently we use non-NUMA aware allocation for TPD and RRD buffers,
this patch modifies to use NUMA friendly allocation.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
On 5/15/18 8:10 PM, Hemanth Puranik wrote:
This patch introduces ops structure for sgmii, This by ensures that
we do not need dummy functions in case of emulation platforms.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
On Fri, Mar 16, 2018 at 11:25 PM, Sinan Kaya wrote:
> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16
> inc, union t4_wr *wqe)
> (u64 *)wqe);
> } else {
> pr_debug("DB wq->sq.pidx = %d\n", wq->sq
On 3/16/18 6:04 PM, Steve Wise wrote:
Anybody understand why the PPC implementation of writeX_relaxed() isn't
relaxed?
You probably should ask that on the linuxppc-...@lists.ozlabs.org
mailing list.
I've always wondered why PowerPC has non-standard I/O accessors.
--
Qualcomm Datacenter Tech
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value)
{
- writel(value, ring->tail);
+ writel_relaxed(value, ring->tail);
}
ge in all the places and
dma_unmap_page while freeing the buffers.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Found
On 01/25/2018 09:59 AM, Andrew Lunn wrote:
I expect we will implement something like acpi_mdiobus_register(), and
it will take a pointer to an ACPI node. And maybe on top of
of_mdiobus_register() and of_mdiobus_register() we will add a
device_mdiobus_register().
Makes sense. If you remember, p
On 01/25/2018 08:15 AM, Andrew Lunn wrote:
If i'm reading your patch correctly, you are looking for the MDIO
reset in the MAC node. This is wrong. It is an MDIO property, so
should be in the MDIO device. Once we have figured out how to
represent MDIO busses in ACPI, the reset will be in the MDIO
On 01/25/2018 12:14 AM, Wang Dongsheng wrote:
mdiobus always try to get a GPIO "reset" consumer, based on ACPI
the GPIO should be described in emac-adev _DSD or _CRS.
Are you talking about this:
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(&bus->dev,
On 1/22/18 10:25 PM, Wang Dongsheng wrote:
Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
it's used as an address bit if PTP is disabled. Since PTP isn't
supported by the driver, we can extend the DMA address to 46 bits.
Signed-off-by: Wang Dongsheng
Acked-by:
reset and open paths.
- In the future there may be need for delay based tasks to be done in
sgmii open which will result in NETDEV watchdog
- As per the documentation the order of init should be sgmii, mac, rings
and DMA
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
This is much better. Can you give me a few days to test it on some
internal platforms?
Also, this is a candidate for 4.16, so you need to wait until net-next
is open anyway (http://vger.kernel.org/~davem/net-next.html).
On 11/20/17 7:48 AM, Wang Dongsheng wrote:
Since PTP doesn't support ye
On 11/17/17 3:56 AM, Wang Dongsheng wrote:
-#define TPD_BUFFER_ADDR_H_SET(tpd, val)BITS_SET((tpd)->word[3], 18,
30, val)
+#define TPD_BUFFER_ADDR_H_SET(adpt, tpd, val) BITS_SET((tpd)->word[3], 18, \
+ TX_TS_ENABLE & \
+
On 11/10/2017 07:24 AM, Wang, Dongsheng wrote:
On QDF2400, EMAC TPD buff address size is [45:0]. buff address_l [31:0],
buff address_h [31:18].
The address_h should change from [30:18] to [31:18]. So TPD buff address
should has 46bits.
Bit 31 of the Word 3 in the TPD is the Timestamp_save.
On 11/10/17 3:49 AM, Wang Dongsheng wrote:
TPD has 46-bits as buff address valid bit. So fix the buff address
from 45-bits to 46-bits.
NAK.
The TPD has 45 bits. Why do you say it was 46?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Techno
This reverts commit df1ec1b9d0df57e96011f175418dc95b1af46821.
It turns out that memory allocated via dma_alloc_coherent is always
aligned to the size of the buffer, so there's no way the RRD and RFD
can ever be in separate 32-bit regions.
Signed-off-by: Timur Tabi
---
drivers/net/eth
On 10/12/2017 11:58 AM, David Miller wrote:
I'm pretty sure that kzalloc does not make that guarantee, and I don't
think dma_alloc_coherent does either.
Both make that guarantee, even when an IOMMU is used.
Ok, Dave, then can you drop this patch?
--
Qualcomm Datacenter Technologies, Inc. as
On 10/12/2017 11:20 AM, David Laight wrote:
I'm pretty sure that kzalloc does not make that guarantee, and I don't
think dma_alloc_coherent does either.
dma_alloc_coherent() definitely does.
And I've a driver that relies on it (for 16k blocks).
What about when an IOMMU is used? The DMA addr
On 10/12/17 4:30 AM, David Laight wrote:
Isn't the memory allocated by a single kzalloc() call?
dma_alloc_coherenent, actually.
IIRC that guarantees it doesn't cross a power or 2 boundary less than
the size.
I'm pretty sure that kzalloc does not make that guarantee, and I don't
think dma_a
ned-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 15 ++-
drivers/net/ethernet/qualcomm/emac/emac.c | 8
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
b/drivers/net/ethernet/qua
The EMAC is capable of multiple TX and RX rings, but the driver only
supports one ring for each. One function had some left-over unused
code that supports multiple rings, but all it did was make the code
harder to read.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac
A set of patches for 4.15 that clean up some code, apply minors fixes,
and so on. Some of the code also prepares the driver for a future
version of the EMAC controller.
Timur Tabi (4):
net: qcom/emac: specify the correct DMA mask
net: qcom/emac: remove unused address arrays
net: qcom/emac
less likely.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index
with the DMA mappings, the driver should provide a correct value and
trust the DMA/IOMMU layers to do the right thing.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet
On 10/05/2017 04:10 AM, Colin King wrote:
From: Colin Ian King
The function emac_isr is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warnings:
symbol 'emac_isr' was not declared. Should it be static?
Signed-off-by: Colin Ian King
ACK
--
Qu
: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/ema
pause frames if the kernel hangs.
The option is enabled by using the single-pause-mode private flag.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 30 +++
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 22 +
drivers
On 08/01/2017 04:37 PM, Timur Tabi wrote:
The EMAC has the option of sending only a single pause frame when
flow control is enabled and the RX queue is full. Although sending
only one pause frame has little value, this would allow admins to
enable automatic flow control without having to worry
On 8/2/17 6:15 PM, David Miller wrote:
So you don't want to run a proper watchdog on your systems?
You want them to just hang there and wait for someone to
notice instead?
This is for internal development. We noticed the problem first during
debugging, when we would halt a core for more than
On 08/02/2017 01:35 PM, David Miller wrote:
Again, any serious installation will have a system watchdog enabled
which will break the pause frame bomb.
Oh well. I guess I'll have to carry this patch internally.
What about patch #2?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
On 08/02/2017 12:54 PM, David Miller wrote:
And if this kind of thing matters to the user, they will have a
software or hardware watchdog driver enabled to break out of this
situation.
The problem is that the user is not going to expect that the EMAC can
disable the nearby switch(es) when the
On 08/02/2017 09:51 AM, David Laight wrote:
Sending pause frames just tells the adjacent switch not to send you packets
(because you'll discard them).
Since the idea is to avoid the discards, the switch will buffer the
packets it would have sent.
The buffers in the switch then fill up with packet
On 8/2/17 8:48 AM, David Laight wrote:
If the nearby switches cannot handle pause frames, then the MAC shouldn't
be sending them at all.
There's no way for me to know whether the switches can handle the pause
frames or not. You would think that sending one multicast pause frame
ever 33ms wou
On 8/1/17 9:58 PM, Andrew Lunn wrote:
The PHY does not participate directly in flow control/pause frames except by
making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in
MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC
controller supports such
On 8/1/17 6:15 PM, Andrew Lunn wrote:
Pause frames are something you can auto-negotiate at the PHY
level. Should you also be clearing some bits in the phydev, so the
peer knows pause frames are not supported?
When pause frame autonegotiation is enabled in the driver, that only
means that the d
On 08/01/2017 04:55 PM, Florian Fainelli wrote:
This is not specific to your EMAC, a lot of adapters have this problem
actually.
I wonder if it would make sense to reach for a broader solution where we
could have a networking stack panic/oops notifier which will actively
clean up the active netw
On 08/01/2017 04:51 PM, Florian Fainelli wrote:
A few adapters (bcmgenet, bcmsysport) support configuring the pause
quanta so it would not be inconceivable to try to update
ethtool_pauseparam to include additional fields such as:
Wouldn't this require a change to the user space tool?
- numbe
el is hung and unrecoverable.
To avoid all these problems, we disable flow control autonegotiation
by default, and only enable receiving pause frames.
Cc: sta...@vger.kernel.org # 4.11.x
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 9 +++--
1 file changed, 7 inser
gle
pause frame" mode that could be useful in some situations.
Timur Tabi (2):
[for 4.13] net: qcom/emac: disable flow control autonegotiation by
default
net: qcom/emac: add software control for pause frame mode
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 30
pause frames if the kernel hangs.
The option is enabled by using the single-pause-mode private flag.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 30 +++
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 22 +
drivers
On 7/21/17 8:29 AM, Marc Gonzalez wrote:
I don't understand what you're saying.
It is a correct observation that the code enabling
RGMII RX clock delay is a NOP, since that bit will
always be set at that point.
The spec for the 8035 (I haven't checked for 8030 and 8031,
is that what you meant b
On 7/21/17 6:25 AM, Marc Gonzalez wrote:
+* NB: This code assumes that RGMII RX clock delay is disabled
+* at reset, but actually, RX clock delay is enabled at reset.
Could we change this to say, "RX clock delay is enabled at reset on some
systems."? Otherwise, it implies that
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
If the interface is not up, then don't try to close it during a
shutdown. This avoids possible double free of the IRQ, which
can happen during a shutdown.
Fixes: 03eb3eb4d4d5 ("net: qcom/emac: add shutdown function")
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/e
On emulation systems, the EMAC's internal PHY ("SGMII") is not present,
but is not needed for network functionality. So just display a warning
message and ignore the SGMII.
Tested-by: Philip Elcan
Tested-by: Adam Wallis
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qua
The shutdown function halts all DMA and interrupts, so that all
operations are discontinued when the system shuts down, e.g. via
kexec or a forced reboot.
Tested-by: Tyler Baicar
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 14 ++
1 file changed, 14
rd Ruigrok
Signed-off-by: Timur Tabi
---
v2: improve the patch description.
drivers/net/ethernet/qualcomm/emac/emac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c
b/drivers/net/ethernet/qualcomm/emac/emac.c
index 77c5c92..746d94e 100644
--- a/d
A collection of minor fixes and features to the Qualcomm Technologies
EMAC network driver.
Timur Tabi (3):
net: qcom/emac: add shutdown function
[v2] net: qcom/emac: do not reset the EMAC during initialization
net: qcom/emac: add support for emulation systems
drivers/net/ethernet/qualcomm
On 06/23/2017 01:00 PM, David Miller wrote:
What if the boot loader or something else left the chip in
a weird state?
We depend on the boot loader leaving the NIC in a very specific state
already, otherwise the driver can't initialize the hardware. The
firmware has to pre-initialize the EMAC
On emulation systems, the EMAC's internal PHY ("SGMII") is not present,
but is not needed for network functionality. So just display a warning
message and ignore the SGMII.
Tested-by: Philip Elcan
Tested-by: Adam Wallis
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qua
The shutdown function halts all DMA and interrupts, so that all
operations are discontinued when the system shuts down, e.g. via
kexec or a forced reboot.
Tested-by: Tyler Baicar
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 14 ++
1 file changed, 14
A collection of minor fixes and features to the Qualcomm Technologies
EMAC network driver.
Timur Tabi (3):
net: qcom/emac: add shutdown function
net: qcom/emac: do not reset the EMAC during initialization
net: qcom/emac: add support for emulation systems
drivers/net/ethernet/qualcomm/emac
It doesn't make sense to reset the EMAC in the middle of initializing
it during the probe.
Tested-by: Richard Ruigrok
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac
c: sta...@vger.kernel.org # 4.11.x
Tested-by: Manoj Iyer
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 2 +-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 75 ++-
drivers/net/ethernet/qualcomm/emac/emac.c | 22 +---
3 files cha
c: sta...@vger.kernel.org # 4.11.x
Tested-by: Manoj Iyer
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 2 +-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 75 ++-
drivers/net/ethernet/qualcomm/emac/emac.c | 22 +---
3 files cha
On 06/01/2017 06:45 AM, Zefir Kurtisi wrote:
I guess we need to decide whether we generally need to handle permanent aneg
failures on the SGMII link. If we expect that it must not fail (like we assumed
until we saw it failing), I agree with Timur and support reverting of the
related
commit f6226
On 05/24/2017 04:36 PM, Florian Fainelli wrote:
OK, and there is no way you can run into the following race condition:
CPU HW
MDIO read intent
polling starts
disable HW autopoll
polling continues
Disabl
On 05/24/2017 04:28 PM, Florian Fainelli wrote:
Yes phydev->lock which is used to serialize the state machine state changes.
Most PHYs have many more registers than the 15 standard exposed
directly, and so you need indirect reads/writes to access these
registers, which typically involve switchi
On 05/24/2017 04:15 PM, Andrew Lunn wrote:
My NIC has a feature called autopolling where it takes over the MDIO
bus and regularly polls the link state. When it detects that the
link state has changed, it generates a MAC interrupt. This is when
I call phy_mac_interrupt() normally.
Unfortunate
On 05/24/2017 02:34 PM, Andrew Lunn wrote:
Ok, I'm going to debug this some more. It turns out that the MAC side of
the SGMII link can send an interrupt when it thinks that auto-negotiation is
done. I might be able to use this.
You can use this for your board. But it still leaves the phy driv
On 05/24/2017 09:09 AM, Andrew Lunn wrote:
> It could be, the copper side is up, but the SGMII side is down, at the
> point at803x_aneg_done() is called. So it is correctly returning
> 0. Sometime later the SGMII side goes up, but there is not a second
> interrupt. Hence the phy core does not know
On 5/24/17 8:40 AM, Andrew Lunn wrote:
You need to prove this, that the link is not up. Any by link, we mean
both the copper and the SGMII link.
I can post the log of my iperf run showing that the, when
at803x_aneg_done() returns zero, no packets can go through. And then
after I change at80
On 5/24/17 2:18 AM, Matthias May wrote:
With the patch: When the copper side is seen as up, it also checks if aneg of
the SGMII link is done.
As far as i know SGMII can not be run without aneg, since it is always Gbit
with aneg mandatory.
If SGMII aneg is not done, then, well aneg is not done a
On 05/23/2017 11:07 AM, Andrew Lunn wrote:
>> > I will test that to see what happens, but I believe the real problem is
>> > that
>> > the at803x driver is lying when it says that the link is not okay. I think
>> > the link is okay, and that's why I'm not getting any more interrupts. I
>> > don'
On 05/22/2017 04:32 PM, Andrew Lunn wrote:
>> I'll have to test this, but what do I do if I don't get another interrupt?
> It probably means interrupts cannot be used. Poll it.
I will test that to see what happens, but I believe the real problem is that
the at803x driver is lying when it says that
On 05/22/2017 04:09 PM, Andrew Lunn wrote:
> Are you using interrupts? Or polling?
adpt->phydev->irq = PHY_IGNORE_INTERRUPT;
ret = phy_connect_direct(netdev, adpt->phydev, emac_adjust_link,
PHY_INTERFACE_MODE_SGMII);
Technically it's polling, except that it's my NIC's har
On 05/22/2017 04:10 PM, Florian Fainelli wrote:
> Even a module argument would be rejected. If you need platform/SoC
> specific behavior propagated down to the PHY driver, several options exist:
>
> - pass an agreed upon value for phy_flags to of_phy_connect() see
> drivers/net/ethernet/broadcom/t
On 10/24/2016 05:40 AM, Zefir Kurtisi wrote:
> This commit adds a wrapper function for at8031
> that in case of operating in SGMII mode double
> checks SGMII link state when generic aneg_done()
> succeeds. It prints a warning on failure but
> intentionally does not try to recover from this
> state.
On 05/10/2017 04:47 PM, Florian Fainelli wrote:
> AFAIR kexec takes care of shutting down network devices explicitly
> (unless instructed otherwise with -x/--no-ifdown) so this may be where
> this is coming from.
>
> Reading through drivers/base/core.c it does not appear that ->remove()
> is calle
On 05/09/2017 02:06 PM, Florian Fainelli wrote:
> On 05/09/2017 11:51 AM, Timur Tabi wrote:
>> Is it possible that the network stack detects a kexec and automatically
>> stops all network devices?
>
> No. why would it? However the device driver model does call into y
On 05/09/2017 01:46 PM, Florian Fainelli wrote:
> A good test case for exercising a .shutdown() function is kexec'ing a
> new kernel for instance.
I tried that. I run iperf in one window while launching kexec in another.
Even without a shutdown function, network traffic appear to halt on its own
I'm trying to add a platform_driver.shutdown function to my Ethernet driver
(drivers/net/ethernet/qualcomm/emac/*), but I can't find any definitive
information as to what a network driver shutdown callback is supposed to do.
I also don't know what testcase I should use to verify that my function i
Adjust the impedance values of the RX and TX lanes in the SGMII block
so that they are closer to optimal values.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii-qdf2400.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac
Dan Carpenter wrote:
We had intended to say "sizeof(u32)" but the "u" is missing.
Fortunately, sizeof(32) is also 4, so the original code still works.
Fixes: c4e7beea2192 ("net: qcom/emac: add ethtool support for reading hardware
registers")
Signed-off-by: Dan Car
walter harms wrote:
The question is: why is a simple calculation const*const
separated into a function ?
This is a callback function. That's just how it's defined.
It's rare, but there are drivers that use the parameter, like this one:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-ne
walter harms wrote:
We have a function where the argument is ignored and the rest is const ?
emac_ethtool_get_regs_len seems the only user. So it would be fairly easy to
move that into that function.
@maintainer:
Is there a deeper logic behind this ?
I don't understand the question.
The patc
two files.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 40
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 52 ---
drivers/net/ethernet/qualcomm/emac/emac.h | 108 --
3 files changed, 119 insertions(+), 81
interface is already running when the setting is changed, then
the interface is reset.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-ethtool.c
b
These two patches implement the remaining two ethtool functions that
are of interest to the Qualcomm EMAC driver. These are the last
patches that will be submitted for the 4.11 merge window.
Timur Tabi (2):
net: qcom/emac: add ethtool support for reading hardware registers
net: qcom/emac
those frames, then the feature will not work.
Also some buffer size initialization code into emac_init_adapter(),
so that it lives with similar code, including the initializtion of
pause frame support.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-ethtool.c | 30
On 01/31/2017 01:19 PM, Russell King wrote:
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:58:12: error: dereferencing
pointer to incomplete type 'struct phy_device'
Add linux/phy.h to emac-sgmii.c
Signed-off-by: Russell King
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +
The v
On 01/27/2017 04:43 PM, Timur Tabi wrote:
The SGMII (internal PHY) can report decode errors via an interrupt. It
can also report autonegotiation status changes, but we don't need to track
those. The SGMII can recover automatically from most decode errors, so
we only reset the interface
The EMAC driver does not support wake-on-lan, but there is still
code left-over that partially enables it. Remove that code and a few
macros that support it.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 10 --
drivers/net/ethernet/qualcomm/emac/emac.h
emac_mac_start() uses information from the external PHY to program
the MAC, so it makes no sense to call it before the link is up.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 2 +-
drivers/net/ethernet/qualcomm/emac/emac-mac.h | 1 -
drivers/net/ethernet
Regardless of how the external PHY is configured, the internal PHY
(the "SGMII" block) is capable of configuring the SGMII link automatically.
When the external PHY link comes up, regardless of how it is configured,
the SGMII link is configured automatically.
Signed-off-by:
It's possible for bogus decode errors to be reported while the link is
being brought up. The interrupt is registered when the interface is
opened, and it's enabled after the link is up.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 8 +-
drivers/net/et
emac_mac_start().
The fourth patch removes some extraneous non-functioning WOL code.
The fifth patch adds an error handler for the SGMII block.
Timur Tabi (5):
[net-next] net: qcom/emac: display the phy driver info after we
connect
[net-next] net: qcom/emac: always use autonegotiation to
is the correct time
to display information about the attached driver.
Since phy_attached_print() also prints information about the
interrupt, that needs to be set as well.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 4 +++-
drivers/net/ethernet/qualcomm/emac
It's possible for bogus decode errors to be reported while the link is
being brought up. The interrupt is registered when the interface is
opened, and it's enabled after the link is up.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 8 +-
drivers/net/et
1 - 100 of 316 matches
Mail list logo
