Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Ben Hutchings @ 2013-03-05  3:16 UTC (permalink / raw)
  To: Chen Gang
  Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
	netdev
In-Reply-To: <51355936.3060307@asianux.com>

On Tue, 2013-03-05 at 10:32 +0800, Chen Gang wrote:
> 于 2013年03月05日 02:34, Ben Hutchings 写道:
> > On Mon, 2013-03-04 at 18:32 +0000, Ben Hutchings wrote:
> >> > On Thu, 2013-02-28 at 09:36 +0000, David Laight wrote:
> >>> > > 
> >>> > > If the target buffer ends up being copied to userspace that
> >>> > > might lead to random kernel memory being leaked.
> >> > 
> >> > Seems it is.  The last byte of 'name' is not currently initialised and
> >> > therefore is already leaked to userland.
> >> > 
> >> > But it's OK because rds_info_copy() uses memcpy() not __copy_to_user(),
> >> > so SMAP will block this leak. :-)
> > Or not, as kmap() presumably evades that.
> 
>  is this patch ok, or need improving ?

I think it is wrong, and the code should be changed to do either:

1. Zero-initialise the whole of the name, then use strlcpy().
2. Keep using strncpy(), and also set the last byte of name to 0.

> BTW:
>   excuse me, maybe my reply will be late during this week.
>   the reason:
>     my father had a serious heart disease, and is in hospital.
>     during these days, most of my time has to be in hospital.
>       (God Bless, and thank Jesus Christ, my father is safe, now).
>     within my company (Asianux), I also have something to do.

Best wishes to you both.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* [PATCH 3/3] net: cs89x0: use module_platform_driver_probe()
From: Jingoo Han @ 2013-03-05  2:43 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <005101ce194b$04f4d980$0ede8c80$%han@samsung.com>

This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/cirrus/cs89x0.c |   14 +-------------
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cirrus/cs89x0.c b/drivers/net/ethernet/cirrus/cs89x0.c
index 1384469..73c1c8c 100644
--- a/drivers/net/ethernet/cirrus/cs89x0.c
+++ b/drivers/net/ethernet/cirrus/cs89x0.c
@@ -1978,18 +1978,6 @@ static struct platform_driver cs89x0_driver = {
 	.remove	= cs89x0_platform_remove,
 };
 
-static int __init cs89x0_init(void)
-{
-	return platform_driver_probe(&cs89x0_driver, cs89x0_platform_probe);
-}
-
-module_init(cs89x0_init);
-
-static void __exit cs89x0_cleanup(void)
-{
-	platform_driver_unregister(&cs89x0_driver);
-}
-
-module_exit(cs89x0_cleanup);
+module_platform_driver_probe(cs89x0_driver, cs89x0_platform_probe);
 
 #endif /* CONFIG_CS89x0_PLATFORM */
-- 
1.7.2.5

^ permalink raw reply related

* [PATCH 2/3] net: macb: use module_platform_driver_probe()
From: Jingoo Han @ 2013-03-05  2:43 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <005101ce194b$04f4d980$0ede8c80$%han@samsung.com>

This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/cadence/macb.c |   13 +------------
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 7903943..3a5d680 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1737,18 +1737,7 @@ static struct platform_driver macb_driver = {
 	},
 };
 
-static int __init macb_init(void)
-{
-	return platform_driver_probe(&macb_driver, macb_probe);
-}
-
-static void __exit macb_exit(void)
-{
-	platform_driver_unregister(&macb_driver);
-}
-
-module_init(macb_init);
-module_exit(macb_exit);
+module_platform_driver_probe(macb_driver, macb_probe);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
-- 
1.7.2.5

^ permalink raw reply related

* [PATCH 1/3] net: at91_ether: use module_platform_driver_probe()
From: Jingoo Han @ 2013-03-05  2:42 UTC (permalink / raw)
  To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'

This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/net/ethernet/cadence/at91_ether.c |   13 +------------
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 3becdb2..1a57e16 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -519,18 +519,7 @@ static struct platform_driver at91ether_driver = {
 	},
 };
 
-static int __init at91ether_init(void)
-{
-	return platform_driver_probe(&at91ether_driver, at91ether_probe);
-}
-
-static void __exit at91ether_exit(void)
-{
-	platform_driver_unregister(&at91ether_driver);
-}
-
-module_init(at91ether_init)
-module_exit(at91ether_exit)
+module_platform_driver_probe(at91ether_driver, at91ether_probe);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("AT91RM9200 EMAC Ethernet driver");
-- 
1.7.2.5

^ permalink raw reply related

* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Chen Gang @ 2013-03-05  2:32 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
	netdev
In-Reply-To: <1362422090.2956.18.camel@bwh-desktop.uk.solarflarecom.com>

于 2013年03月05日 02:34, Ben Hutchings 写道:
> On Mon, 2013-03-04 at 18:32 +0000, Ben Hutchings wrote:
>> > On Thu, 2013-02-28 at 09:36 +0000, David Laight wrote:
>>> > > 
>>> > > If the target buffer ends up being copied to userspace that
>>> > > might lead to random kernel memory being leaked.
>> > 
>> > Seems it is.  The last byte of 'name' is not currently initialised and
>> > therefore is already leaked to userland.
>> > 
>> > But it's OK because rds_info_copy() uses memcpy() not __copy_to_user(),
>> > so SMAP will block this leak. :-)
> Or not, as kmap() presumably evades that.

 is this patch ok, or need improving ?

BTW:
  excuse me, maybe my reply will be late during this week.
  the reason:
    my father had a serious heart disease, and is in hospital.
    during these days, most of my time has to be in hospital.
      (God Bless, and thank Jesus Christ, my father is safe, now).
    within my company (Asianux), I also have something to do.


 :-)

-- 
Chen Gang

Asianux Corporation

^ permalink raw reply

* Re: [PATCH] drivers/isdn: checkng length to be sure not memory overflow
From: Chen Gang @ 2013-03-05  2:20 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: Jiri Kosina, isdn, Greg KH, alan, netdev
In-Reply-To: <512F5F14.6070801@suse.cz>

于 2013年02月28日 21:43, Jiri Slaby 写道:
> 
> Nah, there *are* still people using ISDN.
> 

  ok, thanks.

  it seems, we need maintaining ISDN:
    need fix bugs.
    need not add new features.
    need keep current features no touch.


> No, we cannot be sure that a user gives us less than that. Your patch
> just throws the rest to fix that overflow, right? What I'm saying I
> wouldn't fix more than that.

  what you said is: this patch need improving, is it correct ?
  if it is correct.
    I still prefer to throw the rest contents (but need improving, too)
      for maintaining, we need fix bug, but not need add new features
      so what we should do:
        a) fix the bug (should not memory overflow)
        b) keep the original buffer length no touch
           it is not sizeof(cmd.parm.cmsg.para) - 2)
           it should be sizeof(cmd.param) - sizeof(cmd.param.cmsg) + sizeof(cmd.param.cmsg.para) - 2
        c) need complete the relative document to export the limitation.

  is it ok ?
    (if it is not ok, welcome to provide suggestion or completion)


  thanks.

  :-)

-- 
Chen Gang

Asianux Corporation

^ permalink raw reply

* RE: [E1000-devel] e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)
From: Allan, Bruce W @ 2013-03-05  2:11 UTC (permalink / raw)
  To: Mihai Donțu, Morten Stevens
  Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Rafael J. Wysocki, Borislav Petkov,
	Jiri Slaby
In-Reply-To: <20130305005836.4f84c065@mdontu-l.dsd.ro>

