Netdev List
 help / color / mirror / Atom feed
* [PATCH v2] can: Fix bug in suspend/resume
From: Kedareswara rao Appana @ 2014-11-14  8:16 UTC (permalink / raw)
  To: wg, mkl, michal.simek, soren.brinkmann, grant.likely, robh+dt
  Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, devicetree,
	Kedareswara rao Appana

The drvdata in the suspend/resume is of type struct net_device,
not the platform device.Enable the clocks in the suspend before
accessing the registers of the CAN.

Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
  - Removed the struct platform_device* from suspend/resume
    as suggest by Lothar.
  - The clocks are getting disabled and un prepared at the end of the probe. 
    In the suspend the driver is doing a register write.In order
    To do that register write we have to again enable and prepare the clocks.

  
 drivers/net/can/xilinx_can.c |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 5e8b560..485262f 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -972,15 +972,28 @@ static const struct net_device_ops xcan_netdev_ops = {
  */
 static int __maybe_unused xcan_suspend(struct device *dev)
 {
-	struct platform_device *pdev = dev_get_drvdata(dev);
-	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct net_device *ndev = dev_get_drvdata(dev);
 	struct xcan_priv *priv = netdev_priv(ndev);
+	int ret;
 
 	if (netif_running(ndev)) {
 		netif_stop_queue(ndev);
 		netif_device_detach(ndev);
 	}
 
+	ret = clk_prepare_enable(priv->can_clk);
+	if (ret) {
+		dev_err(dev, "unable to enable device clock\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(priv->bus_clk);
+	if (ret) {
+		dev_err(dev, "unable to enable bus clock\n");
+		clk_disable_unprepare(priv->can_clk);
+		return ret;
+	}
+
 	priv->write_reg(priv, XCAN_MSR_OFFSET, XCAN_MSR_SLEEP_MASK);
 	priv->can.state = CAN_STATE_SLEEPING;
 
@@ -999,8 +1012,7 @@ static int __maybe_unused xcan_suspend(struct device *dev)
  */
 static int __maybe_unused xcan_resume(struct device *dev)
 {
-	struct platform_device *pdev = dev_get_drvdata(dev);
-	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct net_device *ndev = dev_get_drvdata(dev);
 	struct xcan_priv *priv = netdev_priv(ndev);
 	int ret;
 
-- 
1.7.4


^ permalink raw reply related

* Re: [PATCH v2] can: Fix bug in suspend/resume
From: Marc Kleine-Budde @ 2014-11-14  8:54 UTC (permalink / raw)
  To: Kedareswara rao Appana, wg, michal.simek, soren.brinkmann,
	grant.likely, robh+dt
  Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, devicetree,
	Kedareswara rao Appana
In-Reply-To: <e7070431858e49e29cd03d76fd7a66c3@BN1AFFO11FD055.protection.gbl>

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On 11/14/2014 09:16 AM, Kedareswara rao Appana wrote:
> The drvdata in the suspend/resume is of type struct net_device,
> not the platform device.Enable the clocks in the suspend before
> accessing the registers of the CAN.
> 
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v2:
>   - Removed the struct platform_device* from suspend/resume
>     as suggest by Lothar.
>   - The clocks are getting disabled and un prepared at the end of the probe. 
>     In the suspend the driver is doing a register write.In order
>     To do that register write we have to again enable and prepare the clocks.

Please look the at suspend/resume code and count the
clock_enable/disable manually. After a suspend/resume cycle, you have
enabled the clock twice, but disabled it once.

I think you have to abstract the clock handling behind runtime PM. I
haven't done this myself yet, but the strong feeling that this is a
possible solution to your problem. These links might help:

http://lwn.net/Articles/505683/
http://www.slideshare.net/linaroorg/runtime-pm
http://www.slideshare.net/linaroorg/lca14-407-deployingruntimepmonarmsocs
http://www.slideshare.net/SamsungOSG/shuah-khan-lpcpmops

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH] brcmfmac: kill URB when request timed out
From: Arend van Spriel @ 2014-11-14  8:57 UTC (permalink / raw)
  To: Mathy Vanhoef, brudley, frankyl, meuleman, John Linville,
	pieterpg, linux-wireless, brcm80211-dev-list, netdev,
	linux-kernel
In-Reply-To: <5464187E.5060208@gmail.com>

On 13-11-14 03:33, Mathy Vanhoef wrote:
> Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
> assures the URB is never submitted twice. It also prevents a possible
> use-after-free of the URB transfer buffer if a timeout occurs.
> 
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
> ---
> For a discussion about this patch and the underlying problem, see the mails
> with as subject "[PATCH] brcmfmac: unlink URB when request timed out".
> 
>  drivers/net/wireless/brcm80211/brcmfmac/usb.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> index 5265aa7..4572def 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
>  		goto finalize;
>  	}
>  
> -	if (!brcmf_usb_ioctl_resp_wait(devinfo))
> +	if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
> +		usb_kill_urb(devinfo->ctl_urb);
>  		ret = -ETIMEDOUT;
> -	else
> +	} else {
>  		memcpy(buffer, tmpbuf, buflen);
> +	}
>  
>  finalize:
>  	kfree(tmpbuf);
> 

^ permalink raw reply

* Re: [PATCH V4 2/3] can: m_can: update to support CAN FD features
From: Marc Kleine-Budde @ 2014-11-14  9:24 UTC (permalink / raw)
  To: Oliver Hartkopp, Dong Aisheng, linux-can
  Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5464E2D7.7010906@hartkopp.net>

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On 11/13/2014 05:56 PM, Oliver Hartkopp wrote:
> On 11/13/2014 11:10 AM, Marc Kleine-Budde wrote:
>> On 11/07/2014 09:45 AM, Dong Aisheng wrote:
> 
>>>  
>>> -	if (id & RX_BUF_RTR) {
>>> +	if (id & RX_BUF_ESI) {
>>> +		cf->flags |= CANFD_ESI;
>>> +		netdev_dbg(dev, "ESI Error\n");
>>> +	}
>>> +
>>> +	if (!(dlc & RX_BUF_EDL) && (id & RX_BUF_RTR)) {
>>>  		cf->can_id |= CAN_RTR_FLAG;
>>
>> I just noticed, that you don't set the cf->dlc (or cf->len) in the RTR
>> case. Please create a separate patch that fixes this problem.
>>
>>>  	} else {
>>>  		id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
>>> -		cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
>>> -		*(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
>>> -							 M_CAN_FIFO_DATA(0));
>>> -		*(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
>>> -							 M_CAN_FIFO_DATA(1));
>>> +		if (dlc & RX_BUF_EDL)
>>> +			cf->len = can_dlc2len((id >> 16) & 0x0F);
>>> +		else
>>> +			cf->len = get_can_dlc((id >> 16) & 0x0F);
>>> +
> 
> Grr. I missed that one too :-(
> 
> Thanks for catching it.
> 
> As you committed patch 1 & 3 you expect a new single patch containing the
> (fixed) content of this patch 2, right?

No, please make it two patches:

First the Bugfix: One setting the cf->dlc in the RTR case, too.
Then the new feature: The other one adding CAN-FD support.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH v4 8/8] net: can: c_can: Add support for TI am3352 DCAN
From: Marc Kleine-Budde @ 2014-11-14  9:25 UTC (permalink / raw)
  To: Wolfram Sang, Roger Quadros
  Cc: wg, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
	sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <20141113160658.GB1275@katana>

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On 11/13/2014 05:06 PM, Wolfram Sang wrote:
> On Fri, Nov 07, 2014 at 04:49:22PM +0200, Roger Quadros wrote:
>> AM3352 SoC has 2 DCAN modules. Add compatible id and
>> raminit driver data for am3352 DCAN.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> 
> Acked-by: Wolfram Sang <wsa@the-dreams.de>

For the whole series or just this patch?

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* loan offer apply now at 2%, only serious replies needed
From: Barr. Mark Lewis @ 2014-11-14  0:50 UTC (permalink / raw)




Are you in need of any type of loan? of yes, kindly contact barrmarklewis13@gmail.com for more information. Thanks

^ permalink raw reply

* RE: [PATCHv2 net 2/4] be2net: Implement ndo_gso_check()
From: Sathya Perla @ 2014-11-14  9:43 UTC (permalink / raw)
  To: Joe Stringer, netdev@vger.kernel.org
  Cc: shahed.shaikh@qlogic.com, amirv@mellanox.com,
	Dept-GELinuxNICDev@qlogic.com, therbert@google.com,
	gerlitz.or@gmail.com, alexander.duyck@gmail.com,
	linux-kernel@vger.kernel.org
In-Reply-To: <1415925495-59312-3-git-send-email-joestringer@nicira.com>

> -----Original Message-----
> From: Joe Stringer [mailto:joestringer@nicira.com]
> 
> Use vxlan_gso_check() to advertise offload support for this NIC.
> 
> Signed-off-by: Joe Stringer <joestringer@nicira.com>

Acked-by: Sathya Perla <sperla@emulex.com>

Thanks!

> ---
> v2: Refactor out vxlan helper.
> ---
>  drivers/net/ethernet/emulex/benet/be_main.c |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 9a18e79..3e8475c 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -4421,6 +4421,11 @@ static void be_del_vxlan_port(struct net_device
> *netdev, sa_family_t sa_family,
>  		 "Disabled VxLAN offloads for UDP port %d\n",
>  		 be16_to_cpu(port));
>  }
> +
> +static bool be_gso_check(struct sk_buff *skb, struct net_device *dev)
> +{
> +	return vxlan_gso_check(skb);
> +}
>  #endif
> 
>  static const struct net_device_ops be_netdev_ops = {
> @@ -4450,6 +4455,7 @@ static const struct net_device_ops be_netdev_ops
> = {
>  #ifdef CONFIG_BE2NET_VXLAN
>  	.ndo_add_vxlan_port	= be_add_vxlan_port,
>  	.ndo_del_vxlan_port	= be_del_vxlan_port,
> +	.ndo_gso_check		= be_gso_check,
>  #endif
>  };
> 
> --
> 1.7.10.4

^ permalink raw reply

* Re: [PATCH Iproute2 next] ip link: Add ipvlan support to the iproute2/ip util
From: Michal Kubecek @ 2014-11-14 10:09 UTC (permalink / raw)
  To: Mahesh Bandewar
  Cc: netdev, Stephen Hemminger, Eric Dumazet, Maciej Zenczykowski,
	Laurent Chavey, Tim Hockin, David Miller, Brandon Philips,
	Pavel Emelianov
In-Reply-To: <1415948212-28927-1-git-send-email-maheshb@google.com>

On Thu, Nov 13, 2014 at 10:56:51PM -0800, Mahesh Bandewar wrote:
> Adding basic support to create virtual devices using 'ip'
> utility. Following is the syntax -
> 
> 	ip link add link <master> <virtual> mode [ l2 | l3 ]
> 	e.g. ip link add link eth0 ipvl0 mode l3

I suppose "type ipvlan" is missing on both lines.

Michal Kubecek

^ permalink raw reply

* Re: [PATCH 1/3] arch: Introduce load_acquire() and store_release()
From: Will Deacon @ 2014-11-14 10:19 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: linux-arch@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, mikey@neuling.org,
	tony.luck@intel.com, mathieu.desnoyers@polymtl.ca,
	donald.c.skidmore@intel.com, peterz@infradead.org,
	benh@kernel.crashing.org, heiko.carstens@de.ibm.com,
	oleg@redhat.com, davem@davemloft.net, michael@ellerman.id.au,
	matthew.vick@intel.com, nic_swsd@realtek.com,
	geert@linux-m68k.org, jeffrey.t.kirsher@intel.com
In-Reply-To: <20141113192723.12579.25343.stgit@ahduyck-server>

Hi Alex,

On Thu, Nov 13, 2014 at 07:27:23PM +0000, Alexander Duyck wrote:
> It is common for device drivers to make use of acquire/release semantics
> when dealing with descriptors stored in device memory.  On reviewing the
> documentation and code for smp_load_acquire() and smp_store_release() as
> well as reviewing an IBM website that goes over the use of PowerPC barriers
> at http://www.ibm.com/developerworks/systems/articles/powerpc.html it
> occurred to me that the same code could likely be applied to device drivers.
> 
> As a result this patch introduces load_acquire() and store_release().  The
> load_acquire() function can be used in the place of situations where a test
> for ownership must be followed by a memory barrier.  The below example is
> from ixgbe:
> 
>         if (!rx_desc->wb.upper.status_error)
>                 break;
> 
>         /* This memory barrier is needed to keep us from reading
>          * any other fields out of the rx_desc until we know the
>          * descriptor has been written back
>          */
>         rmb();
> 
> With load_acquire() this can be changed to:
> 
>         if (!load_acquire(&rx_desc->wb.upper.status_error))
>                 break;

I still don't think this is a good idea for the specific use-case you're
highlighting.

On ARM, an mb() can be *significantly* more expensive than an rmb() (since
we may have to drain store buffers on an outer L2 cache) and on arm64 it's
not at all clear that an LDAR is more efficient than an LDR; DMB LD
sequence. I can certainly imagine implementations where the latter would
be preferred.

So, whilst I'm perfectly fine to go along with mandatory acquire/release
macros (we should probably add a check to barf on __iomem pointers), I
don't agree with using them in preference to finer-grained read/write
barriers. Doing so will have a real impact on I/O performance.

Finally, do you know of any architectures where load_acquire/store_release
aren't implemented the same way as the smp_* variants on SMP kernels?

Will

^ permalink raw reply

* RE: [PATCH 1/3] arch: Introduce load_acquire() and store_release()
From: David Laight @ 2014-11-14 10:45 UTC (permalink / raw)
  To: 'Alexander Duyck', linux-arch@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
  Cc: mikey@neuling.org, tony.luck@intel.com,
	mathieu.desnoyers@polymtl.ca, donald.c.skidmore@intel.com,
	peterz@infradead.org, benh@kernel.crashing.org,
	heiko.carstens@de.ibm.com, oleg@redhat.com, will.deacon@arm.com,
	davem@davemloft.net, michael@ellerman.id.au,
	matthew.vick@intel.com, nic_swsd@realtek.com,
	geert@linux-m68k.org, jeffrey.t.kirsher@intel.com,
	fweisbec@gmail.com, schwidefsky@de.ibm.com,
	"linux@arm.linux.org.uk" <linux@
In-Reply-To: <20141113192723.12579.25343.stgit@ahduyck-server>

From: Alexander Duyck
> It is common for device drivers to make use of acquire/release semantics
> when dealing with descriptors stored in device memory.  On reviewing the
> documentation and code for smp_load_acquire() and smp_store_release() as
> well as reviewing an IBM website that goes over the use of PowerPC barriers
> at http://www.ibm.com/developerworks/systems/articles/powerpc.html it
> occurred to me that the same code could likely be applied to device drivers.
> 
> As a result this patch introduces load_acquire() and store_release().  The
> load_acquire() function can be used in the place of situations where a test
> for ownership must be followed by a memory barrier.  The below example is
> from ixgbe:
> 
> 	if (!rx_desc->wb.upper.status_error)
> 		break;
> 
> 	/* This memory barrier is needed to keep us from reading
> 	 * any other fields out of the rx_desc until we know the
> 	 * descriptor has been written back
> 	 */
> 	rmb();
> 
> With load_acquire() this can be changed to:
> 
> 	if (!load_acquire(&rx_desc->wb.upper.status_error))
> 		break;

If I'm quickly reading the 'new' code I need to look up yet another
function, with the 'old' code I can easily see the logic.

You've also added a memory barrier to the 'break' path - which isn't needed.

The driver might also have additional code that can be added before the barrier
so reducing the cost of the barrier.

The driver may also be able to perform multiple actions before a barrier is needed.

Hiding barriers isn't necessarily a good idea anyway.
If you are writing a driver you need to understand when and where they are needed.

Maybe you need a new (weaker) barrier to replace rmb() on some architectures.

...


	David


^ permalink raw reply

* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-14 10:56 UTC (permalink / raw)
  To: Dan Williams
  Cc: Greg KH, David S. Miller,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, Aleksander Morgado
In-Reply-To: <CA+icZUW2iRkoAK10ayJ9PFuFGWBQzKdFe+8mfd=8oKkAp1txtg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek <sedat.dilek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>>> Hi,
>>>
>>> I wanted to understand what is going on the kernel-side when
>>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>>> Generation: UMTS / HSPA).
>>>
>>> Especially the correlation between the diverse USB/NET kernel-drivers
>>> and how the networking is setup.
>>
>
> [ Sitting in front of a foreign Windows machine ]
>
> [ CC Aleksander ]
>
> Hi Dan,
>
> sorry for the late (and short) response.
>
> AFAICS you have given a "skeleton" for a "usb-wwan-networking"
> documentation :-).
>
> Personally, I would like to take into account some kernel-config
> options and some more things.
>

I started with documenting...

I have still some difficulties in understanding USB WWAN Networking.
So, this is what I revealed...

##### USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK

### USB-NETWORKING AND WWAN SETUP
CONFIG_USB_USBNET=m        <--- usb networking
CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"

### PPP OPTIONS
CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_ASYNC=m

Beyond the PPP options, I wanted to understand what
CONFIG_USB_NET_CDCETHER does and why I need it.
Can someone help?

Thanks.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/Kconfig#n189

P.S.: cdc_ether Kconfig option and checking my logs

>From [1]...
...
config USB_NET_CDCETHER
tristate "CDC Ethernet support (smart devices such as cable modems)"
depends on USB_USBNET
default y
help
 This option supports devices conforming to the Communication Device
 Class (CDC) Ethernet Control Model, a specification that's easy to
 implement in device firmware.  The CDC specifications are available
 from <http://www.usb.org/>.

 CDC Ethernet is an implementation option for DOCSIS cable modems
 that support USB connectivity, used for non-Microsoft USB hosts.
 The Linux-USB CDC Ethernet Gadget driver is an open implementation.
   This driver should work with at least the following devices:

   * Dell Wireless 5530 HSPA
     * Ericsson PipeRider (all variants)
   * Ericsson Mobile Broadband Module (all variants)
     * Motorola (DM100 and SB4100)
     * Broadcom Cable Modem (reference design)
   * Toshiba (PCX1100U and F3507g/F3607gw)
   * ...

 This driver creates an interface named "ethX", where X depends on
 what other networking devices you have in use.  However, if the
 IEEE 802 "local assignment" bit is set in the address, a "usbX"
 name is used instead.
...

>From my logs...

$ dmesg | egrep -i 'option|wwan|ppp|3-1.2|huawei|gsm|modem'
[    0.000000] please try 'cgroup_disable=memory' option if you don't
want memory cgroups
[    0.549498] PPP generic driver version 2.4.2
[    1.299059] usb 3-1.2: new high-speed USB device number 3 using ehci-pci
[    1.394084] usb 3-1.2: New USB device found, idVendor=12d1, idProduct=1436
[    1.394095] usb 3-1.2: New USB device strings: Mfr=4, Product=3,
SerialNumber=0
[    1.394100] usb 3-1.2: Product: HUAWEI Mobile
[    1.394103] usb 3-1.2: Manufacturer: HUAWEI Technology
[    2.115424] usb-storage 3-1.2:1.0: USB Mass Storage device detected
[    2.125026] usb-storage 3-1.2:1.1: USB Mass Storage device detected
[    2.125607] usb-storage 3-1.2:1.2: USB Mass Storage device detected
[    2.125888] usb-storage 3-1.2:1.3: USB Mass Storage device detected
[    2.126187] usb-storage 3-1.2:1.4: USB Mass Storage device detected
[    2.126461] usb-storage 3-1.2:1.5: USB Mass Storage device detected
[    2.127098] scsi host11: usb-storage 3-1.2:1.5
[    2.129370] usb-storage 3-1.2:1.6: USB Mass Storage device detected
[    2.131685] scsi host12: usb-storage 3-1.2:1.6
[    3.127317] scsi 11:0:0:0: CD-ROM            HUAWEI   Mass Storage
   2.31 PQ: 0 ANSI: 2
[    3.137589] scsi 12:0:0:0: Direct-Access     HUAWEI   SD Storage
   2.31 PQ: 0 ANSI: 2
[   13.500302] cdc_ether 3-1.2:1.1 wwan0: register 'cdc_ether' at
usb-0000:00:1a.0-1.2, Mobile Broadband Network Device,
02:50:f3:00:00:00
[   14.160221] usbcore: registered new interface driver option
[   14.160820] usbserial: USB Serial support registered for GSM modem (1-port)
[   14.160940] option 3-1.2:1.0: GSM modem (1-port) converter detected
[   14.163032] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB0
[   14.163305] option 3-1.2:1.3: GSM modem (1-port) converter detected
[   14.163676] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB1
[   14.163742] option 3-1.2:1.4: GSM modem (1-port) converter detected
[   14.165227] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB2
[   72.877065] PPP BSD Compression module registered
[   72.881701] PPP Deflate Compression module registered
- EOT -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: net-next panic in ovs call to arch_fast_hash2 since e5a2c899
From: Hannes Frederic Sowa @ 2014-11-14 11:10 UTC (permalink / raw)
  To: Jay Vosburgh; +Cc: David Miller, netdev, discuss, pshelar, ogerlitz
In-Reply-To: <12872.1415941444@famine>

Hi Jay,

On Do, 2014-11-13 at 21:04 -0800, Jay Vosburgh wrote:
> 	[ adding Hannes to Cc, which I should've done initially ]
> 
> David Miller <davem@davemloft.net> wrote:
> 
> >From: Jay Vosburgh <jay.vosburgh@canonical.com>
> >Date: Thu, 13 Nov 2014 18:15:32 -0800
> >
> >> 	The "have feature" function, __intel_crc4_2_hash2, does not
> >> clobber %r8, and so the call does not panic on a system with
> >> X86_FEATURE_XMM4_2, although I'm not sure if that's a deliberate
> >> compiler action or just happenstance because __intel_crc4_2_hash2 uses
> >> fewer registers than __jhash2.
> >
> >Perhaps alternative calls can only be used with assembler routines
> >that use specific calling conventions, and they therefore generally
> >don't work with C functions?
> 
> 	I don't know the answer to that, but a quick search suggests
> that arch_fast_hash and arch_fast_hash2 (both added by commit e5a2c899)
> may be the only cases of alternative calls that aren't supplying either
> single instructions or assembly language functions.
> 
> 	From looking at how the alternative calls are implemented (code
> patching at boot or module load time from a table stored in a special
> section of the object file), I'm skeptical that the compiler could know
> what's the right thing to do.
> 
> 	Hannes, can you shed any light on this?

Unfortunately I only tested this code with rhashtable, which itself
takes a function pointer to arch_fast_hash and thus doesn't need to care
about clobbering so much. As a first step, I am currently testing this
patch as a first step and check thoroughly. Thanks for the report:

diff --git a/arch/x86/include/asm/hash.h b/arch/x86/include/asm/hash.h
index a881d78..1b32c82 100644
--- a/arch/x86/include/asm/hash.h
+++ b/arch/x86/include/asm/hash.h
@@ -4,45 +4,12 @@
 #include <linux/cpufeature.h>
 #include <asm/alternative.h>
 
-u32 __intel_crc4_2_hash(const void *data, u32 len, u32 seed);
-u32 __intel_crc4_2_hash2(const u32 *data, u32 len, u32 seed);
-
-/*
- * non-inline versions of jhash so gcc does not need to generate
- * duplicate code in every object file
- */
-u32 __jhash(const void *data, u32 len, u32 seed);
-u32 __jhash2(const u32 *data, u32 len, u32 seed);
-
 /*
  * for documentation of these functions please look into
  * <include/asm-generic/hash.h>
  */
 
-static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
-{
-       u32 hash;
-
-       alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
-#ifdef CONFIG_X86_64
-                        "=a" (hash), "D" (data), "S" (len), "d" (seed));
-#else
-                        "=a" (hash), "a" (data), "d" (len), "c" (seed));
-#endif
-       return hash;
-}
-
-static inline u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
-{
-       u32 hash;
-
-       alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
-#ifdef CONFIG_X86_64
-                        "=a" (hash), "D" (data), "S" (len), "d" (seed));
-#else
-                        "=a" (hash), "a" (data), "d" (len), "c" (seed));
-#endif
-       return hash;
-}
+u32 arch_fast_hash(const void *data, u32 len, u32 seed);
+u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed);
 
 #endif /* __ASM_X86_HASH_H */
