From: Timur Tabi <[EMAIL PROTECTED]>
The workqueue interface changed with David Howell's patch on 11/22/2006
(SHA 65f27f38446e1976cc98fd3004b110fedcddd189). Several drivers were
updated with that patch to handle the new interface, but ucc_geth.c
was not one of them. This pa
From: Timur Tabi <[EMAIL PROTECTED]>
The local versions of phy_read() and phy_write() in ucc_geth_phy.c conflict
with the prototypes in include/linux/phy.h, so this patch renames them,
moves them to the top of the file (while eliminating the redundant prototype),
and makes them static.
These two patches were originally sent to linuxppc-dev, but they should have
been sent here too.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Timur Tabi <[EMAIL PROTECTED]>
The local versions of phy_read() and phy_write() in ucc_geth_phy.c conflict
with the prototypes in include/linux/phy.h, so this patch renames them,
moves them to the top of the file (while eliminating the redundant prototype),
and makes them static.
From: Timur Tabi <[EMAIL PROTECTED]>
The workqueue interface changed with David Howell's patch on 11/22/2006
(SHA 65f27f38446e1976cc98fd3004b110fedcddd189). Several drivers were
updated with that patch to handle the new interface, but ucc_geth.c
was not one of them. This pa
27;s
something that the tulip+uli526x driver does that the stand-alone uli526x driver
doesn't do.
Unfortunately, I don't really know anything about the tulip or uli526x drivers.
Is there anyone who can give me a clue as to what could be wrong?
--
Timur Tabi
Linux kernel de
Timur Tabi wrote:
Hi,
I'm trying to get the ULI 526x driver working on a Freescale 8610
reference board, and it can't connect. When I turn on debug, I see this:
Update: I can ping anything on my subnet, but nothing else. Also, it looks like
my MAC address is hosed:
eth0
, and 8568 to contain the new property
names only.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.25 branch. ucc_geth will compile but not
run if my other patch, "qe: add function qe_clock_source" has not also been
applied.
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, and updates the ucc_geth
driver to take advantage of all this.
Patch #1 is an arch/powerpc patch meant for Kumar's for-2.6.25 branch.
Patch #2 is a netdev patch, so it's eith
with rx-clock-name and tx-clock-name,
which use strings instead of numbers to indicate QE clock sources.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.25 branch. You may need to apply
my other pending patch, "qe: add ability to upload QE
Timur Tabi wrote:
Add function qe_clock_source() which takes a string containing the name of a
QE clock source (as is typically found in device trees) and returns the
matching enum qe_clock value.
Update booting-without-of.txt to indicate that the UCC properties rx-clock
and tx-clock are
Timur Tabi wrote:
Updates the ucc_geth device driver to check the new rx-clock-name and
tx-clock-name properties first. If present, it uses the new function
qe_clock_source() to obtain the clock source. Otherwise, it checks the
deprecated rx-clock and tx-clock properties.
Update the device
The QE Ethernet driver was writing to the wrong register to mask interrupts.
In ucc_geth_stop(), it was clearing UCCE instead of UCCM.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drive
accordingly. Macros
IS_MURAM_ERR() and IS_DPERR(), have been deleted in favor of IS_ERR_VALUE().
Also added error checking to rh_attach_region().
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Updated for Paul's latest tree. Even though this patch changes powerpc,
netdev, and serial
e this introduces the error:
commit 7d776cb596994219584257eb5956b87628e5deaf
Author: Timur Tabi <[EMAIL PROTECTED]>
Date: Mon Mar 12 15:40:27 2007 -0500
[POWERPC] QE: automatically select QE options
I have a dilemma, so I need help fixing this bug.
This particular patch is necessary because without it, select
is out later today.
I chose the first method because I wanted each individual UCC device driver to select
UCC_FAST or UCC_SLOW as appropriate, so that I wouldn't have to update
arch/powerpc/sysdev/qe_lib/Kconfig every time we add a new UCC driver. Oh well.
--
Timur Tabi
Linux Kernel Develope
The UCC_GETH Kconfig option in drivers/net/Kconfig had a line to select
the UCC_FAST option is arch/powerpc/sysdev/qe_lib/Kconfig, which is only used
on PowerPC builds. On other architectures, this would generated a warning.
The fix is to have UCC_FAST depend on UCC_GETH.
Signed-off-by: Timur
Simon Horman wrote:
I agree. I had thought a little about a kconfig fix. Though I'm
wondering if removing the warning will lead to oodles of dangling
symbols and invalid checks over time.
I'm pretty sure it will. Perhaps we need to have a lint for Kconfig?
-
To unsubscribe from this list: se
Russell King wrote:
You might also want to fix the other stupidity with this. See my message
on this very subject ("select is evil: another reason" from May 9th on lkml.)
I submitted a patch yesterday which includes both fixes. Apparently, it's
already in the -mm tree.
-
To unsubscribe from
ucc_geth_mii.c includes , but it never needed it. With commit
2f6c9d961081dc7b109eb19166244bcb2a5dfc28, the asm-powerpc => asm-ppc link
is removed, and so ucc_geth_mii.c can no longer include include/asm-ppc/ocp.h,
so the compile fails. This patch removes the #include line.
Signed-off-by: Ti
Timur Tabi wrote:
ucc_geth_mii.c includes , but it never needed it. With commit
2f6c9d961081dc7b109eb19166244bcb2a5dfc28, the asm-powerpc => asm-ppc link
is removed, and so ucc_geth_mii.c can no longer include include/asm-ppc/ocp.h,
so the compile fails. This patch removes the #include l
27;s wrong with iopa(). Is it because
it's a 32-bit only function? The memory has already been mapped with ioremap(),
so why would we want to map it again?
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
(u32) immrbar_virt_to_phys(ugeth->
p_tx_bd_ring[i]));
Would it be better to replace this code with something like this:
out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].bd_ring_base,
get_qe_base() + ((void *) ugeth->p_tx_bd_ring[i] - (void *) q
Kumar Gala wrote:
Right, so when do you know if you'll be using MURAM or normal memory?
Why not just keep around a token that is the physical address at the
point you make the decision of MURAM vs normal memory.
That's what the original code did, kinda. It called virt_to_phys() if
it is ma
Li Yang-r58472 wrote:
No, we don't know if the BD ring is in MURAM or main memory as it is
configurable. iopa() is best choice to handle both case, IMHO.
The above code would only be used if the BD is in MURAM. The "if
bd_mem_part == MEM_PART_MURAM" would stay.
If the BD ring can be in ma
Dan Malek wrote:
On Feb 8, 2007, at 8:35 AM, Timur Tabi wrote:
That's what the original code did, kinda. It called virt_to_phys() if
it is main memory, and it called immrbar_virt_to_phys() if it is MURAM.
immrbar_virt_to_phys() did pointer math to extract the physical
address.
Y
Update ucc_geth_probe() to use function of_get_mac_address() to obtain the MAC
address.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
Stephen Rothwell wrote:
+ tdm_ctrl[device_num]->ut_info->uf_info.tdm_tx_clk =
+ (char *) of_get_property(np, "fsl,tdm-tx-clk", NULL);
^
We don't normall put spaces here.
Since when?
--
Timur Tabi
Linux kernel d
d in the device tree. So it makes sense to
put the pin configurations in the device tree, too.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
e U-Boot can determine the settings of some board jumpers and
modify the device tree accordingly. The instructions on how to modify the
device tree would be embedded in the tree itself. I can't support this feature
if the kernel calls par_io_config_pin() regardless of what's in
reg();
17. Replace qe_mux.cmxucrX with qe_mux.cmxucr[].
18. Updated struct ucc_geth because struct ucc_fast is not padded any more.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Add fix 18.
arch/powerpc/sysdev/qe_lib/qe.c | 36 +++--
arch/powerpc/sysdev/qe_lib/qe_ic.c|2
I
made a few ucc_geth changes that can't be docoupled from the powerpc changes.
A series of 18 patches would just be convoluted.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, updates some other
functions to use an enum instead of an integer, and updates the ucc_geth
driver to take advantage of all this.
-
To unsubscribe from this list: send the li
with rx-clock-name and tx-clock-name,
which use strings instead of numbers to indicate QE clock sources.
Update qe_setbrg() to take an enum qe_clock instead of an integer as its
first paramter.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.24 bra
, 836x, and 8568 have been updated to contain the
new property names only.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.24 branch, on top of my other patch titled
"qe: add function qe_clock_source".
arch/powerpc/boot/dts/m
Sorry, please ignore this set. Something got screwed up with the patches.
I'm going to resend.
Timur Tabi wrote:
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, updates some other
functions to use an enum instead
(Replaces all previous versions of this patch)
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, updates some other
functions to use an enum instead of an integer, and updates the ucc_geth
driver to take advantage of all thi
with rx-clock-name and tx-clock-name,
which use strings instead of numbers to indicate QE clock sources.
Update qe_setbrg() to take an enum qe_clock instead of an integer as its
first paramter.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.
, 836x, and 8568 have been updated to contain the
new property names only.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.24 branch, on top of my other patch titled
"qe: add function qe_clock_source".
arch/powerpc/boot/dts/mpc832x_mds.
ve <[EMAIL PROTECTED]>
Acked-by: Timur Tabi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Florian Fainelli wrote:
+/* Transmit the packet */
>+static int emac_start_xmit(struct sk_buff *skb, struct net_device *netdev)
>+{
>+ struct emac_adapter *adpt = netdev_priv(netdev);
>+
>+ return emac_mac_tx_buf_send(adpt, &adpt->tx_q, skb);
I would inline emac_mac_tx_buf_send()'s body he
Gilad Avidov
Signed-off-by: Timur Tabi
---
v5:
- changed author to Timur, added MAINTAINERS entry
- use phylib, replacing internal phy code
- added support for EMAC internal SGMII v2
- fix ~DIS_INT warning
- update DT bindings, including removing unused properties
- removed interrupt handler
David Miller wrote:
Please always order local variable declarations from longest to shortest
line.
Audit your entire driver for this issue, thanks.
I will fix this in v6.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Cod
Florian Fainelli wrote:
Are you utilizing the PHYLIB APIs properly? You need at least a
phy_start() to start the PHY state machine, and an adjust_link callback
to be provided to phy_connect() (or of_phy_connect()) to manage link
state changes. And that's the very basic minimum here, there could b
Florian Fainelli wrote:
The Ethernet MAC should be started in ndo_open() and stopped in
ndo_close(), in between, there are link state changes, but you are not
supposed to stop or start your Ethernet MAC and its DMA for instance
during link change, if that is a HW requirement, your HW is pretty fu
Timur Tabi wrote:
I think the problem is that the current driver seems to be too eager to
start/stop the MAC.
Please take a look at emac_work_thread_link_check() at
https://lkml.org/lkml/2016/4/13/670. Every time the PHY link goes up,
it does this:
Never mind, I figured out the problem. I
Is there an easy way to test my driver's response to a
ndo_tx_timeout() call? That is, force dev_watchdog() to think that a
timeout has occurred?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Projec
Florian Fainelli wrote:
One way to do this could be to never reclaim the SKBs you just
transmitted which could be achieved by disabling the TX completion
interrupt permanently for instance.
Thanks, that was the the trick.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc.
Rob Herring wrote:
>>>+- reg : Offset and length of the register regions for the device
>>>+- reg-names : Register region names referenced in 'reg' above.
>>>+ Required register resource entries are:
>>>+ "base" : EMAC controller base register block.
>>>+ "csr": EMAC wrap
Andrew Lunn wrote:
I'm back to working on this driver, and I need some more help with
how to handle the phy. mdio-gpio.txt doesn't really tell me much.
I'm actually working on an ACPI system and not DT.
I can help you with DT, but not ACPI.
The MDIO bus can be a separate Linux device. Since y
Andrew Lunn wrote:
There are two different things here. One is configuring the pin to be
a GPIO. The second is using the GPIO as a GPIO. In this case,
bit-banging the MDIO bus.
The firmware could be doing the configuration, setting the pin as a
GPIO. However, the firmware cannot be doing the MD
Vikram Sethi wrote:
On the FSM9900 SOC (which uses device-tree), the two pins that connect to the external
PHY are gpio pins. However, the driver needs to reprogram the pinmux so that those pins
are wired to the Emac controller. That's what the the gpio code in this driver is doing:
it's ju
Bjorn Andersson wrote:
It sounds like you're trying to say that the pins used can be are
muxed as GPIO or MDIO, in the TLMM.
I'm not 100% sure, but I think that's correct. If you don't want to
have normal networking, you could connect those external pins to some
GPIO device (like an LED or
The driver was originally written by Gilad Avidov, but it's now
being supported by Timur Tabi.
Signed-off-by: Timur Tabi
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4851f02..8c580f8 100644
--- a/MAINTAINERS
+++ b/MAINTA
kbuild test robot wrote:
drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
>>drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:9: warning: large integer
implicitly truncated to unsigned type [-Woverflow]
writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
This
Shanker Donthineni wrote:
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
>>drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:9: warning: large
integer implicitly truncated to unsigned type [-Woverflow]
>> writel(~DIS_INT, adpt->base + EMAC_INT_STAT
Rob Herring wrote:
@@ -0,0 +1,65 @@
+Qualcomm EMAC Gigabit Ethernet Controller
+
+Required properties:
+- compatible : Should be "qcom,emac".
Come on... Can you guess what I'm going to say here.
Ooops, I missed that one.
+- reg : Offset and length of the register regions for the device
+
Florian Fainelli wrote:
On 13/04/16 10:59, Timur Tabi wrote:
From: Gilad Avidov
Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC.
This driver supports the following features:
1) Checksum offload.
2) Runtime power management support.
3) Interrupt coalescing support.
4
Vikram Sethi wrote:
>> retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> if (retval) {
>> dev_err(&pdev->dev, "failed to set DMA mask err %d\n", retval);
>> goto err_res;
>> }
How can you set the mask to 64 bits when the EMAC IP on FSM9900 and QD
Rob Herring wrote:
>
> dma-mask = <0 0x>;
>
>or
>
> dma-mask = <0x 0x>;
No. See dma-ranges.
How exactly should I use dma-ranges? I can't find any other drivers
that queries that property and uses the result to call dma_set_mask. I
thought the dma-ran
Bjorn Andersson wrote:
For platform devices being populated via from DT you will pass:
of_platform_bus_create()
of_platform_device_create_pdata()
of_dma_configure()
Which calls of_dma_get_range() to acquire this information from the
dma-ranges property and set up the dma ops and properti
Rob Herring wrote:
You may only care about the size, but the binding has to handle the
more complex case. Here's an example
<0x0 0x2 0x0 0x1 0x0>
dma address 0 (cell 0) maps to cpu (parent) address 0x2_ (cell
1-2) and the range/size is 4G (cell 3-4).
If you have the same base address,
Bjorn Andersson wrote:
Your driver is a platform driver and it's being probed from DT. As such
all this is already taken care of for you, by the core.
The listing is for your reference to know why the dma-ranges property
would affect your device.
Ah, sorry. I misunderstood what you meant by "y
Sinan Kaya wrote:
VMAP allows you to make several pages look contiguous to the CPU.
It can only be used against logical addresses returned from kmalloc
or alloc_page.
You cannot take several virtually mapped addresses returned by
dma_alloc_coherent
and try to make them virtually contiguous aga
Sinan Kaya wrote:
I'd like to see a version of the solution
to get merged until Mellanox comes up with a better solution with another
patch.
Yes, I agree 100%.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation coll
Florian Fainelli wrote:
Well, PHYLIB does prefer using MDIO accesses to "speak" to PHYs,
built-in or external, but there is always the option of investing into
some custom development with the subsystem to make it play nicely with
your HW.
So I've done some more research, and I believe that th
Timur Tabi wrote:
So I've done some more research, and I believe that the internal phy is
not a candidate for phylib, but the external phy (which is a real phy)
might be. There's no MDIO bus to the internal phy.
Does this mean that I will need to enable a PHY driver, and that d
the PHY on the 8030, but it makes more sense to not call that
function at all if it isn't needed.
Signed-off-by: Timur Tabi
---
drivers/net/phy/at803x.c | 40 ++--
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/net/phy/at803x
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote:
> From: Madalin Bucur
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).
Please fix your git-send-email configuration, so that your emails are
formatted properly. This is the From: header
So first of all, thanks for posting this. I know it's missing a bunch
of stuff that's necessary for Qualcomm's Server chip, but it's a
start.
Unfortunately, 6,000 lines is a lot to review at once. Any chance you
can break up the next version into smaller patches?
On Mon, Dec 7, 2015 at 4:58 PM,
Gilad Avidov wrote:
pointer math on void* ?
what is the size of void ?
I'm talking about adding and subtracting pointer values, so
u32 pkt_len =((void *)ip_hdr(skb) - skb->data)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of
Arnd Bergmann wrote:
We generally want to use readl/writel rather than the relaxed versions,
unless it is in performance-critical code.
What about if we have 20+ writes in a row, for example, when
initializing a part? I've seen code like this:
writel_relaxed(...);
writel_rel
Arnd Bergmann wrote:
If that's in the probe() called from it function, just use writel() everywhere,
a few extra microseconds won't kill the boot time. In general, if a user would
notice the difference, use the relaxed version and add a comment to explain
how you proved it's correct, otherwise st
David Miller wrote:
I think you did something much worse. You quoted the entire huge
patch which is entirely inappropriate given the feedback you were
trying to give.
Sorry about that. I usually do trim it, but I got tired and forgot
before I hit send.
--
Sent by an employee of the Qualcom
Rob Herring wrote:
>+ dma-ranges = <0 0 0x>;
I believe dma-ranges is supposed to be in the bus (parent) node.
Maybe I'm just going to be perpetually confused by dma-ranges, but how
can I specify that the emac has a different DMA range from another SOC
device, if dma-ranges
Shanker Donthineni wrote:
/* Set dma_mask and coherent_dma_mask to 64-bits,
* if xHC supports 64-bit addressing */
if (HCC_64BIT_ADDR(xhci->hcc_params) &&
!dma_set_mask(dev, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, "Enabling 64-bit
Rob Herring wrote:
>+ interrupt-parent = <&emac0>;
>+ #interrupt-cells = <1>;
>+ interrupts = <0 1>;
>+ interrupt-map-mask = <0x>;
>+ interrupt-map = <0 &intc 0 76 0
>+1 &intc 0 80 0>;
Why? This looks unnecessa
Gilad Avidov
Signed-off-by: Timur Tabi
---
v6:
- Properly ordered local variables
- use built-in GEN_MASK instead of BITS_MASK
- remove redundant call to emac_rx_mode_set from emac_mac_up
- removed emac_rfd structure, use dma_addr_t directly instead
- removed emac_mac_speed enun, replaced
Arnd Bergmann wrote:
On Friday, June 24, 2016 6:46:48 PM CEST Timur Tabi wrote:
>+ /* The EMAC itself is capable of 64-bit DMA. If the SOC limits that
>+* range, then we expect platform code to adjust the mask accordingly.
>+*/
>+ ret = dma_set_mask_
Arnd Bergmann wrote:
If the ranges property lists the bus as dma capable for only the
lower 32 bits, then dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
should fail, otherwise dma_alloc_coherent() will return an invalid
memory area.
That seems wrong. dma_alloc_coherent() should be smart eno
Arnd Bergmann wrote:
That's also not how it works: each device starts out with a 32-bit mask,
because that's what historically all PCI devices can do. If a device
is 64-bit DMA capable, it can extend the mask by passing DMA_BIT_MASK(64)
(or whatever it can support), and the platform code checks i
Arnd Bergmann wrote:
Usually drivers try 64-bit mask and 32-bit masks, and the 32 bit
mask is practically guaranteed to succeed.
Sure, but in theory, my for-loop is correct, right? Wouldn't there be
some value in setting a 36-bit or 40-bit DMA mask if it works? We have
a platform where memo
Arnd Bergmann wrote:
Sure, but in theory, my for-loop is correct, right? Wouldn't there be
some value in setting a 36-bit or 40-bit DMA mask if it works? We have
a platform where memory starts at a 40-bit address, so some devices have
a 44-bit address bus. If a 64-bit mask doesn't work, then
Gilad Avidov wrote:
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
new file mode 100644
index 000..36a7746
--- /dev/null
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -0,0 +1,1808 @@
+/* Copyright (c) 2013-2015, The Linux
Gilad is no longer working for Qualcomm, so I'm taking over (as best as
I can) this driver. Let's just say it's going to be a learning experience.
Rob Herring wrote:
diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt
b/Documentation/devicetree/bindings/net/qcom-emac.txt
new file
Rob Herring wrote:
The emac is present on a lot of Qualcomm SOCs, and there are only a few
variations of it. It's not really SOC-specific, and the hardware version
can be queried by the driver.
Can the integration bugs be queried, too?
Come on, you know how compatible strings work.
Fine. I
Gerlando Falauto wrote:
Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb
You need to remove these from patches that are emailed, and fix the
pointer type comparison.
Otherwise,
Acked-by: Timur Tabi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
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 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);
}
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 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
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.
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
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:
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 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 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 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 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 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
1 - 100 of 324 matches
Mail list logo