> -----Original Message-----
> From: Mihai Donțu [mailto:mihai.dontu@gmail.com]
> Sent: Monday, March 04, 2013 2:59 PM
> To: Morten Stevens
> Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Rafael J. Wysocki; Borislav Petkov; Jiri Slaby
> Subject: Re: [E1000-devel] e1000e 3.9-rc1 suspend failure (was: Re: e1000e:
> nic does not work properly after cold power on)
> 
> On Mon, 4 Mar 2013 22:48:30 +0100 Borislav Petkov wrote:
> > On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote:
> > > Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest
> > > upstream driver (e1000e 2.2.14) which contains many bugfixes.
> >
> 
> On my system (ThinkPad T420) I get:
> 
> [   10.694743] e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k
> [   10.694746] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> [   10.694852] e1000e 0000:00:19.0: setting latency timer to 64
> [   10.694911] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to
> dynamic conservative mode
> [   10.694949] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X
> [   10.975086] e1000e 0000:00:19.0 eth0: registered PHC clock
> [   10.975091] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1)
> 00:21:cc:70:17:a0
> [   10.975093] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network
> Connection
> [   10.975127] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-
> 0FF
> [   89.716695] e1000e 0000:00:19.0 eth0: Hardware Error
> [   90.025403] e1000e 0000:00:19.0 eth0: Timesync Tx Control register not set
> as expected
> [   90.349197] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X
> [   90.449760] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X
> 
> The 'hardware error' line caught my attention.
> 
> > This e1000e thing gets more b0rked by the minute. This is what happens
> > when I try to suspend with 3.9-rc1:
> >
> > [   83.502908] PM: Syncing filesystems ... done.
> > [   83.509886] Freezing user space processes ... (elapsed 0.01
> > seconds) done. [   83.523352] PM: Preallocating image memory... done
> > (allocated 95652 pages) [   83.675083] PM: Allocated 382608 kbytes in
> > 0.15 seconds (2550.72 MB/s) [   83.675782] Freezing remaining
> > freezable tasks ... (elapsed 0.01 seconds) done. [   83.688524]
> > Suspending console(s) (use no_console_suspend to debug)
> > [   84.251024] e1000e 0000:00:19.0 eth0: Hardware Error
> > [   84.458866] ------------[ cut here ]------------ [   84.458871]
> > WARNING: at kernel/irq/manage.c:1249 __free_irq+0xa3/0x1e0()
> > [   84.458872] Hardware name: 2320CTO [   84.458872] Trying to free
> > already-free IRQ 20 [   84.458898] Modules linked in:
> > cpufreq_powersave cpufreq_userspace cpufreq_conservative
> > cpufreq_stats uinput loop hid_generic usb hid hid coretemp kvm_intel
> > arc4 kvm crc32_pclmul iwldvm crc32c_intel ghash_clmulni_intel
> > mac80211 aesni_intel xts ipv6 aes_x86_64 lr w gf128mul ablk_helper
> > cryptd iTCO_wdt iTCO_vendor_support iwlwifi sdhci_pci sdhci cfg80211
> > snd_hda_codec_hdmi snd_hda_codec_realtek mmc_core microcode
> e1000e
> > thinkpad_acpi pcspkr lpc_ich i2c_i801 mfd_core nvram snd_hda_intel
> > rfkill snd_hda_codec battery ac snd_hw dep led_class snd_pcm
> > snd_page_alloc snd_timer snd acpi_cpufreq soundcore mperf ptp wmi
> > pps_core xhci_hcd ehci_pci ehci_hcd processo r thermal [   84.458900]
> > Pid: 3353, comm: kworker/u:35 Tainted: G        W    3.9.0-rc1 #1
> > [   84.458901] Call Trace: [   84.458905]  [<ffffffff8103ef7f>]
> > warn_slowpath_common+0x7f/0xc0 [   84.458907]  [<ffffffff8103f076>]
> > warn_slowpath_fmt+0x46/0x50 [   84.458910]  [<ffffffff81537bfe>] ?
> > _raw_spin_lock_irqsave+0x4e/0x60 [   84.458911]
> > [<ffffffff810bc8d5>] ? __free_irq+0x55/0x1e0 [   84.458913]
> > [<ffffffff810bc923>] __free_irq+0xa3/0x1e0 [   84.458914]
> > [<ffffffff810bcab4>] free_irq+0x54/0xc0 [   84.458919]
> > [<ffffffffa017745d>] e1000_free_irq+0x7d/0x90 [e1000e]
> > [   84.458922]  [<ffffffffa01834af>] __e1000_shutdown+0x8f/0x8a0
> > [e1000e] [   84.458924]  [<ffffffff813c92a7>] ?
> > __device_suspend+0xb7/0x200 [   84.458927]  [<ffffffff81073b71>] ?
> > get_parent_ip+0x11/0x50 [   84.458931]  [<ffffffffa0183d33>]
> > e1000_suspend+0x23/0x50 [e1000e] [   84.458932]
> > [<ffffffff813c92a7>] ? __device_suspend+0xb7/0x200 [   84.458933]
> > [<ffffffff8153c049>] ? sub_preempt_count+0x79/0xd0 [   84.458936]
> > [<ffffffff812a2ff5>] pci_pm_freeze+0x55/0xc0 [   84.458937]
> > [<ffffffff812a2fa0>] ? pci_pm_resume_noirq+0xd0/0xd0 [   84.458938]
> > [<ffffffff813c8b45>] dpm_run_callback.isra.5+0x25/0x50
> > [   84.458939]  [<ffffffff813c92d3>] __device_suspend+0xe3/0x200
> > [   84.458941]  [<ffffffff813c940f>] async_suspend+0x1f/0xa0
> > [   84.458942]  [<ffffffff8106bcfb>] async_run_entry_fn+0x3b/0x140
> > [   84.458944]  [<ffffffff8105d00d>] process_one_work+0x1ed/0x510
> > [   84.458946]  [<ffffffff8105cfab>] ? process_one_work+0x18b/0x510
> > [   84.458948]  [<ffffffff8105e7b5>] worker_thread+0x115/0x390
> > [   84.458949]  [<ffffffff8105e6a0>] ? manage_workers+0x300/0x300
> > [   84.458951]  [<ffffffff81064e2a>] kthread+0xea/0xf0
> > [   84.458953]  [<ffffffff81064d40>] ?
> > kthread_create_on_node+0x160/0x160 [   84.458954]
> > [<ffffffff8153ff9c>] ret_from_fork+0x7c/0xb0 [   84.458955]
> > [<ffffffff81064d40>] ? kthread_create_on_node+0x160/0x160
> > [   84.458956] ---[ end trace 3114e23ce50d2357 ]--- [   85.082276]
> > pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2
> > [   85.082278] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -2
> > [   85.082281] PM: Device 0000:00:19.0 failed to freeze async: error
> > -2
> >
> > Let's add more folks to CC.

This may be related to some runtime power management issues for which there are a
number of patches currently in test.


^ permalink raw reply

* RE: e1000e disabling already-disabled device
From: Allan, Bruce W @ 2013-03-05  2:11 UTC (permalink / raw)
  To: Francois Romieu, Dave Jones; +Cc: netdev@vger.kernel.org, khlebnikov@openvz.org
In-Reply-To: <20130303233624.GA28784@electric-eye.fr.zoreil.com>

> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Sunday, March 03, 2013 3:36 PM
> To: Dave Jones
> Cc: netdev@vger.kernel.org; Allan, Bruce W
> Subject: Re: e1000e disabling already-disabled device
> 
> Dave Jones <davej@redhat.com> :
> [...]
> >  ------------[ cut here ]------------
> >  WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x90/0xa0()
> >  Hardware name: 2356JK8
> >  Device e1000e
> > disabling already-disabled device
> > Modules linked in:
> >  dm_crypt arc4 iwldvm mac80211 ipv6 iTCO_wdt xfs iTCO_vendor_support
> libcrc32c coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel
> microcode snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth
> iwlwifi pcspkr snd_hda_intel cfg80211 snd_hda_codec snd_pcm lpc_ich
> mfd_core e1000e snd_page_alloc ptp pps_core thinkpad_acpi hwmon
> led_class rfkill wmi nfsd auth_rpcgss nfs_acl lockd sunrpc i915 i2c_algo_bit
> drm_kms_helper drm i2c_core video
> > Pid: 19776, comm: kworker/u:11 Not tainted 3.8.0+ #6
> > Call Trace:
> >  [<ffffffff81049855>] warn_slowpath_common+0x75/0xa0
> >  [<ffffffff81049936>] warn_slowpath_fmt+0x46/0x50
> >  [<ffffffff81359760>] pci_disable_device+0x90/0xa0
> >  [<ffffffffa0251092>] __e1000_shutdown+0x262/0x8a0 [e1000e]
> >  [<ffffffffa0251743>] e1000_suspend+0x23/0x50 [e1000e]
> >  [<ffffffff816284b9>] ? sub_preempt_count+0x79/0xd0
> >  [<ffffffff8135bd97>] pci_pm_suspend+0x77/0x140
> >  [<ffffffff8135bd20>] ? pci_pm_poweroff+0xf0/0xf0
> >  [<ffffffff8140c678>] dpm_run_callback+0x58/0x90
> >  [<ffffffff8140c79d>] __device_suspend+0xed/0x280
> >  [<ffffffff8140d1ef>] async_suspend+0x1f/0xa0
> 
> Could it be that runtime power management is also enabled, you have no
> link and thus end running both runtime_suspend and suspend at different
> times ?
> 
> I wonder why the driver disables the PCI device here btw.
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index a177b8b..5c643c6 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5986,8 +5986,6 @@ static int __e1000_shutdown(struct pci_dev
> *pdev, bool *enable_wake,
>  	 */
>  	e1000e_release_hw_control(adapter);
> 
> -	pci_disable_device(pdev);
> -
>  	return 0;
>  }
> 
> ---
> Ueimor

This is a known issue and a patch from Konstantin Khlebnikov <khlebnikov@openvz.org> is currently under test.

Thanks,
Bruce.

^ permalink raw reply

* How to reduce Ethernet TX irq number
From: Frank Li @ 2013-03-05  1:47 UTC (permalink / raw)
  To: netdev
In-Reply-To: <CAHrpEqTLm=fQFEKdDfAGo=p2pSxihQVf6=-b4RSUqg0sr9n9YA@mail.gmail.com>

All:
          Recently, I send some patches about put TX handle to NAPI
for freescale FEC.
          But Irq number still huge because we enable irq at each BD.
          Hardware always issue TX irq and irq handle always be called.

          I do test by enable BD irq every 64 packages.
          TX performance can improve huge from 360M to 470M.

          What's correct method to do that?

          Actually, xmit function have return SEND,  stack should
think package already sent when call xmit.
          TX irq handler just free some resource.

best regards
Frank Li

^ permalink raw reply