diff --git a/arch/x86/lib/hash.c b/arch/x86/lib/hash.c
index e143271..a0a7a7e 100644
--- a/arch/x86/lib/hash.c
+++ b/arch/x86/lib/hash.c
@@ -38,7 +38,7 @@
 #include <linux/hash.h>
 #include <linux/jhash.h>
 
-static inline u32 crc32_u32(u32 crc, u32 val)
+static u32 crc32_u32(u32 crc, u32 val)
 {
 #ifdef CONFIG_AS_CRC32
        asm ("crc32l %1,%0\n" : "+r" (crc) : "rm" (val));
@@ -71,7 +71,6 @@ u32 __intel_crc4_2_hash(const void *data, u32 len, u32 seed)
 
        return seed;
 }
-EXPORT_SYMBOL(__intel_crc4_2_hash);
 
 u32 __intel_crc4_2_hash2(const u32 *data, u32 len, u32 seed)
 {
@@ -82,16 +81,45 @@ u32 __intel_crc4_2_hash2(const u32 *data, u32 len, u32 seed)
 
        return seed;
 }
-EXPORT_SYMBOL(__intel_crc4_2_hash2);
 
 u32 __jhash(const void *data, u32 len, u32 seed)
 {
        return jhash(data, len, seed);
 }
-EXPORT_SYMBOL(__jhash);
 
 u32 __jhash2(const u32 *data, u32 len, u32 seed)
 {
        return jhash2(data, len, seed);
 }
-EXPORT_SYMBOL(__jhash2);
+
+noinline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
+{
+       u32 hash;
+
+
+#ifdef CONFIG_X86_64
+       alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+                        "=a" (hash), "D" (data), "S" (len), "d" (seed));
+#else
+       alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+                        "=a" (hash), "a" (data), "d" (len), "c" (seed));
+#endif
+       return hash;
+}
+EXPORT_SYMBOL(arch_fast_hash);
+
+noinline u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
+{
+       u32 hash;
+
+
+#ifdef CONFIG_X86_64
+       alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+                        "=a" (hash), "D" (data), "S" (len), "d" (seed));
+#else
+       alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+                        "=a" (hash), "a" (data), "d" (len), "c" (seed));
+#endif
+       return hash;
+}
+EXPORT_SYMBOL(arch_fast_hash2);

^ permalink raw reply related

* [PATCH net] ipv4: Fix incorrect error code when adding an unreachable route
From: Panu Matilainen @ 2014-11-14 11:14 UTC (permalink / raw)
  To: netdev

Trying to add an unreachable route incorrectly returns -ESRCH if
if custom FIB rules are present:

[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: Network is unreachable
[root@localhost ~]# ip rule add to 55.66.77.88 table 200
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: No such process
[root@localhost ~]#

Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
return value for rule lookup") changed fib_rules_lookup()
to use -ESRCH as a "not found" code internally, but for user space it
should be translated into -ENETUNREACH. Handle the translation centrally in
ipv4-specific fib_lookup(), leaving the DECnet case alone.

On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
("ipv4: removed redundant conditional") removed a similar translation from
ip_route_input_slow() prematurely AIUI.

Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
 net/ipv4/fib_rules.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index f2e1573..8f7bd56 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -62,6 +62,10 @@ int __fib_lookup(struct net *net, struct flowi4 *flp, struct fib_result *res)
 	else
 		res->tclassid = 0;
 #endif
+
+	if (err == -ESRCH)
+		err = -ENETUNREACH;
+
 	return err;
 }
 EXPORT_SYMBOL_GPL(__fib_lookup);