* Re: [PATCH V2] lglock: add read-preference local-global rwlock
From: Michel Lespinasse @ 2013-03-05  1:37 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Lai Jiangshan, Srivatsa S. Bhat, Lai Jiangshan, linux-doc, peterz,
	fweisbec, linux-kernel, namhyung, mingo, linux-arch, linux,
	xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty, rostedt,
	rjw, vincent.guittot, tglx, linux-arm-kernel, netdev, sbw, tj,
	akpm, linuxppc-dev
In-Reply-To: <20130303174056.GA30176@redhat.com>

On Sun, Mar 3, 2013 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>> However, I still think that FALLBACK_BASE only adds the unnecessary
>> complications. But even if I am right this is subjective of course, please
>> feel free to ignore.

Would it help if I sent out that version (without FALLBACK_BASE) as a
formal proposal ?

> Hmm. But then I do not understand the lglock annotations. Obviously,
> rwlock_acquire_read() in lg_local_lock() can't even detect the simplest
> deadlock, say, lg_local_lock(LOCK) + lg_local_lock(LOCK). Not to mention
> spin_lock(X) + lg_local_lock(Y) vs lg_local_lock(Y) + spin_lock(X).
>
> OK, I understand that it is not easy to make these annotations correct...

I am going to send out a proposal to fix the existing lglock
annotations and detect the two cases you noticed. It's actually not
that hard :)

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

^ permalink raw reply

* Re: [PATCH] net/wireless/brcm80211: remove PCI_BUS define from defs.h to fix warnings
From: Larry Finger @ 2013-03-05  1:28 UTC (permalink / raw)
  To: shuah.khan
  Cc: brudley, arend, frankyl, linville, seth.forshee, pieterpg,
	linux-wireless, brcm80211-dev-list, netdev, LKML, shuahkhan
In-Reply-To: <1362445374.4591.28.camel@lorien2>

On 03/04/2013 07:02 PM, Shuah Khan wrote:
> PCI_BUS defined in defs.h results in warnings from all brcm80211 source files
> including defs.h. This define is not used in brcm80211. Removing this define
> fixes the warning.
>
> In file included from drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:35:0:
> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
> include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition
>    CC [M]  drivers/net/wireless/b43legacy/dma.o
>    CC [M]  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
>    CC [M]  drivers/net/wireless/b43legacy/pio.o
> In file included from drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
> include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition
> In file included from drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
> include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition

Strange, I do not see PCI_BUS defined anywhere in the include/ branch in either 
3.8 or 3.9. In addition, I don't get these warnings. What is different in your 
system?

Larry

>
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> ---
>   drivers/net/wireless/brcm80211/include/defs.h |    1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/include/defs.h b/drivers/net/wireless/brcm80211/include/defs.h
> index fb7cbcf..3608436 100644
> --- a/drivers/net/wireless/brcm80211/include/defs.h
> +++ b/drivers/net/wireless/brcm80211/include/defs.h
> @@ -20,7 +20,6 @@
>   #include <linux/types.h>
>
>   #define	SI_BUS			0
> -#define	PCI_BUS			1
>   #define	PCMCIA_BUS		2
>   #define SDIO_BUS		3
>   #define JTAG_BUS		4
>

^ permalink raw reply

* [PATCH] net/wireless/brcm80211: remove PCI_BUS define from defs.h to fix warnings
From: Shuah Khan @ 2013-03-05  1:02 UTC (permalink / raw)
  To: brudley, arend, frankyl, linville, seth.forshee, pieterpg
  Cc: linux-wireless, brcm80211-dev-list, netdev, LKML, shuahkhan

PCI_BUS defined in defs.h results in warnings from all brcm80211 source files
including defs.h. This define is not used in brcm80211. Removing this define
fixes the warning.

In file included from drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:35:0:
drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition
  CC [M]  drivers/net/wireless/b43legacy/dma.o
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
  CC [M]  drivers/net/wireless/b43legacy/pio.o
In file included from drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition
In file included from drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS" redefined [enabled by default]
include/uapi/linux/pci.h:36:0: note: this is the location of the previous definition

Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
 drivers/net/wireless/brcm80211/include/defs.h |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/brcm80211/include/defs.h b/drivers/net/wireless/brcm80211/include/defs.h
index fb7cbcf..3608436 100644
--- a/drivers/net/wireless/brcm80211/include/defs.h
+++ b/drivers/net/wireless/brcm80211/include/defs.h
@@ -20,7 +20,6 @@
 #include <linux/types.h>
 
 #define	SI_BUS			0
-#define	PCI_BUS			1
 #define	PCMCIA_BUS		2
 #define SDIO_BUS		3
 #define JTAG_BUS		4
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH v5] net: sh_eth: Add support of device tree probe
From: Simon Horman @ 2013-03-05  0:43 UTC (permalink / raw)
  To: Nobuhiro Iwamatsu
  Cc: netdev, grant.likely, kuninori.morimoto.gx, devicetree-discuss,
	magnus.damm, kda, Mark Rutland
In-Reply-To: <1362433940-20533-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>

[ Cc: Mark Rutland ]

On Tue, Mar 05, 2013 at 06:52:20AM +0900, Nobuhiro Iwamatsu wrote:
> This adds support of device tree probe for Renesas sh-ether driver.
> 
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>

Hi Iwamatsu-san,

could you please address the review by
Mark Rutland of the bindings in this patch.
The review was made for v2 but I believe it
is still applicable to v5.

http://www.spinics.net/lists/netdev/msg226454.html