-- 
1.9.3

^ permalink raw reply related

* Re: [PATCH 19/22] dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
From: Johan Hovold @ 2014-11-14 11:21 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: Johan Hovold, Mark Rutland, Florian Fainelli, David S. Miller,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org
In-Reply-To: <20141113080927.GP30369@pengutronix.de>

On Thu, Nov 13, 2014 at 09:09:27AM +0100, Sascha Hauer wrote:
> On Wed, Nov 12, 2014 at 10:19:20AM +0100, Johan Hovold wrote:
> > On Wed, Nov 12, 2014 at 08:01:27AM +0100, Sascha Hauer wrote:
> > > On Tue, Nov 11, 2014 at 07:18:25PM +0100, Johan Hovold wrote:
> > > > On Tue, Nov 11, 2014 at 05:57:42PM +0000, Mark Rutland wrote:
> > > > > On Tue, Nov 11, 2014 at 05:37:37PM +0000, Johan Hovold wrote:
> > > > > > Add "micrel,rmii_ref_clk_sel_25_mhz" to Micrel ethernet PHY binding
> > > > > > documentation.
> > > > > > 
> > > > > > Cc: devicetree@vger.kernel.org
> > > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/net/micrel.txt | 5 +++++
> > > > > >  1 file changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> > > > > > index a1bab5eaae02..9b08dd6551dd 100644
> > > > > > --- a/Documentation/devicetree/bindings/net/micrel.txt
> > > > > > +++ b/Documentation/devicetree/bindings/net/micrel.txt
> > > > > > @@ -19,6 +19,11 @@ Optional properties:
> > > > > >  
> > > > > >                See the respective PHY datasheet for the mode values.
> > > > > >  
> > > > > > + - micrel,rmii_ref_clk_sel_25_mhz: rmii_ref_clk_sel bit selects 25 MHz mode
> > > > > > +
> > > > > > +		Whether 25 MHz (rather than 50 Mhz) clock mode is selected
> > > > > > +		when the rmii_ref_clk_sel bit is set.
> > > > > 
> > > > > s/_/-/ in property names please.
> > > > 
> > > > Ouch, copied from variable name, sorry.
> > > > 
> > > > > That said, I don't follow the meaning. Does this cause the kernel to do
> > > > > something different, or is is simply that a 25MHz ref clock is wired up?
> > > > 
> > > > Yes, the driver currently sets this configuration bit based on a common
> > > > clock binding.
> > > > 
> > > > However, it turns out the meaning of the bit is reversed on some PHY
> > > > variants. On most PHYs 50 MHz mode is selected by setting this bit,
> > > > whereas on the PHYs that need this new property, setting it selects 25
> > > > MHz mode instead.
> > > 
> > > Maybe rename the property to something like rmii-ref-clk-25mhz-active-high
> > > then? Also you should probably make it more explicit that this is a
> > > hardware property and not for adjusting the clock.
> > 
> > You're right, but how about calling it
> > 
> > 	micrel,rmii-reference-clock-select-inverted
> > 
> > Then no one will set it believing it will change the clock mode and
> > without reading the binding doc first.
> > 
> > The description could then read something like
> > 
> > 	micrel,rmii-reference-clock-select-inverted: RMII Reference
> > 		Clock Select bit is inverted
> > 
> > 	The RMII Reference Clock Select bit is inverted so that setting
> > 	it selects 25 MHz rather than 50 MHz clock mode. 
> > 
> > 	Note that this is only needed for PHY variants that has this bit
> > 	inverted and that a clock reference ("rmii-ref" below) is always
> > 	needed to select the actual mode.
> 
> "Inverted" only has a meaning when everybody agrees what's the normal
> case. Since that not the case I really prefer talking about
> "active-high" or "active-low".

Yes, but I'm reluctant to using "active-high" and "active-low" as this
is not a signal (or IO pin) we're dealing with.

It's a configuration bit, which (if set) selects 25 MHz mode. Hence I
still think something like 

	micrel,rmii_ref_clk_sel_25_mhz

or

	micrel,rmii_reference_clock_select_selects_25_mhz

is preferred. The binding documentation will still make it clear that a
clocks reference is also needed.

Johan

^ permalink raw reply

* Re: [PATCH v4 8/8] net: can: c_can: Add support for TI am3352 DCAN
From: Wolfram Sang @ 2014-11-14 11:26 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Roger Quadros, wg, tony, tglx, mugunthanvnm, george.cherian,
	balbi, nsekhar, nm, sergei.shtylyov, linux-omap, linux-can,
	netdev
In-Reply-To: <5465CAA3.5030301@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Fri, Nov 14, 2014 at 10:25:55AM +0100, Marc Kleine-Budde wrote:
> On 11/13/2014 05:06 PM, Wolfram Sang wrote:
> > On Fri, Nov 07, 2014 at 04:49:22PM +0200, Roger Quadros wrote:
> >> AM3352 SoC has 2 DCAN modules. Add compatible id and
> >> raminit driver data for am3352 DCAN.
> >>
> >> Signed-off-by: Roger Quadros <rogerq@ti.com>
> > 
> > Acked-by: Wolfram Sang <wsa@the-dreams.de>
> 
> For the whole series or just this patch?

Just this one.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH 0/2] xfrm: Do not hash socket policies
From: Steffen Klassert @ 2014-11-14 11:36 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20141113090811.GA3280@gondor.apana.org.au>

On Thu, Nov 13, 2014 at 05:08:11PM +0800, Herbert Xu wrote:
> On Thu, Nov 13, 2014 at 05:00:48PM +0800, Herbert Xu wrote:
> > Hi Steffen:
> > 
> > I'm working on converting the xfrm policy hashing over to RCU
> > due to performance complaints.  While doing this I noticed that
> > we're needlessly hashing socket policies.
> > 
> > Here are two patches to get rid of that and slightly clean things
> > up.
> 
> Oops that didn't work very well as I left out some rather important
> bits :)
> 
> Here is a second revision.

Both applied to ipsec-next, thanks Herbert!

^ permalink raw reply

* Re: [PATCH v2 net-next 1/7] bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
From: Hannes Frederic Sowa @ 2014-11-14 12:11 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: David S. Miller, Ingo Molnar, Andy Lutomirski, Daniel Borkmann,
	Eric Dumazet, linux-api-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415929010-9361-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>

On Do, 2014-11-13 at 17:36 -0800, Alexei Starovoitov wrote:
> the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
> either update existing map element or create a new one.
> Initially the plan was to add a new command to handle the case of
> 'create new element if it didn't exist', but 'flags' style looks
> cleaner and overall diff is much smaller (more code reused), so add 'flags'
> attribute to BPF_MAP_UPDATE_ELEM command with the following meaning:
>  #define BPF_ANY	0 /* create new element or update existing */
>  #define BPF_NOEXIST	1 /* create new element if it didn't exist */
>  #define BPF_EXIST	2 /* update existing element */

Would a cmpxchg-alike function be handy here?

Bye,
Hannes

^ permalink raw reply

* Re: linux-next: ath9k: build failure, ath_cmn_process_fft() redefinition
From: Oleksij Rempel @ 2014-11-14 12:30 UTC (permalink / raw)
  To: Jeremiah Mahler, linux-kernel, ath9k-devel, linville,
	linux-wireless, ath9k-devel, netdev
In-Reply-To: <20141114000747.GA6865@hudson.localdomain>