> V5: - Rewrite sh_eth_parse_dt().
>       Remove of_device_is_available() and CONFIG_OF from support OF
>       checking function and re-add empty sh_eth_parse_dt().
>     - Add CONFIG_PM to definition of dev_pm_ops.
> 	- Add CONFIG_OF to definition of of_device_id.
> V4: - Remove empty sh_eth_parse_dt().
> V3: - Remove empty sh_eth_parse_dt().
> V3: - Removed sentnece of "needs-init" from document.
> V2: - Removed ether_setup().
>     - Fixed typo from "sh-etn" to "sh-eth".
> 	- Removed "needs-init" and sh-eth,endian from definition of DT.
> 	- Changed "sh-eth,edmac-endian" instead of "sh-eth,edmac-big-endain"
> 	  in definition of DT.
> ---
>  Documentation/devicetree/bindings/net/sh_ether.txt |   39 +++++
>  drivers/net/ethernet/renesas/sh_eth.c              |  164 +++++++++++++++++---
>  2 files changed, 178 insertions(+), 25 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/sh_ether.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/sh_ether.txt b/Documentation/devicetree/bindings/net/sh_ether.txt
> new file mode 100644
> index 0000000..2deb841
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sh_ether.txt
> @@ -0,0 +1,39 @@
> +* Renesas Electronics SuperH EMAC
> +
> +This file provides information, what the device node
> +for the sh_eth interface contains.
> +
> +Required properties:
> +- compatible:                   "renesas,sh-eth";
> +- interrupt-parent:             The phandle for the interrupt controller that
> +                                services interrupts for this device.
> +- reg:                          Offset and length of the register set for the
> +                                device.
> +- interrupts:                   Interrupt mapping for the sh_eth interrupt
> +                                sources (vector id).
> +- phy-mode:                     String, operation mode of the PHY interface.
> +- sh-eth,register-type:         String, register type of sh_eth.
> +                                Please select "gigabit", "fast-sh4" or
> +                                "fast-sh3-sh2".
> +- sh-eth,phy-id:                PHY id.
> +
> +Optional properties:
> +- local-mac-address:            6 bytes, mac address
> +- sh-eth,no-ether-link:         Set link control by software. When device does
> +                                not support ether-link, set.
> +- sh-eth,ether-link-active-low: Set link check method.
> +                                When detection of link is treated as active-low,
> +                                set.
> +- sh-eth,edmac-big-endian:      Set big endian for sh_eth dmac.
> +                                It work as little endian when this is not set.
> +
> +Example (armadillo800eva):
> +	sh-eth@e9a00000 {
> +		compatible = "renesas,sh-eth";
> +		interrupt-parent = <&intca>;
> +		reg = <0xe9a00000 0x800>, <0xe9a01800 0x800>;
> +		interrupts = <0x500>;
> +		phy-mode = "mii";
> +		sh-eth,register-type = "gigabit";
> +		sh-eth,phy-id = <0>;
> +	};
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 3d70586..a97d208 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1,7 +1,7 @@
>  /*
>   *  SuperH Ethernet device driver
>   *
> - *  Copyright (C) 2006-2012 Nobuhiro Iwamatsu
> + *  Copyright (C) 2006-2013 Nobuhiro Iwamatsu
>   *  Copyright (C) 2008-2012 Renesas Solutions Corp.
>   *
>   *  This program is free software; you can redistribute it and/or modify it
> @@ -31,6 +31,12 @@
>  #include <linux/platform_device.h>
>  #include <linux/mdio-bitbang.h>
>  #include <linux/netdevice.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_net.h>
>  #include <linux/phy.h>
>  #include <linux/cache.h>
>  #include <linux/io.h>
> @@ -2347,26 +2353,109 @@ static const struct net_device_ops sh_eth_netdev_ops = {
>  	.ndo_change_mtu		= eth_change_mtu,
>  };
>  
> +#ifdef CONFIG_OF
> +static int
> +sh_eth_of_get_register_type(struct device_node *np)
> +{
> +	const char *of_str;
> +	int ret = of_property_read_string(np, "sh-eth,register-type", &of_str);
> +	if (ret)
> +		return ret;
> +
> +	if (of_str && !strcmp(of_str, "gigabit"))
> +		return SH_ETH_REG_GIGABIT;
> +
> +	else if (of_str && !strcmp(of_str, "fast-sh4"))
> +		return SH_ETH_REG_FAST_SH4;
> +	else if (of_str && !strcmp(of_str, "fast-sh3-sh2"))
> +		return SH_ETH_REG_FAST_SH3_SH2;
> +	else
> +		return -EINVAL;
> +}
> +
> +static struct sh_eth_plat_data *
> +sh_eth_parse_dt(struct device *dev, struct net_device *ndev,
> +				struct device_node *np)
> +{
> +	int ret;
> +	struct sh_eth_plat_data *pdata;
> +
> +	pdata = devm_kzalloc(dev, sizeof(struct sh_eth_plat_data),
> +					GFP_KERNEL);
> +	if (!pdata) {
> +		dev_err(dev, "%s: failed to allocate config data\n", __func__);
> +		return NULL;
> +	}
> +
> +	pdata->phy_interface = of_get_phy_mode(np);
> +
> +	of_property_read_u32(np, "sh-eth,phy-id", &pdata->phy);
> +
> +	if (of_find_property(np, "sh-eth,edmac-big-endian", NULL))
> +		pdata->edmac_endian = EDMAC_BIG_ENDIAN;
> +	else
> +		pdata->edmac_endian = EDMAC_LITTLE_ENDIAN;
> +
> +	if (of_find_property(np, "sh-eth,no-ether-link", NULL))
> +		pdata->no_ether_link = 1;
> +	else
> +		pdata->no_ether_link = 0;
> +
> +	if (of_find_property(np, "sh-eth,ether-link-active-low", NULL))
> +		pdata->ether_link_active_low = 1;
> +	else
> +		pdata->ether_link_active_low = 0;
> +
> +	ret = sh_eth_of_get_register_type(np);
> +	if (ret < 0)
> +		goto error;
> +	pdata->register_type = ret;
> +
> +#ifdef CONFIG_OF_NET
> +	if (!is_valid_ether_addr(ndev->dev_addr)) {
> +		const char *macaddr = of_get_mac_address(np);
> +		if (macaddr)
> +			memcpy(pdata->mac_addr, macaddr, ETH_ALEN);
> +	}
> +#endif
> +
> +	return pdata;
> +
> +error:
> +	devm_kfree(dev, pdata);
> +	return NULL;
> +}
> +#else
> +static inline struct sh_eth_plat_data *
> +sh_eth_parse_dt(struct device *dev, struct net_device *ndev,
> +				struct device_node *np)
> +{
> +	return NULL;
> +}
> +#endif
> +
>  static int sh_eth_drv_probe(struct platform_device *pdev)
>  {
> -	int ret, devno = 0;
> +	int ret = 0, devno = 0;
>  	struct resource *res;
>  	struct net_device *ndev = NULL;
>  	struct sh_eth_private *mdp = NULL;
>  	struct sh_eth_plat_data *pd;
> +	struct device_node *np = pdev->dev.of_node;
>  
> +	ndev = alloc_etherdev(sizeof(struct sh_eth_private));
> +	if (!ndev) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	mdp = netdev_priv(ndev);
>  	/* get base addr */
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (unlikely(res == NULL)) {
>  		dev_err(&pdev->dev, "invalid resource\n");
>  		ret = -EINVAL;
> -		goto out;
> -	}
> -
> -	ndev = alloc_etherdev(sizeof(struct sh_eth_private));
> -	if (!ndev) {
> -		ret = -ENOMEM;
> -		goto out;
> +		goto out_release;
>  	}
>  
>  	/* The sh Ether-specific entries in the device structure. */
> @@ -2383,14 +2472,6 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>  	}
>  	ndev->irq = ret;
>  
> -	SET_NETDEV_DEV(ndev, &pdev->dev);
> -
> -	/* Fill in the fields of the device structure with ethernet values. */
> -	ether_setup(ndev);
> -
> -	mdp = netdev_priv(ndev);
> -	mdp->num_tx_ring = TX_RING_SIZE;
> -	mdp->num_rx_ring = RX_RING_SIZE;
>  	mdp->addr = ioremap(res->start, resource_size(res));
>  	if (mdp->addr == NULL) {
>  		ret = -ENOMEM;
> @@ -2398,12 +2479,33 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>  		goto out_release;
>  	}
>  
> +	if (np) {
> +		pd = sh_eth_parse_dt(&pdev->dev, ndev, np);
> +		if (pdev->dev.platform_data && pd) {
> +			struct sh_eth_plat_data *tmp =
> +				pdev->dev.platform_data;
> +			pd->set_mdio_gate = tmp->set_mdio_gate;
> +			pd->needs_init = tmp->needs_init;
> +		}
> +	} else
> +		pd = pdev->dev.platform_data;
> +
> +	if (!pd) {
> +		dev_err(&pdev->dev, "no setup data defined\n");
> +		ret = -EINVAL;
> +		goto out_release;
> +	}
> +
> +	SET_NETDEV_DEV(ndev, &pdev->dev);
> +
> +	mdp->num_tx_ring = TX_RING_SIZE;
> +	mdp->num_rx_ring = RX_RING_SIZE;
> +
>  	spin_lock_init(&mdp->lock);
>  	mdp->pdev = pdev;
>  	pm_runtime_enable(&pdev->dev);
>  	pm_runtime_resume(&pdev->dev);
>  
> -	pd = (struct sh_eth_plat_data *)(pdev->dev.platform_data);
>  	/* get PHY ID */
>  	mdp->phy_id = pd->phy;
>  	mdp->phy_interface = pd->phy_interface;
> @@ -2412,6 +2514,8 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>  	mdp->no_ether_link = pd->no_ether_link;
>  	mdp->ether_link_active_low = pd->ether_link_active_low;
>  	mdp->reg_offset = sh_eth_get_register_offset(pd->register_type);
> +	/* read and set MAC address */
> +	read_mac_address(ndev, pd->mac_addr);
>  
>  	/* set cpu data */
>  #if defined(SH_ETH_HAS_BOTH_MODULES)
> @@ -2429,20 +2533,16 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>  	/* debug message level */
>  	mdp->msg_enable = SH_ETH_DEF_MSG_ENABLE;
>  
> -	/* read and set MAC address */
> -	read_mac_address(ndev, pd->mac_addr);
> -
>  	/* ioremap the TSU registers */
>  	if (mdp->cd->tsu) {
>  		struct resource *rtsu;
>  		rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>  		if (!rtsu) {
>  			dev_err(&pdev->dev, "Not found TSU resource\n");
> -			ret = -ENODEV;
>  			goto out_release;
>  		}
>  		mdp->tsu_addr = ioremap(rtsu->start,
> -					resource_size(rtsu));
> +				resource_size(rtsu));
>  		mdp->port = devno % 2;
>  		ndev->features = NETIF_F_HW_VLAN_FILTER;
>  	}
> @@ -2509,6 +2609,7 @@ static int sh_eth_drv_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_PM
>  static int sh_eth_runtime_nop(struct device *dev)
>  {
>  	/*
> @@ -2522,17 +2623,30 @@ static int sh_eth_runtime_nop(struct device *dev)
>  	return 0;
>  }
>  
> -static struct dev_pm_ops sh_eth_dev_pm_ops = {
> +static const struct dev_pm_ops sh_eth_dev_pm_ops = {
>  	.runtime_suspend = sh_eth_runtime_nop,
>  	.runtime_resume = sh_eth_runtime_nop,
>  };
> +#define SH_ETH_PM_OPS (&sh_eth_dev_pm_ops)
> +#else
> +#define SH_ETH_PM_OPS NULL
> +#endif
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id sh_eth_match[] = {
> +	{ .compatible = "renesas,sh-eth", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sh_eth_match);
> +#endif
>  
>  static struct platform_driver sh_eth_driver = {
>  	.probe = sh_eth_drv_probe,
>  	.remove = sh_eth_drv_remove,
>  	.driver = {
>  		   .name = CARDNAME,
> -		   .pm = &sh_eth_dev_pm_ops,
> +		   .pm = SH_ETH_PM_OPS,
> +		   .of_match_table = of_match_ptr(sh_eth_match),
>  	},
>  };
>  
> -- 
> 1.7.10.4
> 

^ permalink raw reply

* Re: [PATCHi v2] net: sh_eth: Add support of device tree probe
From: Simon Horman @ 2013-03-05  0:43 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Nobuhiro Iwamatsu, netdev@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org, magnus.damm@gmail.com,
	kda@linux-powerpc.org
In-Reply-To: <20130215163251.GA2597@e106331-lin.cambridge.arm.com>

On Fri, Feb 15, 2013 at 04:32:51PM +0000, Mark Rutland wrote:
> Hello,
> 
> I have a couple of comments on the binding and the way it's parsed.
> 
> On Thu, Feb 14, 2013 at 12:51:31AM +0000, Nobuhiro Iwamatsu wrote:
> > This adds support of device tree probe for Renesas sh-ether driver.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > 
> > ---
> > V2: - Removed ether_setup().
> >     - Fixed typo from "sh-etn" to "sh-eth".
> > 	- Removed "needs-init" and sh-eth,endian from definition of DT.
> > 	- Changed "sh-eth,edmac-endian" instead of "sh-eth,edmac-big-endain"
> > 	  in definition of DT.
> > 
> >  Documentation/devicetree/bindings/net/sh_ether.txt |   41 +++++
> >  drivers/net/ethernet/renesas/sh_eth.c              |  156 +++++++++++++++++---
> >  2 files changed, 173 insertions(+), 24 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/net/sh_ether.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/net/sh_ether.txt b/Documentation/devicetree/bindings/net/sh_ether.txt
> > new file mode 100644
> > index 0000000..7415e54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/sh_ether.txt
> > @@ -0,0 +1,41 @@
> > +* Renesas Electronics SuperH EMAC
> > +
> > +This file provides information, what the device node
> > +for the sh_eth interface contains.
> > +
> > +Required properties:
> > +- compatible:                   "renesas,sh-eth";
> > +- interrupt-parent:             The phandle for the interrupt controller that
> > +                                services interrupts for this device.
> 
> Is this really a required property?
> 
> As it's a standard property with a well-defined meaning, is it necessary to
> document?
> 
> > +- reg:                          Offset and length of the register set for the
> > +                                device.
> 
> The example below shows 2 reg values, yet this implies only one is necessary.
> 
> > +- interrupts:                   Interrupt mapping for the sh_eth interrupt
> > +                                sources (vector id).
> 
> How many interrupts are expected, what are they, and in what order should they be in?
> 
> > +- phy-mode:                     String, operation mode of the PHY interface.
> 
> What are the valid values for this?
> 
> If they're defined in another document, it'd be good to reference it.
> 
> > +- sh-eth,register-type:         String, register type of sh_eth.
> > +                                Please select "gigabit", "fast-sh4" or
> > +                                "fast-sh3-sh2".
> 
> Why are these not handled as separate versions using the compatible string to
> differentiate them?

Hi Iwamatasu-san,

Could you please address this review?
I believe it is still applicable as of v5 which you posted yesterday.

^ permalink raw reply

* Re: Fw: [Bug 54601] New: PPP regression on 3.2.39 stop work need restart server ont version 3.2.21 not found this problem.
From: Eric Dumazet @ 2013-03-05  0:05 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: Stephen Hemminger, netdev, micron10, Eric Dumazet
In-Reply-To: <20130304224837.GX9079@decadent.org.uk>

On Mon, 2013-03-04 at 22:48 +0000, Ben Hutchings wrote:
> On Fri, Mar 01, 2013 at 08:47:05AM -0800, Stephen Hemminger wrote:
> > 
> > 
> > Begin forwarded message:
> > 
> > Date: Fri, 1 Mar 2013 01:24:14 -0800
> > From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> > To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> > Subject: [Bug 54601] New: PPP regression on 3.2.39 stop work need restart server ont version 3.2.21 not found this problem.
> > 
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=54601
> > 
> >            Summary: PPP regression on 3.2.39 stop work need restart server
> >                     ont version 3.2.21 not found this problem.
> >            Product: Networking
> >            Version: 2.5
> >     Kernel Version: 3.2.39
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: high
> >           Priority: P1
> >          Component: Other
> >         AssignedTo: shemminger@linux-foundation.org
> >         ReportedBy: micron10@gmail.com
> >         Regression: Yes
> > 
> > 
> > Hi
> > watch a problem with PPP after upgrade to version 3.2.39 ppp service stop work
> > 2 hours after start with this crash :
> > 
> > [79619.180026] unregister_netdevice: waiting for ppp618 to become free. Usage
> > count = 562
> [...]
> > [79862.540040] unregister_netdevice: waiting for ppp618 to become free. Usage
> > count = 30
> > [79872.680037] unregister_netdevice: waiting for ppp618 to become free. Usage
> > count = 9
> [...]
> 
> So there are many references left to the device, which slowly go away
> (very slowly, about 2 per second).  Maybe there are skbs in a queue somewhere
> that still refer to the PPP device.
> 
> Since this a regression between 3.2.21 and 3.2.29, it might have been
> introduced by:
> 
> commit 73a3346556281fd56f39f0a9475249e5039d8807
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Thu Jun 14 06:42:44 2012 +0000
> 
>     net: remove skb_orphan_try()
>     
>     commit 62b1a8ab9b3660bb820d8dfe23148ed6cda38574 upstream.
> 
> But this is a bit of a guess.  And I don't think that this change
> would do more than expose/exacerbate a bug that already existed.
> 
> Ben.
> 

I wonder which component could possibly take one dev refcnt for every
packet.

maybe xdst_queue_output in net/xfrm/xfrm_policy.c ?

Then maybe the cleanup is not properly done at device dismantle

^ permalink raw reply

* Re: e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)
From: Mihai Donțu @ 2013-03-04 22:58 UTC (permalink / raw)
  To: Morten Stevens
  Cc: e1000-devel, netdev, linux-kernel, Rafael J. Wysocki,
	Borislav Petkov, Jiri Slaby
In-Reply-To: <20130304214830.GB22306@pd.tnic>

On Mon, 4 Mar 2013 22:48:30 +0100 Borislav Petkov wrote:
> On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote:
> > Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest
> > upstream driver (e1000e 2.2.14) which contains many bugfixes.
> 

On my system (ThinkPad T420) I get:

[   10.694743] e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k
[   10.694746] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[   10.694852] e1000e 0000:00:19.0: setting latency timer to 64
[   10.694911] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[   10.694949] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X
[   10.975086] e1000e 0000:00:19.0 eth0: registered PHC clock
[   10.975091] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:cc:70:17:a0
[   10.975093] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[   10.975127] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
[   89.716695] e1000e 0000:00:19.0 eth0: Hardware Error
[   90.025403] e1000e 0000:00:19.0 eth0: Timesync Tx Control register not set as expected
[   90.349197] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X
[   90.449760] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X

The 'hardware error' line caught my attention.

> This e1000e thing gets more b0rked by the minute. This is what happens
> when I try to suspend with 3.9-rc1:
> 
> [   83.502908] PM: Syncing filesystems ... done.
> [   83.509886] Freezing user space processes ... (elapsed 0.01
> seconds) done. [   83.523352] PM: Preallocating image memory... done
> (allocated 95652 pages) [   83.675083] PM: Allocated 382608 kbytes in
> 0.15 seconds (2550.72 MB/s) [   83.675782] Freezing remaining
> freezable tasks ... (elapsed 0.01 seconds) done. [   83.688524]
> Suspending console(s) (use no_console_suspend to debug)
> [   84.251024] e1000e 0000:00:19.0 eth0: Hardware Error
> [   84.458866] ------------[ cut here ]------------ [   84.458871]
> WARNING: at kernel/irq/manage.c:1249 __free_irq+0xa3/0x1e0()
> [   84.458872] Hardware name: 2320CTO [   84.458872] Trying to free
> already-free IRQ 20 [   84.458898] Modules linked in:
> cpufreq_powersave cpufreq_userspace cpufreq_conservative
> cpufreq_stats uinput loop hid_generic usb hid hid coretemp kvm_intel
> arc4 kvm crc32_pclmul iwldvm crc32c_intel ghash_clmulni_intel
> mac80211 aesni_intel xts ipv6 aes_x86_64 lr w gf128mul ablk_helper
> cryptd iTCO_wdt iTCO_vendor_support iwlwifi sdhci_pci sdhci cfg80211
> snd_hda_codec_hdmi snd_hda_codec_realtek mmc_core microcode e1000e
> thinkpad_acpi pcspkr lpc_ich i2c_i801 mfd_core nvram snd_hda_intel
> rfkill snd_hda_codec battery ac snd_hw dep led_class snd_pcm
> snd_page_alloc snd_timer snd acpi_cpufreq soundcore mperf ptp wmi
> pps_core xhci_hcd ehci_pci ehci_hcd processo r thermal [   84.458900]
> Pid: 3353, comm: kworker/u:35 Tainted: G        W    3.9.0-rc1 #1
> [   84.458901] Call Trace: [   84.458905]  [<ffffffff8103ef7f>]
> warn_slowpath_common+0x7f/0xc0 [   84.458907]  [<ffffffff8103f076>]
> warn_slowpath_fmt+0x46/0x50 [   84.458910]  [<ffffffff81537bfe>] ?
> _raw_spin_lock_irqsave+0x4e/0x60 [   84.458911]
> [<ffffffff810bc8d5>] ? __free_irq+0x55/0x1e0 [   84.458913]
> [<ffffffff810bc923>] __free_irq+0xa3/0x1e0 [   84.458914]
> [<ffffffff810bcab4>] free_irq+0x54/0xc0 [   84.458919]
> [<ffffffffa017745d>] e1000_free_irq+0x7d/0x90 [e1000e]
> [   84.458922]  [<ffffffffa01834af>] __e1000_shutdown+0x8f/0x8a0
> [e1000e] [   84.458924]  [<ffffffff813c92a7>] ?
> __device_suspend+0xb7/0x200 [   84.458927]  [<ffffffff81073b71>] ?
> get_parent_ip+0x11/0x50 [   84.458931]  [<ffffffffa0183d33>]
> e1000_suspend+0x23/0x50 [e1000e] [   84.458932]
> [<ffffffff813c92a7>] ? __device_suspend+0xb7/0x200 [   84.458933]
> [<ffffffff8153c049>] ? sub_preempt_count+0x79/0xd0 [   84.458936]
> [<ffffffff812a2ff5>] pci_pm_freeze+0x55/0xc0 [   84.458937]
> [<ffffffff812a2fa0>] ? pci_pm_resume_noirq+0xd0/0xd0 [   84.458938]
> [<ffffffff813c8b45>] dpm_run_callback.isra.5+0x25/0x50
> [   84.458939]  [<ffffffff813c92d3>] __device_suspend+0xe3/0x200
> [   84.458941]  [<ffffffff813c940f>] async_suspend+0x1f/0xa0
> [   84.458942]  [<ffffffff8106bcfb>] async_run_entry_fn+0x3b/0x140
> [   84.458944]  [<ffffffff8105d00d>] process_one_work+0x1ed/0x510
> [   84.458946]  [<ffffffff8105cfab>] ? process_one_work+0x18b/0x510
> [   84.458948]  [<ffffffff8105e7b5>] worker_thread+0x115/0x390
> [   84.458949]  [<ffffffff8105e6a0>] ? manage_workers+0x300/0x300
> [   84.458951]  [<ffffffff81064e2a>] kthread+0xea/0xf0
> [   84.458953]  [<ffffffff81064d40>] ?
> kthread_create_on_node+0x160/0x160 [   84.458954]
> [<ffffffff8153ff9c>] ret_from_fork+0x7c/0xb0 [   84.458955]
> [<ffffffff81064d40>] ? kthread_create_on_node+0x160/0x160
> [   84.458956] ---[ end trace 3114e23ce50d2357 ]--- [   85.082276]
> pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2
> [   85.082278] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -2
> [   85.082281] PM: Device 0000:00:19.0 failed to freeze async: error
> -2
> 
> Let's add more folks to CC.
> 

-- 
Mihai Donțu

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* Re: Fw: [Bug 54601] New: PPP regression on 3.2.39 stop work need restart server ont version 3.2.21 not found this problem.
From: Ben Hutchings @ 2013-03-04 22:48 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev, micron10, Eric Dumazet
In-Reply-To: <20130301084705.4169c429@nehalam.linuxnetplumber.net>

On Fri, Mar 01, 2013 at 08:47:05AM -0800, Stephen Hemminger wrote:
> 
> 
> Begin forwarded message:
> 
> Date: Fri, 1 Mar 2013 01:24:14 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 54601] New: PPP regression on 3.2.39 stop work need restart server ont version 3.2.21 not found this problem.
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=54601
> 
>            Summary: PPP regression on 3.2.39 stop work need restart server
>                     ont version 3.2.21 not found this problem.
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 3.2.39
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: Other
>         AssignedTo: shemminger@linux-foundation.org
>         ReportedBy: micron10@gmail.com
>         Regression: Yes
> 
> 
> Hi
> watch a problem with PPP after upgrade to version 3.2.39 ppp service stop work
> 2 hours after start with this crash :
> 
> [79619.180026] unregister_netdevice: waiting for ppp618 to become free. Usage
> count = 562
[...]
> [79862.540040] unregister_netdevice: waiting for ppp618 to become free. Usage
> count = 30
> [79872.680037] unregister_netdevice: waiting for ppp618 to become free. Usage
> count = 9
[...]

So there are many references left to the device, which slowly go away
(very slowly, about 2 per second).  Maybe there are skbs in a queue somewhere
that still refer to the PPP device.

Since this a regression between 3.2.21 and 3.2.29, it might have been
introduced by:

commit 73a3346556281fd56f39f0a9475249e5039d8807
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 14 06:42:44 2012 +0000

    net: remove skb_orphan_try()
    
    commit 62b1a8ab9b3660bb820d8dfe23148ed6cda38574 upstream.

But this is a bit of a guess.  And I don't think that this change
would do more than expose/exacerbate a bug that already existed.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

^ permalink raw reply

* Re: [PATCH -v3 17/23] net/sunrpc: rename random32() to prandom_u32()
From: Myklebust, Trond @ 2013-03-04 22:44 UTC (permalink / raw)
  To: Akinobu Mita
  Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	J. Bruce Fields, David S. Miller, netdev@vger.kernel.org,
	linux-nfs@vger.kernel.org
In-Reply-To: <1362401911-14074-18-git-send-email-akinobu.mita@gmail.com>

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

On Mon, 2013-03-04 at 21:58 +0900, Akinobu Mita wrote:
> Use more preferable function name which implies using a pseudo-random
> number generator.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: linux-nfs@vger.kernel.org
> ---
> 
> No change from v2
> 
>  net/sunrpc/auth_gss/gss_krb5_wrap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sunrpc/auth_gss/gss_krb5_wrap.c b/net/sunrpc/auth_gss/gss_krb5_wrap.c
> index 88edec9..1da52d1 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_wrap.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_wrap.c
> @@ -130,8 +130,8 @@ gss_krb5_make_confounder(char *p, u32 conflen)
>  
>  	/* initialize to random value */
>  	if (i == 0) {
> -		i = random32();
> -		i = (i << 32) | random32();
> +		i = prandom_u32();
> +		i = (i << 32) | prandom_u32();
>  	}
>  
>  	switch (conflen) {

Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [RFC PATCH 0/5] net: low latency Ethernet device polling
From: Ben Hutchings @ 2013-03-04 22:34 UTC (permalink / raw)
  To: Eliezer Tamir
  Cc: Tom Herbert, Stephen Hemminger, Eliezer Tamir, linux-kernel,
	netdev, Dave Miller, Jesse Brandeburg, e1000-devel,
	Willem de Bruijn, Andi Kleen, HPA, Eliezer Tamir
In-Reply-To: <512E5BBD.2040803@linux.intel.com>

On Wed, 2013-02-27 at 21:17 +0200, Eliezer Tamir wrote:
> On 27/02/2013 20:47, Tom Herbert wrote:
> > On Wed, Feb 27, 2013 at 10:13 AM, Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> >>
> >> Have you looked at netmap? Seems like a cleaner user API for this.
> >>
> > That might be a bit orthogonal to this.  I believe the intent it to
> > allow spin polling from socket calls without API change.
> 
> Exactly.
> 
> BTW, an interesting alternative to netmap would be to map a VF into 
> userspace. (you would need to pre-allocate DMA memory regions and all of 
> that RDMA-like stuff)

Unless the hardware has separate event rings for completions, userland
is presumably going to need to be able to rewrite the DMA descriptor
rings.  At which point you have to restrict the VF's DMA with an IOMMU,
and might as well let userland allocate and assign DMA buffers
dynamically.

(In OpenOnload this is called 'scalable buffer mode' as an IOMMU allows
mapping more buffers than the on-board buffer table on the SFC9000
family.  The catch is that an IOMMU has higher latency.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* [PATCH] net: fix new kernel-doc warnings in net core
From: Randy Dunlap @ 2013-03-04 22:32 UTC (permalink / raw)
  To: netdev@vger.kernel.org, David Miller, Linus Torvalds

From: Randy Dunlap <rdunlap@infradead.org>

Fix new kernel-doc warnings in net/core/dev.c:

Warning(net/core/dev.c:4788): No description found for parameter 'new_carrier'
Warning(net/core/dev.c:4788): Excess function parameter 'new_carries' description in 'dev_change_carrier'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
 net/core/dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-39-rc1.orig/net/core/dev.c
+++ lnx-39-rc1/net/core/dev.c
@@ -4780,7 +4780,7 @@ EXPORT_SYMBOL(dev_set_mac_address);
 /**
  *	dev_change_carrier - Change device carrier
  *	@dev: device
- *	@new_carries: new value
+ *	@new_carrier: new value
  *
  *	Change device carrier
  */

^ permalink raw reply

* Re: [PATCH 2/8] netback: add module unload function
From: Stephen Hemminger @ 2013-03-04 21:58 UTC (permalink / raw)
  To: Wei Liu; +Cc: xen-devel, netdev, ian.campbell, konrad.wilk, annie.li
In-Reply-To: <1360944010-15336-3-git-send-email-wei.liu2@citrix.com>

On Fri, 15 Feb 2013 16:00:03 +0000
Wei Liu <wei.liu2@citrix.com> wrote:

> Enable users to unload netback module. Users should make sure there is not vif
> runnig.


Isn't it likely that some admin might be trying to cleanup or do shutdown and there
is an ordering problem. What happens if vif's are still running?

Why depend on users? You should allow it anytime and do refcounting and auto-destroy the vif's for them.

^ permalink raw reply

* Re: [PATCH -v3 16/23] drivers/net: rename random32() to prandom_u32()
From: Akinobu Mita @ 2013-03-04 21:53 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: LKML, Andrew Morton, David S. Miller, Michael Chan, Thomas Sailer,
	Jean-Paul Roubelat, Bing Zhao, Brett Rudley, Franky (Zhenhui) Lin,
	Hante Meuleman, brcm80211-dev-list, netdev, linux-hams,
	linux-wireless
In-Reply-To: <5134A37D.9000704@broadcom.com>

2013/3/4 Arend van Spriel <arend@broadcom.com>
>>
>> @@ -1118,7 +1118,7 @@ static void brcmf_p2p_afx_handler(struct work_struct *work)
>>         if (afx_hdl->is_listen&&  afx_hdl->my_listen_chan)
>>
>>                 /* 100ms ~ 300ms */
>>                 err = brcmf_p2p_discover_listen(p2p, afx_hdl->my_listen_chan,
>> -                                               100 * (1 + (random32() % 3)));
>> +                                       100 * (1 + (prandom_u32() % 3)));
>
>
> Seems like indentation is wrong now. Please retain the alignment.

OK, I'll fix it.

^ permalink raw reply

* [PATCH v5] net: sh_eth: Add support of device tree probe
From: Nobuhiro Iwamatsu @ 2013-03-04 21:52 UTC (permalink / raw)
  To: netdev
  Cc: grant.likely, kuninori.morimoto.gx, devicetree-discuss,
	magnus.damm, horms+renesas, kda, Nobuhiro Iwamatsu

This adds support of device tree probe for Renesas sh-ether driver.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>

V5: - Rewrite sh_eth_parse_dt().
      Remove of_device_is_available() and CONFIG_OF from support OF
      checking function and re-add empty sh_eth_parse_dt().
    - Add CONFIG_PM to definition of dev_pm_ops.
	- Add CONFIG_OF to definition of of_device_id.
V4: - Remove empty sh_eth_parse_dt().
V3: - Remove empty sh_eth_parse_dt().
V3: - Removed sentnece of "needs-init" from document.
V2: - Removed ether_setup().
    - Fixed typo from "sh-etn" to "sh-eth".
	- Removed "needs-init" and sh-eth,endian from definition of DT.
	- Changed "sh-eth,edmac-endian" instead of "sh-eth,edmac-big-endain"
	  in definition of DT.
---
 Documentation/devicetree/bindings/net/sh_ether.txt |   39 +++++
 drivers/net/ethernet/renesas/sh_eth.c              |  164 +++++++++++++++++---
 2 files changed, 178 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/sh_ether.txt

diff --git a/Documentation/devicetree/bindings/net/sh_ether.txt b/Documentation/devicetree/bindings/net/sh_ether.txt
new file mode 100644
index 0000000..2deb841
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/sh_ether.txt
@@ -0,0 +1,39 @@
+* Renesas Electronics SuperH EMAC
+
+This file provides information, what the device node
+for the sh_eth interface contains.
+
+Required properties:
+- compatible:                   "renesas,sh-eth";
+- interrupt-parent:             The phandle for the interrupt controller that
+                                services interrupts for this device.
+- reg:                          Offset and length of the register set for the
+                                device.
+- interrupts:                   Interrupt mapping for the sh_eth interrupt
+                                sources (vector id).
+- phy-mode:                     String, operation mode of the PHY interface.
+- sh-eth,register-type:         String, register type of sh_eth.
+                                Please select "gigabit", "fast-sh4" or
+                                "fast-sh3-sh2".
+- sh-eth,phy-id:                PHY id.
+
+Optional properties:
+- local-mac-address:            6 bytes, mac address
+- sh-eth,no-ether-link:         Set link control by software. When device does
+                                not support ether-link, set.
+- sh-eth,ether-link-active-low: Set link check method.
+                                When detection of link is treated as active-low,
+                                set.
+- sh-eth,edmac-big-endian:      Set big endian for sh_eth dmac.
+                                It work as little endian when this is not set.
+
+Example (armadillo800eva):
+	sh-eth@e9a00000 {
+		compatible = "renesas,sh-eth";
+		interrupt-parent = <&intca>;
+		reg = <0xe9a00000 0x800>, <0xe9a01800 0x800>;
+		interrupts = <0x500>;
+		phy-mode = "mii";
+		sh-eth,register-type = "gigabit";
+		sh-eth,phy-id = <0>;
+	};
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 3d70586..a97d208 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1,7 +1,7 @@
 /*
  *  SuperH Ethernet device driver
  *
- *  Copyright (C) 2006-2012 Nobuhiro Iwamatsu
+ *  Copyright (C) 2006-2013 Nobuhiro Iwamatsu
  *  Copyright (C) 2008-2012 Renesas Solutions Corp.
  *
  *  This program is free software; you can redistribute it and/or modify it
@@ -31,6 +31,12 @@
 #include <linux/platform_device.h>
 #include <linux/mdio-bitbang.h>
 #include <linux/netdevice.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
 #include <linux/phy.h>
 #include <linux/cache.h>
 #include <linux/io.h>
@@ -2347,26 +2353,109 @@ static const struct net_device_ops sh_eth_netdev_ops = {
 	.ndo_change_mtu		= eth_change_mtu,
 };
 
+#ifdef CONFIG_OF
+static int
+sh_eth_of_get_register_type(struct device_node *np)
+{
+	const char *of_str;
+	int ret = of_property_read_string(np, "sh-eth,register-type", &of_str);
+	if (ret)
+		return ret;
+
+	if (of_str && !strcmp(of_str, "gigabit"))
+		return SH_ETH_REG_GIGABIT;
+
+	else if (of_str && !strcmp(of_str, "fast-sh4"))
+		return SH_ETH_REG_FAST_SH4;
+	else if (of_str && !strcmp(of_str, "fast-sh3-sh2"))
+		return SH_ETH_REG_FAST_SH3_SH2;
+	else
+		return -EINVAL;
+}
+
+static struct sh_eth_plat_data *
+sh_eth_parse_dt(struct device *dev, struct net_device *ndev,
+				struct device_node *np)
+{
+	int ret;
+	struct sh_eth_plat_data *pdata;
+
+	pdata = devm_kzalloc(dev, sizeof(struct sh_eth_plat_data),
+					GFP_KERNEL);
+	if (!pdata) {
+		dev_err(dev, "%s: failed to allocate config data\n", __func__);
+		return NULL;
+	}
+
+	pdata->phy_interface = of_get_phy_mode(np);
+
+	of_property_read_u32(np, "sh-eth,phy-id", &pdata->phy);
+
+	if (of_find_property(np, "sh-eth,edmac-big-endian", NULL))
+		pdata->edmac_endian = EDMAC_BIG_ENDIAN;
+	else
+		pdata->edmac_endian = EDMAC_LITTLE_ENDIAN;
+
+	if (of_find_property(np, "sh-eth,no-ether-link", NULL))
+		pdata->no_ether_link = 1;
+	else
+		pdata->no_ether_link = 0;
+
+	if (of_find_property(np, "sh-eth,ether-link-active-low", NULL))
+		pdata->ether_link_active_low = 1;
+	else
+		pdata->ether_link_active_low = 0;
+
+	ret = sh_eth_of_get_register_type(np);
+	if (ret < 0)
+		goto error;
+	pdata->register_type = ret;
+
+#ifdef CONFIG_OF_NET
+	if (!is_valid_ether_addr(ndev->dev_addr)) {
+		const char *macaddr = of_get_mac_address(np);
+		if (macaddr)
+			memcpy(pdata->mac_addr, macaddr, ETH_ALEN);
+	}
+#endif
+
+	return pdata;
+
+error:
+	devm_kfree(dev, pdata);
+	return NULL;
+}
+#else
+static inline struct sh_eth_plat_data *
+sh_eth_parse_dt(struct device *dev, struct net_device *ndev,
+				struct device_node *np)
+{
+	return NULL;
+}
+#endif
+
 static int sh_eth_drv_probe(struct platform_device *pdev)
 {
-	int ret, devno = 0;
+	int ret = 0, devno = 0;
 	struct resource *res;
 	struct net_device *ndev = NULL;
 	struct sh_eth_private *mdp = NULL;
 	struct sh_eth_plat_data *pd;
+	struct device_node *np = pdev->dev.of_node;
 
+	ndev = alloc_etherdev(sizeof(struct sh_eth_private));
+	if (!ndev) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	mdp = netdev_priv(ndev);
 	/* get base addr */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (unlikely(res == NULL)) {
 		dev_err(&pdev->dev, "invalid resource\n");
 		ret = -EINVAL;
-		goto out;
-	}
-
-	ndev = alloc_etherdev(sizeof(struct sh_eth_private));
-	if (!ndev) {
-		ret = -ENOMEM;
-		goto out;
+		goto out_release;
 	}
 
 	/* The sh Ether-specific entries in the device structure. */
@@ -2383,14 +2472,6 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
 	}
 	ndev->irq = ret;
 
-	SET_NETDEV_DEV(ndev, &pdev->dev);
-
-	/* Fill in the fields of the device structure with ethernet values. */
-	ether_setup(ndev);
-
-	mdp = netdev_priv(ndev);
-	mdp->num_tx_ring = TX_RING_SIZE;
-	mdp->num_rx_ring = RX_RING_SIZE;
 	mdp->addr = ioremap(res->start, resource_size(res));
 	if (mdp->addr == NULL) {
 		ret = -ENOMEM;
@@ -2398,12 +2479,33 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
 		goto out_release;
 	}
 
+	if (np) {
+		pd = sh_eth_parse_dt(&pdev->dev, ndev, np);
+		if (pdev->dev.platform_data && pd) {
+			struct sh_eth_plat_data *tmp =
+				pdev->dev.platform_data;
+			pd->set_mdio_gate = tmp->set_mdio_gate;
+			pd->needs_init = tmp->needs_init;
+		}
+	} else
+		pd = pdev->dev.platform_data;
+
+	if (!pd) {
+		dev_err(&pdev->dev, "no setup data defined\n");
+		ret = -EINVAL;
+		goto out_release;
+	}
+
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	mdp->num_tx_ring = TX_RING_SIZE;
+	mdp->num_rx_ring = RX_RING_SIZE;
+
 	spin_lock_init(&mdp->lock);
 	mdp->pdev = pdev;
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_resume(&pdev->dev);
 
-	pd = (struct sh_eth_plat_data *)(pdev->dev.platform_data);
 	/* get PHY ID */
 	mdp->phy_id = pd->phy;
 	mdp->phy_interface = pd->phy_interface;
@@ -2412,6 +2514,8 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
 	mdp->no_ether_link = pd->no_ether_link;
 	mdp->ether_link_active_low = pd->ether_link_active_low;
 	mdp->reg_offset = sh_eth_get_register_offset(pd->register_type);
+	/* read and set MAC address */
+	read_mac_address(ndev, pd->mac_addr);
 
 	/* set cpu data */
 #if defined(SH_ETH_HAS_BOTH_MODULES)
@@ -2429,20 +2533,16 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
 	/* debug message level */
 	mdp->msg_enable = SH_ETH_DEF_MSG_ENABLE;
 
-	/* read and set MAC address */
-	read_mac_address(ndev, pd->mac_addr);
-
 	/* ioremap the TSU registers */
 	if (mdp->cd->tsu) {
 		struct resource *rtsu;
 		rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 		if (!rtsu) {
 			dev_err(&pdev->dev, "Not found TSU resource\n");
-			ret = -ENODEV;
 			goto out_release;
 		}
 		mdp->tsu_addr = ioremap(rtsu->start,
-					resource_size(rtsu));
+				resource_size(rtsu));
 		mdp->port = devno % 2;
 		ndev->features = NETIF_F_HW_VLAN_FILTER;
 	}