[-- Attachment #1.1: Type: text/plain, Size: 5068 bytes --]

Thank you,

fixes are queued for review.

Am 14.11.2014 um 01:07 schrieb Jeremiah Mahler:
> 
> In version 20141113 of the linux-next kernel, if it is compiled with
> CONFIG_ATH9K_DEBUGFS unset, an error about ath_cmn_process_fft() being
> redefined will be produced.
> 
>   make
>   ...
>     LD [M]  drivers/net/wireless/ath/ath9k/ath9k_hw.o
>     CC [M]  drivers/net/wireless/ath/ath9k/common-spectral.o
>     CC      lib/debug_locks.o
>     CC      lib/random32.o
>   drivers/net/wireless/ath/ath9k/common-spectral.c:40:5: error:
>   redefinition of ‘ath_cmn_process_fft’
>    int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct
>   ieee80211_hdr *hdr,
>        ^
>   In file included from drivers/net/wireless/ath/ath9k/common.h:27:0,
>                    from drivers/net/wireless/ath/ath9k/ath9k.h:27,
>                    from
>   drivers/net/wireless/ath/ath9k/common-spectral.c:18:
>   drivers/net/wireless/ath/ath9k/common-spectral.h:146:19: note: previous
>   definition of ‘ath_cmn_process_fft’ was here
>    static inline int ath_cmn_process_fft(struct ath_spec_scan_priv
>   *spec_priv,
>                      ^
>   scripts/Makefile.build:257: recipe for target
>   'drivers/net/wireless/ath/ath9k/common-spectral.o' failed
>   make[5]: *** [drivers/net/wireless/ath/ath9k/common-spectral.o] Error 1
>   scripts/Makefile.build:402: recipe for target
>   'drivers/net/wireless/ath/ath9k' failed
>   make[4]: *** [drivers/net/wireless/ath/ath9k] Error 2
>   scripts/Makefile.build:402: recipe for target 'drivers/net/wireless/ath'
>   failed
>   make[3]: *** [drivers/net/wireless/ath] Error 2
>   scripts/Makefile.build:402: recipe for target 'drivers/net/wireless'
>   failed
>   make[2]: *** [drivers/net/wireless] Error 2
>   scripts/Makefile.build:402: recipe for target 'drivers/net' failed
>   make[1]: *** [drivers/net] Error 2
>   Makefile:953: recipe for target 'drivers' failed
>   make: *** [drivers] Error 2
>   make: *** Waiting for unfinished jobs....
>     CC      lib/bust_spinlocks.o
>   ...
> 
> Bisecting the kernel found that the following patch was the cause.
> 
>   commit 67dc74f15f147b9f88702de2952d2951e3e000ec
>   Author: Oleksij Rempel <linux@rempel-privat.de>
>   Date:   Thu Nov 6 08:53:30 2014 +0100
>   
>       ath9k: move spectral.* to common-spectral.*
>       
>       and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*
>       
>       Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>       Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> This patch mostly consists of renaming functions and moving code but
> there was a functional change to the Makefile.
> 
> common-spectral.h uses CONFIG_ATH9K_DEBUGFS to conditionally provide a
> prototype of ath_cmn_process_fft() when set or to define it as a noop
> when it is unset.  The Makefile was changed so that CONFIG_ATH9K_DEBUGFS
> no longer applied to common-spectral and this will result in two
> definitions of ath_cmn_process_fft().
> 
>   > --- a/drivers/net/wireless/ath/ath9k/Makefile
>   > +++ b/drivers/net/wireless/ath/ath9k/Makefile
>   > @@ -16,8 +16,7 @@ ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
>   >  ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
>   >  ath9k-$(CONFIG_ATH9K_WOW) += wow.o
>   >
>   > -ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o \
>   > -                                spectral.o
>   > +ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
>   >
>   >  ath9k-$(CONFIG_ATH9K_STATION_STATISTICS) += debug_sta.o
>   >
>   > @@ -59,7 +58,8 @@ obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o
>   >  ath9k_common-y:=       common.o \
>   >                         common-init.o \
>   >                         common-beacon.o \
>   > -                       common-debug.o
>   > +                       common-debug.o \
>   > +                       common-spectral.o
> 
> Reverting the patch solves one error, but then a new one is produced.
> 
>   make
>   ...
>     MODPOST 185 modules
>     CC      arch/x86/boot/edd.o
>     VOFFSET arch/x86/boot/voffset.h
>   ERROR: "ath9k_cmn_spectral_scan_trigger"
>   [drivers/net/wireless/ath/ath9k/ath9k.ko] undefined!
>   scripts/Makefile.modpost:90: recipe for target '__modpost' failed
>   make[1]: *** [__modpost] Error 1
>   ...
> 
> This error is caused by the patch before it.
> 
>   commit f00a422cc81ef665f5098c0bc43cb0c616e55a9b
>   Author: Oleksij Rempel <linux@rempel-privat.de>
>   Date:   Thu Nov 6 08:53:29 2014 +0100
>   
>       ath9k: move ath9k_spectral_scan_ from main.c to spectral.c
>       
>       Now we should be ready to make this code common.
>       
>       Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>       Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> Since the code was moved from main.c to spectral.c, it is now involved
> with CONFIG_ATH9K_DEBUGFS, which causes it to break.
> 
> Reverting both the above patches resolves the build errors.
> 


-- 
Regards,
Oleksij


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

^ permalink raw reply

* Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-14 13:43 UTC (permalink / raw)
  To: Marc Kleine-Budde, wg, Linus Walleij
  Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
	sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <5464D661.7080505@pengutronix.de>

On 11/13/2014 06:03 PM, Marc Kleine-Budde wrote:
> On 11/13/2014 04:23 PM, Roger Quadros wrote:
>> DRA7 CAN IP suffers from a problem which causes it to be prevented
>> from fully turning OFF (i.e. stuck in transition) if the module was
>> disabled while there was traffic on the CAN_RX line.
>>
>> To work around this issue we select the SLEEP pin state by default
>> on probe and use the DEFAULT pin state on CAN up and back to the
>> SLEEP pin state on CAN down.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/net/can/c_can/c_can.c | 37 +++++++++++++++++++++++++++++++++++++
>>  drivers/net/can/c_can/c_can.h |  1 +
>>  2 files changed, 38 insertions(+)
>>
>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>> index 8e78bb4..c80cb3d 100644
>> --- a/drivers/net/can/c_can/c_can.c
>> +++ b/drivers/net/can/c_can/c_can.c
>> @@ -35,6 +35,7 @@
>>  #include <linux/list.h>
>>  #include <linux/io.h>
>>  #include <linux/pm_runtime.h>
>> +#include <linux/pinctrl/consumer.h>
>>  
>>  #include <linux/can.h>
>>  #include <linux/can/dev.h>
>> @@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
>>  	return c_can_set_bittiming(dev);
>>  }
>>  
>> +/*
>> + * Selects the pinctrl state specified in the name.
>> + */
>> +static void c_can_pinctrl_select_state(struct c_can_priv *priv,
>> +				      const char *name)
>> +{
>> +	if (!IS_ERR(priv->pinctrl)) {
>> +		struct pinctrl_state *s;
>> +
>> +		s = pinctrl_lookup_state(priv->pinctrl, name);
>> +		if (!IS_ERR(s))
>> +			pinctrl_select_state(priv->pinctrl, s);
>> +	}
>> +}
>> +
>>  static int c_can_start(struct net_device *dev)
>>  {
>>  	struct c_can_priv *priv = netdev_priv(dev);
>> @@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
>>  
>>  	priv->can.state = CAN_STATE_ERROR_ACTIVE;
>>  
>> +	/* activate pins */
>> +	c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
>>  	return 0;
>>  }
>>  
>> @@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
>>  	struct c_can_priv *priv = netdev_priv(dev);
>>  
>>  	c_can_irq_control(priv, false);
>> +
>> +	/* deactivate pins */
>> +	c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
>>  	priv->can.state = CAN_STATE_STOPPED;
>>  }
>>  
>> @@ -1244,6 +1265,22 @@ int register_c_can_dev(struct net_device *dev)
>>  	struct c_can_priv *priv = netdev_priv(dev);
>>  	int err;
>>  
>> +	priv->pinctrl = devm_pinctrl_get(dev->dev.parent);
> 
> What's dev->dev.parent?
> Ah, this is set by SET_NETDEV_DEV(dev, &pdev->dev); Good work!
> 
> I thought we had to set priv->pinctrl in the platform.c.
> 
>> +	if (!IS_ERR(priv->pinctrl)) {
>> +		struct pinctrl_state *s;
>> +
>> +		/* Deactivate pins to prevent DRA7 DCAN IP from being
>> +		 * stuck in transition when module is disabled.
>> +		 * Pins are activated in c_can_start() and deactivated
>> +		 * in c_can_stop()
>> +		 */
>> +		s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_SLEEP);
>> +		if (!IS_ERR(s))
>> +			pinctrl_select_state(priv->pinctrl, s);
>> +	} else {
>> +		netdev_dbg(dev, "failed to get pinctrl\n");
>> +	}
>> +
> The above can be replace by this?
> 
> 	c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP)

Yes, indeed.

> 
> Then we don't have the worrying looking error message if there isn't any
> pinctrl, e.g. for the PCI driver with pinctrl enabled in the Kernel.
> 
> I just stumbled over pinctrl_pm_select_sleep_state(), is it possible to
> integrate this into runtime pm?
> 
> http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1282

I think those functions are there for the same reason but not sure why aren't 
they used in runtime pm core.

Linus W. any hints?

cheers,
-roger

> 
>>  	c_can_pm_runtime_enable(priv);
>>  
>>  	dev->flags |= IFF_ECHO;	/* we support local echo */
>> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
>> index c6715ca..3cedf48 100644
>> --- a/drivers/net/can/c_can/c_can.h
>> +++ b/drivers/net/can/c_can/c_can.h
>> @@ -210,6 +210,7 @@ struct c_can_priv {
>>  	u32 comm_rcv_high;
>>  	u32 rxmasked;
>>  	u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
>> +	struct pinctrl *pinctrl;
>>  };
>>  
>>  struct net_device *alloc_c_can_dev(void);
>>
> 
> Marc
> 


^ permalink raw reply

* [PATCH net-next] fast_hash: clobber registers correctly for inline function use
From: Hannes Frederic Sowa @ 2014-11-14 14:06 UTC (permalink / raw)
  To: netdev; +Cc: ogerlitz, pshelar, jesse, jay.vosburgh, discuss

In case the arch_fast_hash call gets inlined we need to tell gcc which
registers are clobbered with. Most callers where fine, as rhashtable
used arch_fast_hash via function pointer and thus the compiler took care
of that. In case of openvswitch the call got inlined and arch_fast_hash
touched registeres which gcc didn't know about.

Also don't use conditional compilation inside arguments, as this confuses
sparse.

Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Pravin Shelar <pshelar@nicira.com>
Cc: Jesse Gross <jesse@nicira.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 arch/x86/include/asm/hash.h | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/hash.h b/arch/x86/include/asm/hash.h
index a881d78..771cee0 100644
--- a/arch/x86/include/asm/hash.h
+++ b/arch/x86/include/asm/hash.h
@@ -23,11 +23,14 @@ static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
 {
 	u32 hash;
 
-	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
 #ifdef CONFIG_X86_64
-			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
+	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
+			 : "rcx", "r8", "r9", "r10", "r11", "cc", "memory");
 #else
-			 "=a" (hash), "a" (data), "d" (len), "c" (seed));
+	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "a" (data), "d" (len), "c" (seed)
+			 : "cc", "memory");
 #endif
 	return hash;
 }
@@ -36,11 +39,14 @@ static inline u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
 {
 	u32 hash;
 
-	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
 #ifdef CONFIG_X86_64
-			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
+	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
+			 : "rcx", "r8", "r9", "r10", "r11", "cc", "memory");
 #else
-			 "=a" (hash), "a" (data), "d" (len), "c" (seed));
+	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "a" (data), "d" (len), "c" (seed)
+			 : "cc", "memory");
 #endif
 	return hash;
 }
-- 
1.9.3

^ permalink raw reply related

* [PATCH net] reciprocal_div: objects with exported symbols should be obj-y rather than lib-y
From: Hannes Frederic Sowa @ 2014-11-14 14:16 UTC (permalink / raw)
  To: netdev; +Cc: jim.epost

Otherwise the exported symbols might be discarded because of no users
in vmlinux.

Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Makefile b/lib/Makefile
index 04e53dd..4b9baa4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -10,7 +10,7 @@ endif
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 rbtree.o radix-tree.o dump_stack.o timerqueue.o\
 	 idr.o int_sqrt.o extable.o \
-	 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
+	 sha1.o md5.o irq_regs.o argv_split.o \
 	 proportions.o flex_proportions.o ratelimit.o show_mem.o \
 	 is_single_threaded.o plist.o decompress.o kobject_uevent.o \
 	 earlycpio.o
@@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
 	 bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
 	 gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
 	 bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
-	 percpu-refcount.o percpu_ida.o rhashtable.o
+	 percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o
 obj-y += string_helpers.o
 obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
 obj-y += kstrtox.o
-- 
1.9.3

^ permalink raw reply related

* [PATCH net-next v2] fast_hash: clobber registers correctly for inline function use
From: Hannes Frederic Sowa @ 2014-11-14 14:40 UTC (permalink / raw)
  To: netdev; +Cc: ogerlitz, pshelar, jesse, jay.vosburgh, discuss
In-Reply-To: <4086c7bc9f7f9e8e2de9656c9e27ef1e71bb6423.1415973706.git.hannes@stressinduktion.org>

In case the arch_fast_hash call gets inlined we need to tell gcc which
registers are clobbered with. rhashtable was fine, because it used
arch_fast_hash via function pointer and thus the compiler took care of
that. In case of openvswitch the call got inlined and arch_fast_hash
touched registeres which gcc didn't know about.

Also don't use conditional compilation inside arguments, as this confuses
sparse.

Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Pravin Shelar <pshelar@nicira.com>
Cc: Jesse Gross <jesse@nicira.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---

v2)
After studying gcc documentation again, it occured to me that I need to
specificy all input operands in the clobber section, too. Otherwise gcc
can expect that the inline assembler section won't modify the inputs,
which is not true.

Bye,
Hannes


 arch/x86/include/asm/hash.h | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/hash.h b/arch/x86/include/asm/hash.h
index a881d78..a25c45a 100644
--- a/arch/x86/include/asm/hash.h
+++ b/arch/x86/include/asm/hash.h
@@ -23,11 +23,15 @@ static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
 {
 	u32 hash;
 
-	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
 #ifdef CONFIG_X86_64
-			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
+	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
+			 : "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r10", "r11",
+			   "cc", "memory");
 #else
-			 "=a" (hash), "a" (data), "d" (len), "c" (seed));
+	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "a" (data), "d" (len), "c" (seed)
+			 : "edx", "ecx", "cc", "memory");
 #endif
 	return hash;
 }
@@ -36,11 +40,15 @@ static inline u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
 {
 	u32 hash;
 
-	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
 #ifdef CONFIG_X86_64
-			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
+	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
+			 : "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r10", "r11",
+			   "cc", "memory");
 #else
-			 "=a" (hash), "a" (data), "d" (len), "c" (seed));
+	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
+			 "=a" (hash), "a" (data), "d" (len), "c" (seed)
+			 : "edx", "ecx", "cc", "memory");
 #endif
 	return hash;
 }
-- 
1.9.3

^ permalink raw reply related

* [PATCH 1/1] drivers: net: cpsw: Fix TX_IN_SEL offset
From: John Ogness @ 2014-11-14 14:42 UTC (permalink / raw)
  To: linux-kernel
  Cc: davem, mugunthanvnm, balbi, george.cherian, jhovold, mpa,
	bhutchings, zonque, tklauser, netdev

The TX_IN_SEL offset for the CPSW_PORT/TX_IN_CTL register was
incorrect. This caused the Dual MAC mode to never get set when
it should. It also caused possible unintentional setting of a
bit in the CPSW_PORT/TX_BLKS_REM register.

The purpose of setting the Dual MAC mode for this register is to:

    "... allow packets from both ethernet ports to be written into
     the FIFO without one port starving the other port."
					- AM335x ARM TRM

Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 drivers/net/ethernet/ti/cpsw.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index d879448..c560f9a 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -129,9 +129,9 @@ do {								\
 #define CPSW_VLAN_AWARE		BIT(1)
 #define CPSW_ALE_VLAN_AWARE	1
 
-#define CPSW_FIFO_NORMAL_MODE		(0 << 15)
-#define CPSW_FIFO_DUAL_MAC_MODE		(1 << 15)
-#define CPSW_FIFO_RATE_LIMIT_MODE	(2 << 15)
+#define CPSW_FIFO_NORMAL_MODE		(0 << 16)
+#define CPSW_FIFO_DUAL_MAC_MODE		(1 << 16)
+#define CPSW_FIFO_RATE_LIMIT_MODE	(2 << 16)
 
 #define CPSW_INTPACEEN		(0x3f << 16)
 #define CPSW_INTPRESCALE_MASK	(0x7FF << 0)
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH net-next] fast_hash: clobber registers correctly for inline function use
From: Eric Dumazet @ 2014-11-14 14:50 UTC (permalink / raw)
  To: Hannes Frederic Sowa
  Cc: netdev, ogerlitz, pshelar, jesse, jay.vosburgh, discuss
In-Reply-To: <4086c7bc9f7f9e8e2de9656c9e27ef1e71bb6423.1415973706.git.hannes@stressinduktion.org>

On Fri, 2014-11-14 at 15:06 +0100, Hannes Frederic Sowa wrote:
> In case the arch_fast_hash call gets inlined we need to tell gcc which
> registers are clobbered with. Most callers where fine, as rhashtable
> used arch_fast_hash via function pointer and thus the compiler took care
> of that. In case of openvswitch the call got inlined and arch_fast_hash
> touched registeres which gcc didn't know about.
> 
> Also don't use conditional compilation inside arguments, as this confuses
> sparse.
> 

Please add a 
Fixes: 12-sha1 ("patch title")

> Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
> Cc: Pravin Shelar <pshelar@nicira.com>
> Cc: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
>  arch/x86/include/asm/hash.h | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/hash.h b/arch/x86/include/asm/hash.h
> index a881d78..771cee0 100644
> --- a/arch/x86/include/asm/hash.h
> +++ b/arch/x86/include/asm/hash.h
> @@ -23,11 +23,14 @@ static inline u32 arch_fast_hash(const void *data, u32 len, u32 seed)
>  {
>  	u32 hash;
>  
> -	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
>  #ifdef CONFIG_X86_64
> -			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
> +	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
> +			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
> +			 : "rcx", "r8", "r9", "r10", "r11", "cc", "memory");
>  #else




> -			 "=a" (hash), "a" (data), "d" (len), "c" (seed));
> +	alternative_call(__jhash, __intel_crc4_2_hash, X86_FEATURE_XMM4_2,
> +			 "=a" (hash), "a" (data), "d" (len), "c" (seed)
> +			 : "cc", "memory");
>  #endif
>  	return hash;
>  }
> @@ -36,11 +39,14 @@ static inline u32 arch_fast_hash2(const u32 *data, u32 len, u32 seed)
>  {
>  	u32 hash;
>  
> -	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
>  #ifdef CONFIG_X86_64
> -			 "=a" (hash), "D" (data), "S" (len), "d" (seed));
> +	alternative_call(__jhash2, __intel_crc4_2_hash2, X86_FEATURE_XMM4_2,
> +			 "=a" (hash), "D" (data), "S" (len), "d" (seed)
> +			 : "rcx", "r8", "r9", "r10", "r11", "cc", "memory");


Thats a lot of clobbers.