@@ -2509,6 +2609,7 @@ static int sh_eth_drv_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_PM
 static int sh_eth_runtime_nop(struct device *dev)
 {
 	/*
@@ -2522,17 +2623,30 @@ static int sh_eth_runtime_nop(struct device *dev)
 	return 0;
 }
 
-static struct dev_pm_ops sh_eth_dev_pm_ops = {
+static const struct dev_pm_ops sh_eth_dev_pm_ops = {
 	.runtime_suspend = sh_eth_runtime_nop,
 	.runtime_resume = sh_eth_runtime_nop,
 };
+#define SH_ETH_PM_OPS (&sh_eth_dev_pm_ops)
+#else
+#define SH_ETH_PM_OPS NULL
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id sh_eth_match[] = {
+	{ .compatible = "renesas,sh-eth", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sh_eth_match);
+#endif
 
 static struct platform_driver sh_eth_driver = {
 	.probe = sh_eth_drv_probe,
 	.remove = sh_eth_drv_remove,
 	.driver = {
 		   .name = CARDNAME,
-		   .pm = &sh_eth_dev_pm_ops,
+		   .pm = SH_ETH_PM_OPS,
+		   .of_match_table = of_match_ptr(sh_eth_match),
 	},
 };
 
-- 
1.7.10.4

^ permalink raw reply related

* e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)
From: Borislav Petkov @ 2013-03-04 21:48 UTC (permalink / raw)
  To: Morten Stevens
  Cc: Mihai Donțu, linux-kernel, Rafael J. Wysocki, e1000-devel,
	netdev, Jiri Slaby
In-Reply-To: <5134E4AB.2010504@imt-systems.com>

On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote:
> Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest
> upstream driver (e1000e 2.2.14) which contains many bugfixes.

This e1000e thing gets more b0rked by the minute. This is what happens
when I try to suspend with 3.9-rc1:

[   83.502908] PM: Syncing filesystems ... done.
[   83.509886] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   83.523352] PM: Preallocating image memory... done (allocated 95652 pages)
[   83.675083] PM: Allocated 382608 kbytes in 0.15 seconds (2550.72 MB/s)
[   83.675782] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[   83.688524] Suspending console(s) (use no_console_suspend to debug)
[   84.251024] e1000e 0000:00:19.0 eth0: Hardware Error
[   84.458866] ------------[ cut here ]------------
[   84.458871] WARNING: at kernel/irq/manage.c:1249 __free_irq+0xa3/0x1e0()
[   84.458872] Hardware name: 2320CTO
[   84.458872] Trying to free already-free IRQ 20
[   84.458898] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats uinput loop hid_generic usb
hid hid coretemp kvm_intel arc4 kvm crc32_pclmul iwldvm crc32c_intel ghash_clmulni_intel mac80211 aesni_intel xts ipv6 aes_x86_64 lr
w gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support iwlwifi sdhci_pci sdhci cfg80211 snd_hda_codec_hdmi snd_hda_codec_realtek
 mmc_core microcode e1000e thinkpad_acpi pcspkr lpc_ich i2c_i801 mfd_core nvram snd_hda_intel rfkill snd_hda_codec battery ac snd_hw
dep led_class snd_pcm snd_page_alloc snd_timer snd acpi_cpufreq soundcore mperf ptp wmi pps_core xhci_hcd ehci_pci ehci_hcd processo
r thermal
[   84.458900] Pid: 3353, comm: kworker/u:35 Tainted: G        W    3.9.0-rc1 #1
[   84.458901] Call Trace:
[   84.458905]  [<ffffffff8103ef7f>] warn_slowpath_common+0x7f/0xc0
[   84.458907]  [<ffffffff8103f076>] warn_slowpath_fmt+0x46/0x50
[   84.458910]  [<ffffffff81537bfe>] ? _raw_spin_lock_irqsave+0x4e/0x60
[   84.458911]  [<ffffffff810bc8d5>] ? __free_irq+0x55/0x1e0
[   84.458913]  [<ffffffff810bc923>] __free_irq+0xa3/0x1e0
[   84.458914]  [<ffffffff810bcab4>] free_irq+0x54/0xc0
[   84.458919]  [<ffffffffa017745d>] e1000_free_irq+0x7d/0x90 [e1000e]
[   84.458922]  [<ffffffffa01834af>] __e1000_shutdown+0x8f/0x8a0 [e1000e]
[   84.458924]  [<ffffffff813c92a7>] ? __device_suspend+0xb7/0x200
[   84.458927]  [<ffffffff81073b71>] ? get_parent_ip+0x11/0x50
[   84.458931]  [<ffffffffa0183d33>] e1000_suspend+0x23/0x50 [e1000e]
[   84.458932]  [<ffffffff813c92a7>] ? __device_suspend+0xb7/0x200
[   84.458933]  [<ffffffff8153c049>] ? sub_preempt_count+0x79/0xd0
[   84.458936]  [<ffffffff812a2ff5>] pci_pm_freeze+0x55/0xc0
[   84.458937]  [<ffffffff812a2fa0>] ? pci_pm_resume_noirq+0xd0/0xd0
[   84.458938]  [<ffffffff813c8b45>] dpm_run_callback.isra.5+0x25/0x50
[   84.458939]  [<ffffffff813c92d3>] __device_suspend+0xe3/0x200
[   84.458941]  [<ffffffff813c940f>] async_suspend+0x1f/0xa0
[   84.458942]  [<ffffffff8106bcfb>] async_run_entry_fn+0x3b/0x140
[   84.458944]  [<ffffffff8105d00d>] process_one_work+0x1ed/0x510
[   84.458946]  [<ffffffff8105cfab>] ? process_one_work+0x18b/0x510
[   84.458948]  [<ffffffff8105e7b5>] worker_thread+0x115/0x390
[   84.458949]  [<ffffffff8105e6a0>] ? manage_workers+0x300/0x300
[   84.458951]  [<ffffffff81064e2a>] kthread+0xea/0xf0
[   84.458953]  [<ffffffff81064d40>] ? kthread_create_on_node+0x160/0x160
[   84.458954]  [<ffffffff8153ff9c>] ret_from_fork+0x7c/0xb0
[   84.458955]  [<ffffffff81064d40>] ? kthread_create_on_node+0x160/0x160
[   84.458956] ---[ end trace 3114e23ce50d2357 ]---
[   85.082276] pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2
[   85.082278] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -2
[   85.082281] PM: Device 0000:00:19.0 failed to freeze async: error -2

Let's add more folks to CC.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply

* Re: [PATCH] net: netfilter: nfnetlink: Fixed warning for nfnl_get_lock
From: Borislav Petkov @ 2013-03-04 21:42 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Alexandru Gheorghiu, Patrick McHardy, David S. Miller, netdev,
	linux-kernel
In-Reply-To: <20130304212338.GA3594@localhost>

On Mon, Mar 04, 2013 at 10:23:38PM +0100, Pablo Neira Ayuso wrote:
> Already got a fix for compilation warning in my tree:
> 
> http://1984.lsi.us.es/git/nf/commit/?id=9df9e7832391cf699abbf39fc8d95d7e78297462

And it even explains why gcc complains.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ 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