Alternative would be to use an assembly trampoline to save/restore them
before calling __jhash2

__intel_crc4_2_hash2 can probably be written in assembly, it is quite
simple.

^ permalink raw reply

* Re: Device Tree Binding for Marvell DSA Switch on imx28 board over Mdio Interface
From: Oliver Graute @ 2014-11-14 14:52 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: netdev
In-Reply-To: <CA+KjHfZSeM=CPxbpoTAjbC3S5EKw+M59hii3t2zY4HePmFGZYg@mail.gmail.com>

On Fri, Nov 14, 2014 at 8:39 AM, Oliver Graute <oliver.graute@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 9:03 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 11/13/2014 07:15 AM, Oliver Graute wrote:
>>> Hello Florian,
>>>
>>> On Wed, Nov 12, 2014 at 8:19 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> On 11/12/2014 05:07 AM, Oliver Graute wrote:
>>>>> Hello,
>>>>>
>>>>> how do I specify the DSA node and the MDIO node in the Device Tree
>>>>> Binding to integrate a Marvell 88e6071 switch with a imx28 board?
>>>>>
>>>>> On my board the Marvell switch 88e6071 is connected via phy1 (on a
>>>>> imx28 PCB) to phy5 on the Marvell switch (on a Switch PCB). All phys
>>>>> are connected via the same MDIO Bus.
>>>>>
>>>>> I enabled the Marvell DSA Support Driver, Gianfar Ethernet Driver and
>>>>> Freescale PQ MDIO Driver in the Kernel (I' am not sure if this is the
>>>>> right choice for imx28 fec ethernet controller is it?)
>>>>>
>>>
>>> I changed my DeviceTree according to your proposal. Now I got a ENODEV 19
>>> in dsa_of_probe. Because  of_find_device_by_node(ethernet) is returning 0.
>>> Is my ethernet setting still wrong?
>>
>> Is your ethernet driver also modular? If so, you will need it to be
>> loaded *before* dsa. of_find_device_by_node() also needs the ethernet
>> driver to be a platform_driver.
>
> No my Freescale FEC PHY driver is not a module. FEC is a imx28/arm
> platform driver or not?
>
> I loaded the DSA as a Kernel module to make sure that the DSA probing
> is happening when the switch is really on. I enable the SWITCH ON Pin
> on bootup with a systemd started script. Then I write some registers
> on the switch with a userspace mii tool. This manually writing of some
> switch registers works fine via the MII Bus using ioctl(SIOCGMIIPHY).
>
> But i would like to integrate the switch with a full dsa driver.
> currently its failing with dsa_of_probe returns=-19
>

the dsa_core driver is probing the mii_bus before eth0 and eth1 are
detected via the FEC Driver.

[   20.716253] !!!!!enter dsa_init_module!!!!!
[   20.777046] !!!!Enter dsa Probe!!!!!
[   20.803422] Distributed Switch Architecture driver version 0.1
[   20.809295] !!!!!Enter dsa_of_probe!!!!!
[   20.888268] !!!!!mdio->name=mdio mdio->type=mdio
mdio->full_name=/mdio@800f0040 !!!!!
[   20.999618] !!!!!np->name=dsa np->type=<NULL> np->full_name=/dsa@0 !!!!!
[   21.097805] !!!!before of_mdio_find_bus!!!!!
[   21.137278] !!!!!enter of_mdio_find_bus!!!!!
[   21.190232] !!!!!enter of_mdio_bus_match!!!!!
[   21.194635] !!!!!enter of_mdio_bus_match!!!!!
[   21.199000] !!!!!enter of_mdio_bus_match!!!!!
[   21.300627] !!!!Leave of_mdio_find_bus !!!!!
[   21.304949] !!!!after of_mdio_find_bus mdio_bus=Freescale
PowerQUICC MII Bus !!!!!
[   21.456904] !!!!before of_parse_phandle dsa,ethernet!!!!!
[   21.570569] !!!!before of find_device_by_node!!!!!
[   21.575416] !!!!!ethernet->name=ethernet ethernet->type=<NULL>
ethernet->full_name=/ahb@80080000/ethernet@800f4000 !!!!!
[   21.860234] !!!!! enter of_find_device_by_node !!!!!
[   21.865284] !!!!! Leave of_find_device_by_node dev=c790fe10 !!!!!
[   21.970600] !!!!! dev->init_name=(null) !!!!!
[   21.975001] before to_platform_device test->name=800f4000.ethernet
[   22.088915] !!!!before of kzalloc!!!!!
[   22.134753] !!!!before pd->netdev!!!!!
[   22.138548] !!!!before dev_to_net_device!!!!!
[   22.210241] !!!!dev_put(dev)!!!!!
[   22.213600] !!!!kzalloc!!!!!
[   22.216493] !!!!platform_set_drv_data!!!!!
[   22.313247] !!!!!enter dev_to_mii_bus!!!!!
[   22.317393] !!!!!enter dsa_switch_setup!!!!!
[   22.394756] !!!!name=!!!!!
[   22.397691] !!!!bus->name=Freescale PowerQUICC MII Bus!!!!!
[   22.502050] !!!!pd->sw_addr=3!!!!!
[   22.505489] !!!!Enter dsa_switch_probe!!!!!
[   22.509685] !!!!Leave dsa_switch_probe!!!!!
[   22.630239] eth1[0]: could not detect attached switch
[   22.635337] eth1[0]: couldn't create dsa switch instance (error -22)
[   22.740538] !!!!Leave dsa Probe!!!!!
[   22.794305] !!!!!leave dsa_init_module!!!!!

[   65.954070] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   66.067135] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   66.532877] fec 800f4000.ethernet eth1: Freescale FEC PHY driver
[Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:01, irq=-1)

if i manually rmmod and modprobe the dsa_core driver  after FEC PHY
detection again i got a  EEXIST 17

modprobe dsa_core
[  212.770578] !!!!!enter dsa_init_module!!!!!
[  212.775121] !!!!Enter dsa Probe!!!!!
[  212.778726] Distributed Switch Architecture driver version 0.1
[  212.791071] !!!!!Enter dsa_of_probe!!!!!
[  212.795191] !!!!!mdio->name=mdio mdio->type=mdio
mdio->full_name=/mdio@800f0040 !!!!!
[  212.805452] !!!!!np->name=dsa np->type=<NULL> np->full_name=/dsa@0 !!!!!
[  212.813355] !!!!before of_mdio_find_bus!!!!!
[  212.817669] !!!!!enter of_mdio_find_bus!!!!!
[  212.823707] !!!!!enter of_mdio_bus_match!!!!!
[  212.828111] !!!!!enter of_mdio_bus_match!!!!!
[  212.834213] !!!!!enter of_mdio_bus_match!!!!!
[  212.838620] !!!!Leave of_mdio_find_bus !!!!!
[  212.844655] !!!!after of_mdio_find_bus mdio_bus=Freescale
PowerQUICC MII Bus !!!!!
[  212.853684] !!!!before of_parse_phandle dsa,ethernet!!!!!
[  212.859179] !!!!before of find_device_by_node!!!!!
[  212.866019] !!!!!ethernet->name=ethernet ethernet->type=<NULL>
ethernet->full_name=/ahb@80080000/ethernet@800f4000 !!!!!
[  212.878029] !!!!! enter of_find_device_by_node !!!!!
[  212.884159] !!!!! Leave of_find_device_by_node dev=c790fe10 !!!!!
[  212.891366] !!!!! dev->init_name=(null) !!!!!
[  212.895769]
[  212.895769] before to_platform_device test->name=800f4000.ethernet
[  212.905738] !!!!before of kzalloc!!!!!
[  212.909586] !!!!before pd->netdev!!!!!
[  212.915402] !!!!before dev_to_net_device!!!!!
[  212.919817] !!!!dev_put(dev)!!!!!
[  212.925431] dsa: probe of dsa.5 failed with error -17
[  212.936922] !!!!!leave dsa_init_module!!!!!


best regards,

Oliver

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox