Re: [PATCH linux-firmware] linux-firmware: liquidio: fix GPL compliance issue

2018-10-18 Thread Josh Boyer 
On Wed, Oct 17, 2018 at 5:09 PM John W. Linville  wrote:
>
> On Wed, Oct 17, 2018 at 07:34:42PM +, Manlunas, Felix wrote:
> > On Fri, Sep 28, 2018 at 04:50:51PM -0700, Felix Manlunas wrote:
> > > Part of the code inside the lio_vsw_23xx.bin firmware image is under GPL,
> > > but the LICENCE.cavium file neglects to indicate that.  However,
> > > LICENCE.cavium does correctly specify the license that covers the other
> > > Cavium firmware images that do not contain any GPL code.
> > >
> > > Fix the GPL compliance issue by adding a new file, 
> > > LICENCE.cavium_liquidio,
> > > which correctly shows the GPL boilerplate.  This new file specifies the
> > > licenses for all liquidio firmware, including the ones that do not have
> > > GPL code.
> > >
> > > Change the liquidio section of WHENCE to point to LICENCE.cavium_liquidio.
> > >
> > > Reported-by: Florian Weimer 
> > > Signed-off-by: Manish Awasthi 
> > > Signed-off-by: Manoj Panicker 
> > > Signed-off-by: Faisal Masood 
> > > Signed-off-by: Felix Manlunas 
> > > ---
> > >  LICENCE.cavium_liquidio | 429 
> > > 
> > >  WHENCE  |   2 +-
> > >  2 files changed, 430 insertions(+), 1 deletion(-)
> > >  create mode 100644 LICENCE.cavium_liquidio
> >
> > Hello Maintainers of linux-firmware.git,
> >
> > Any feedback about this patch?
>
> I would prefer to see an offer that included a defined URL for anyone
> to download the source for the kernel in question without having to
> announce themselves. The "send an email to i...@cavium.com" offer may
> (or may not) be sufficient for the letter of the law. But it seems
> both fragile and prone to subjective frustrations and delays for
> users to obtain the sources at some future date.

I agree with John here, but I also believe the patch is better than
the current text in the upstream repo.  I've committed it and pushed
it out.  If there are improvements to be made on source availability,
we can take those in a different patch.

Thank you for taking this seriously and responding quickly.

josh

Re: [PATCH linux-firmware] Mellanox: Add new mlxsw_spectrum firmware 13.1702.6

2018-07-27 Thread Josh Boyer 
Applied and pushed out.

josh
On Sun, Jul 22, 2018 at 7:43 AM Nir Dotan  wrote:
>
> This new firmware contains: - Support for new types of cables - Support for 
> flashing future firmware without reboot - Support for Router ARP BC and UC 
> traps Signed-off-by: Nir Dotan --- WHENCE | 3 ++- 
> mellanox/mlxsw_spectrum-13.1702.6.mfa2 | Bin 0 -> 863220 bytes 2 files 
> changed, 2 insertions(+), 1 deletion(-) create mode 100644 
> mellanox/mlxsw_spectrum-13.1702.6.mfa2 diff --git a/WHENCE b/WHENCE index 
> 6771831..cdc78ba 100644 --- a/WHENCE +++ b/WHENCE @@ -4050,9 +4050,10 @@ 
> Driver: mlxsw_spectrum - Mellanox Spectrum switch File: 
> mellanox/mlxsw_spectrum-13.1420.122.mfa2 File: 
> mellanox/mlxsw_spectrum-13.1530.152.mfa2 File: 
> mellanox/mlxsw_spectrum-13.1620.192.mfa2 +File: 
> mellanox/mlxsw_spectrum-13.1702.6.mfa2 Licence: - Copyright (c) 2017 Mellanox 
> Technologies, Ltd. All rights reserved. + Copyright (c) 2017-2018 Mellanox 
> Technologies, Ltd. All rights reserved. Redistribution and use in source and 
> binary forms, with or without modification, are permitted provided that the 
> following conditions are met: diff --git 
> a/mellanox/mlxsw_spectrum-13.1702.6.mfa2 
> b/mellanox/mlxsw_spectrum-13.1702.6.mfa2 new file mode 100644 index 
> ..0186d19c8285f161d2ffc6644e8451ff448e1684
>  GIT binary patch literal 863220 
> zcma}I-ySoJq?(PJ4cXuafa19>Z-QC@TJHg%E-Q9j>=Dm9N{xkPZHdRzo 
> z^;Oenb@yIt?>f>_GHSHaBK(ZBY8tfk^n?H)04M+i-~s>!-~yOFegMdr0644_z{dqX 
> zj?kAM8*A_Tw!NdthfVxS2A`F}D1L54q+7Jk4ZL)i4(M*O6%z1p)MWIYu?0og5# 
> zs;d2Z3-Do_hBdWTUTmO^FE-bQj)2dT-{-#LLO@HU?}NuM;t0F{^X~(HLd0NCp5P0ziJ4e_j8`_5Zhw|7QQC|J~C6&{q5T8ThX)3+w;c
>  ze`E;w5BdI2SO#Y1|FfX~|A&0R|H3kTB*DPI@~1U}_*={RCky$vmibQ> 
> z>TfO6pDgs>TE;(Fn7_3Qf3mRu%jy1W@c+sFqbL8lzJIm|e_{Wp 
> zALyAm{sI2gzleWf{}q?xPoE9xFDxTF>%Y|)`ETu?YmD-@_Rlp&{agFz8l(NK{d0}c 
> z|JMGw#u)$2{-MU0e_{W(7VLkh1=e5Kf35GIYmEID_J89tGyVhotHwD0#j^b);a2 
> zjBG3)HU4ug@c!2RdFDU;H~WVi@c-8SxyA&4YyVth!oRYt|9-C~`b*37Z})ZLzq0>a 
> zvp@F^$$zpRGykvk{d0{!|0nw~^Z&_`{)PSDe)!{_MfMk#k)8eDJ{$R8*#C{o_J{tZ 
> z_Xqt=Ni-hm1Sc4w^}g#h5g@Ju>N5`{^$7r^GpB)Ao)0*{Odmd_J-| 
> zac+VG2NV!sLj2#o`v12?SZV+w!lvJ{LRu>~^=eOb} 
> zkG1}GzCVx3K5X4@#a#op{jlGD$9^20Z$9jAtphL-kJ*RS`>nV_Y6}1(#e_CXQbK 
> zL@H9hWrK&)KCIAh*;2xb5BtyOl>atwz@si7v-z7joR592Hq=xdJ3fSMqWiJ`&-?3mQiXZn90=?g|EZ=Z{H(xN-xL^Pg(Zp}Xb#45p1tIxw+0=!s
>  zk2A)?Z`roRj~oDlzh&2#^Z-P;O21>lfjvL=0Kjj}8#syAN3R2ZYc9Y=yyZS@=Wpd; 
> z=0ot2FXnIAP~wks#>;Qb5O_HOH-PXt?f;Ma%I2n~@$q)UoM?^pW1j%}#{ 
> zlKuI+HUKFqfaDDt>~J%Zvf+pIiBH6}n7JaSv6XkZ@-8-X3#T1yo=%rszZS7~rV|9Y 
> zqTziaO|W*}(ME-pJ_gbRH%QKlj_0~rr=tejK}M-3{=Pd(v=x!6}^N 
> z2V}^`u|UUEuvwh=MqHTs)6ZX9>PQHjtJ+D~_z#>no%IfEG6tos=s|n7QP7c$X(F 
> z)}pf`%+Uk+BrQJ9n`$vgv@x9<_0*$_jCBJ3hAnN)x{wqSFi;R_wAbegih)~v|E#7p 
> z(YjVBJ`ly|_hQ-N+Pk>VNf?r`lNu#8o8SWkd-Bv4Tb!C2I>^I63OaMEJf~Rc{ZG9a 
> zzD{?r5+8BG9U5$BUkq4ZqPTYG+-#|zr_=djA46<=ba`IPVd_@i8oiz5K1!;dx7 
> z4U}^9h(C{m`5(PUpokm!Y5f|^J$XzyE-JD4wsCL5H1sX1Km0}6SNYDXq^8N2MslTb 
>

Re: pull request Cavium liquidio vswitch firmware v1.7.2

2018-06-06 Thread Josh Boyer 
On Wed, Jun 6, 2018 at 1:13 PM Felix Manlunas  wrote:
>
> On Mon, May 21, 2018 at 10:39:20AM -0700, Felix Manlunas wrote:
> > The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> >
> >   Merge branch 'for-upstreaming-v1.7.2' of 
> > https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
> >
> > are available in the git repository at:
> >
> >   https://github.com/felix-cavium/linux-firmware.git 
> > for-upstreaming-v1.7.2-vsw
> >
> > for you to fetch changes up to 0e193ca65d8b064502d61163597bf14eef81710f:
> >
> >   linux-firmware: liquidio: update vswitch firmware to v1.7.2 (2018-05-19 
> > 23:29:03 -0700)
> >
> > Signed-off-by: Manish Awasthi 
> > Signed-off-by: Felix Manlunas 
> > 
> > Felix Manlunas (1):
> >   linux-firmware: liquidio: update vswitch firmware to v1.7.2
> >
> >  WHENCE|   2 +-
> >  liquidio/lio_23xx_vsw.bin | Bin 19922416 -> 20434408 bytes
> >  2 files changed, 1 insertion(+), 1 deletion(-)
>
> Hello Maintainers of linux-firmware.git,
>
> Any feedback about this submission?  We sent it two weeks ago, but we
> haven't heard anything.

Thanks for the ping.  I missed this one and then confused it with an
older pull request with a similar subject line.  I've pulled and
pushed out now.

josh

Re: [PATCH v2 1/1] qed: Add firmware 8.37.2.0

2018-05-25 Thread Josh Boyer 
On Mon, May 21, 2018 at 10:25 AM Rahul Verma  wrote:

> This patch add a new qed firmware with fixes and added
> support for new features.
> -Fix aRFS for tunneled traffic without inner IP.
> -Fix chip configuration which may fail under heavy traffic conditions.
> -Fix iSCSI recovery flow.
> -Support receiving any-VNI in VXLAN and GENEVE RX classification.
> -Support additional RoCE statistics for error cases.
> -Support RoCE T10DIF.

> v1->v2:
> Added signoff for Ariel Elior.

> Signed-off-by: Rahul Verma 
> Signed-off-by: Ariel Elior 
> ---
>   WHENCE  |   1 +
>   qed/qed_init_values_zipped-8.37.2.0.bin | Bin 0 -> 867472 bytes
>   2 files changed, 1 insertion(+)
>   create mode 100755 qed/qed_init_values_zipped-8.37.2.0.bin

Applied and pushed out.

josh

Re: pull-request Cavium liquidio firmware v1.7.2

2018-05-18 Thread Josh Boyer 
On Wed, May 9, 2018 at 12:54 AM Felix Manlunas 
wrote:

> The following changes since commit
8fc2d4e55685bf73b6f7752383da9067404a74bb:

>Merge git://git.marvell.com/mwifiex-firmware (2018-05-07 09:09:40 -0400)

> are available in the git repository at:

>https://github.com/felix-cavium/linux-firmware.git
for-upstreaming-v1.7.2

> for you to fetch changes up to d3b6941e1a85cbff895a92aa9e36b50deaeac970:

>linux-firmware: liquidio: update firmware to v1.7.2 (2018-05-08
19:02:41 -0700)

> Signed-off-by: Felix Manlunas 
> 
> Felix Manlunas (1):
>linux-firmware: liquidio: update firmware to v1.7.2

>   WHENCE |   8 
>   liquidio/lio_210nv_nic.bin | Bin 1265368 -> 1281464 bytes
>   liquidio/lio_210sv_nic.bin | Bin 1163128 -> 1179352 bytes
>   liquidio/lio_23xx_nic.bin  | Bin 1271456 -> 1287264 bytes
>   liquidio/lio_410nv_nic.bin | Bin 1265368 -> 1281464 bytes
>   5 files changed, 4 insertions(+), 4 deletions(-)

Pulled and pushed out.  Thanks.

josh

Re: [PATCH linux-firmware] Mellanox: Add new mlxsw_spectrum firmware 13.1620.192

2018-03-12 Thread Josh Boyer 
On Tue, Feb 27, 2018 at 3:51 AM, Tal Bar  wrote:
> This new firmware contains:
> - Support for auto-neg disable mode
>
> Signed-off-by: Tal Bar 
> ---
>  WHENCE   |   1 +
>  mellanox/mlxsw_spectrum-13.1620.192.mfa2 | Bin 0 -> 1091848 bytes
>  2 files changed, 1 insertion(+)
>  create mode 100644 mellanox/mlxsw_spectrum-13.1620.192.mfa2

Applied and pushed out.  Thanks.

josh

Re: [PATCH 1/1] qed: Add firmware 8.33.11.0

2018-03-12 Thread Josh Boyer 
On Feb 28, Rahul Verma wrote:
> This patch add a new qed firmware with fixes and added
> support for new features.
> -Support VLAN remove action in steering flow.
> -Optimized the FW flow and several bug fixes.
> -Allow VXLAN steering.
> -Supports T10DIF and SRQ.
> -Support for port redirection for RDMA bonding
>
> Signed-off-by: Rahul Verma 
> ---
>  WHENCE   |   1 +
>  qed/qed_init_values_zipped-8.33.11.0.bin | Bin 0 -> 852456 bytes
>  2 files changed, 1 insertion(+)
>  create mode 100755 qed/qed_init_values_zipped-8.33.11.0.bin

I had to fixup a small conflict in WHENCE, but no big deal.  Applied
and pushed out.

josh

Re: [PATCH] rtl_bt: Add firmware and configuration files for the Bluetooth parts of RTL8821C and RTL8723D

2018-02-13 Thread Josh Boyer 
On Sun, Feb 11, 2018 at 1:06 PM, Larry Finger  wrote:
> These devices are new models from Realtek. Updates to driver btrtl will
> soon be submitted to the kernel.
>
> These files were provided by the Realtek developer.
>
> Signed-off-by: 陆朱伟 
> Signed-off-by: Larry Finger 
> ---
>  WHENCE |   5 +
>  rtl_bt/rtl8723d_config.bin | Bin 0 -> 10 bytes
>  rtl_bt/rtl8723d_fw.bin | Bin 0 -> 47028 bytes
>  rtl_bt/rtl8821c_config.bin | Bin 0 -> 10 bytes
>  rtl_bt/rtl8821c_fw.bin | Bin 0 -> 37356 bytes
>  5 files changed, 5 insertions(+)
>  create mode 100644 rtl_bt/rtl8723d_config.bin
>  create mode 100644 rtl_bt/rtl8723d_fw.bin
>  create mode 100644 rtl_bt/rtl8821c_config.bin
>  create mode 100644 rtl_bt/rtl8821c_fw.bin

Applied and pushed out.  Thanks!

josh

Re: [PATCH] rtlwifi: rtl8723de: Add firmware for new driver/device

2018-01-03 Thread Josh Boyer 
On Tue, Jan 2, 2018 at 7:44 PM, Larry Finger  wrote:
> A driver for the RTL8723DE is nearing submission to staging. This commit 
> supplies
> the firmware for it.
>
> Signed-off-by: Larry Finger 
> Cc: Ping-Ke Shih 
> ---
>  WHENCE  |   9 +
>  rtlwifi/rtl8723defw.bin | Bin 0 -> 27726 bytes
>  2 files changed, 9 insertions(+)
>  create mode 100644 rtlwifi/rtl8723defw.bin

Applied and pushed out.  Thanks.

josh

Re: [PATCH] can: check for null sk before deferencing it via the call to sock_net

2017-10-16 Thread Josh Boyer 
On Fri, Sep 8, 2017 at 1:46 PM, Oliver Hartkopp  wrote:
>
>
> On 09/08/2017 05:02 PM, Colin King wrote:
>>
>> From: Colin Ian King 
>>
>> The assignment of net via call sock_net will dereference sk. This
>> is performed before a sanity null check on sk, so there could be
>> a potential null dereference on the sock_net call if sk is null.
>> Fix this by assigning net after the sk null check. Also replace
>> the sk == NULL with the more usual !sk idiom.
>>
>> Detected by CoverityScan CID#1431862 ("Dereference before null check")
>>
>> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM
>> protocol")
>> Signed-off-by: Colin Ian King 
>
>
> Acked-by: Oliver Hartkopp 

I don't see this one queued up in the net or net-next trees.  Did it
fall through the cracks or did it get queued up elsewhere?  Seems like
it's a good candidate to get into 4.14?

josh

>
>
> Thanks Collin!
>
>
>> ---
>>   net/can/bcm.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/can/bcm.c b/net/can/bcm.c
>> index 47a8748d953a..a3791674b8ce 100644
>> --- a/net/can/bcm.c
>> +++ b/net/can/bcm.c
>> @@ -1493,13 +1493,14 @@ static int bcm_init(struct sock *sk)
>>   static int bcm_release(struct socket *sock)
>>   {
>> struct sock *sk = sock->sk;
>> -   struct net *net = sock_net(sk);
>> +   struct net *net;
>> struct bcm_sock *bo;
>> struct bcm_op *op, *next;
>>   - if (sk == NULL)
>> +   if (!sk)
>> return 0;
>>   + net = sock_net(sk);
>> bo = bcm_sk(sk);
>> /* remove bcm_ops, timer, rx_unregister(), etc. */
>>
>

ibss.c backtrace when batman-adv adds wireless interface

2016-02-03 Thread Josh Boyer 
Hi All,

We've had a user report the backtrace below when loading batman-adv on
his machine.  It looks like the cfg80211 layer is complaining about a
null bss returned, but I cannot tell if the rtlwifi driver or
batman-adv is in error here.

Thoughts?

josh

Jan 28 22:29:21 melissa.gathman.org kernel: batman_adv: B.A.T.M.A.N.
advanced 2015.2 (compatibility version 15) loaded
Jan 28 22:29:21 melissa.gathman.org kernel: wlp0s26u1u4: Selected IBSS
BSSID 02:1a:a0:3a:a6:ff based on configured SSID
Jan 28 22:29:21 melissa.gathman.org kernel: [ cut here ]
Jan 28 22:29:21 melissa.gathman.org kernel: WARNING: CPU: 1 PID: 111
at net/wireless/ibss.c:35 __cfg80211_ibss_joined+0x166/0x190
[cfg80211]()
Jan 28 22:29:21 melissa.gathman.org kernel: Modules linked in:
batman_adv libcrc32c xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 xt_conntrack tun ebtable_filter ebtable_nat
ebtable_broute bridge stp llc ebtables ip6table_mangle ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw
ip6table_security ip6table_filter ip6_tables iptable_mangle
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack iptable_raw iptable_security arc4 rtl8192cu rtl_usb
rtl8192c_common rtlwifi mac80211 cfg80211 rfkill uvcvideo
videobuf2_vmalloc videobuf2_core videobuf2_memops v4l2_common
intel_rapl snd_hda_codec_hdmi snd_usb_audio joydev snd_usbmidi_lib
snd_hda_codec_realtek iosf_mbi x86_pkg_temp_thermal videodev coretemp
kvm_intel
Jan 28 22:29:21 melissa.gathman.org kernel:  media snd_rawmidi cm109
snd_hda_codec_generic kvm snd_hda_intel iTCO_wdt snd_hda_codec
iTCO_vendor_support crct10dif_pclmul snd_hda_core ppdev snd_hwdep
snd_seq snd_seq_device snd_pcm crc32_pclmul crc32c_intel snd_timer snd
dcdbas lpc_ich mei_me parport_pc parport shpchp i2c_i801 mei tpm_tis
tpm soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc
hid_microsoft i915 i2c_algo_bit drm_kms_helper drm e1000e serio_raw
ptp pps_core fjes video
Jan 28 22:29:21 melissa.gathman.org kernel: CPU: 1 PID: 111 Comm:
kworker/u32:5 Not tainted 4.3.3-301.fc23.x86_64 #1
Jan 28 22:29:21 melissa.gathman.org kernel: Hardware name: Dell Inc.
OptiPlex 790/0HY9JP, BIOS A06 07/25/2011
Jan 28 22:29:21 melissa.gathman.org kernel: Workqueue: cfg80211
cfg80211_event_work [cfg80211]
Jan 28 22:29:21 melissa.gathman.org kernel:  
8beeeb5f 8800368bfce0 813a626f
Jan 28 22:29:21 melissa.gathman.org kernel:  
8800368bfd18 810a07c2 8800c2bc8850
Jan 28 22:29:21 melissa.gathman.org kernel:  8800c2bc8000
8801275bd558  0286
Jan 28 22:29:21 melissa.gathman.org kernel: Call Trace:
Jan 28 22:29:21 melissa.gathman.org kernel:  []
dump_stack+0x44/0x55
Jan 28 22:29:21 melissa.gathman.org kernel:  []
warn_slowpath_common+0x82/0xc0
Jan 28 22:29:21 melissa.gathman.org kernel:  []
warn_slowpath_null+0x1a/0x20
Jan 28 22:29:21 melissa.gathman.org kernel:  []
__cfg80211_ibss_joined+0x166/0x190 [cfg80211]
Jan 28 22:29:21 melissa.gathman.org kernel:  []
cfg80211_process_wdev_events+0x8c/0x190 [cfg80211]
Jan 28 22:29:21 melissa.gathman.org kernel:  []
cfg80211_process_rdev_events+0x32/0x70 [cfg80211]
Jan 28 22:29:21 melissa.gathman.org kernel:  []
cfg80211_event_work+0x1e/0x30 [cfg80211]
Jan 28 22:29:21 melissa.gathman.org kernel:  []
process_one_work+0x19e/0x3f0
Jan 28 22:29:21 melissa.gathman.org kernel:  []
worker_thread+0x4e/0x450
Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
process_one_work+0x3f0/0x3f0
Jan 28 22:29:21 melissa.gathman.org kernel:  []
kthread+0xd8/0xf0
Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
kthread_worker_fn+0x160/0x160
Jan 28 22:29:21 melissa.gathman.org kernel:  []
ret_from_fork+0x3f/0x70
Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
kthread_worker_fn+0x160/0x160
Jan 28 22:29:21 melissa.gathman.org kernel: ---[ end trace 04ee7067960ce525 ]---
Jan 28 22:29:21 melissa.gathman.org kernel: batman_adv: bat0: Adding
interface: wlp0s26u1u4

Re: ibss.c backtrace when batman-adv adds wireless interface

2016-02-03 Thread Josh Boyer 
On Wed, Feb 3, 2016 at 10:24 AM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> Hi All,
>
> We've had a user report the backtrace below when loading batman-adv on
> his machine.  It looks like the cfg80211 layer is complaining about a
> null bss returned, but I cannot tell if the rtlwifi driver or
> batman-adv is in error here.
>
> Thoughts?

Sorry, forgot to include the link to the actual bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1304428

Reporter says this is new with 4.3.y and did not happen on e.g. 4.2.8.


josh

>
> Jan 28 22:29:21 melissa.gathman.org kernel: batman_adv: B.A.T.M.A.N.
> advanced 2015.2 (compatibility version 15) loaded
> Jan 28 22:29:21 melissa.gathman.org kernel: wlp0s26u1u4: Selected IBSS
> BSSID 02:1a:a0:3a:a6:ff based on configured SSID
> Jan 28 22:29:21 melissa.gathman.org kernel: [ cut here 
> ]
> Jan 28 22:29:21 melissa.gathman.org kernel: WARNING: CPU: 1 PID: 111
> at net/wireless/ibss.c:35 __cfg80211_ibss_joined+0x166/0x190
> [cfg80211]()
> Jan 28 22:29:21 melissa.gathman.org kernel: Modules linked in:
> batman_adv libcrc32c xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4
> nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter
> ip6t_REJECT nf_reject_ipv6 xt_conntrack tun ebtable_filter ebtable_nat
> ebtable_broute bridge stp llc ebtables ip6table_mangle ip6table_nat
> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw
> ip6table_security ip6table_filter ip6_tables iptable_mangle
> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack iptable_raw iptable_security arc4 rtl8192cu rtl_usb
> rtl8192c_common rtlwifi mac80211 cfg80211 rfkill uvcvideo
> videobuf2_vmalloc videobuf2_core videobuf2_memops v4l2_common
> intel_rapl snd_hda_codec_hdmi snd_usb_audio joydev snd_usbmidi_lib
> snd_hda_codec_realtek iosf_mbi x86_pkg_temp_thermal videodev coretemp
> kvm_intel
> Jan 28 22:29:21 melissa.gathman.org kernel:  media snd_rawmidi cm109
> snd_hda_codec_generic kvm snd_hda_intel iTCO_wdt snd_hda_codec
> iTCO_vendor_support crct10dif_pclmul snd_hda_core ppdev snd_hwdep
> snd_seq snd_seq_device snd_pcm crc32_pclmul crc32c_intel snd_timer snd
> dcdbas lpc_ich mei_me parport_pc parport shpchp i2c_i801 mei tpm_tis
> tpm soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> hid_microsoft i915 i2c_algo_bit drm_kms_helper drm e1000e serio_raw
> ptp pps_core fjes video
> Jan 28 22:29:21 melissa.gathman.org kernel: CPU: 1 PID: 111 Comm:
> kworker/u32:5 Not tainted 4.3.3-301.fc23.x86_64 #1
> Jan 28 22:29:21 melissa.gathman.org kernel: Hardware name: Dell Inc.
> OptiPlex 790/0HY9JP, BIOS A06 07/25/2011
> Jan 28 22:29:21 melissa.gathman.org kernel: Workqueue: cfg80211
> cfg80211_event_work [cfg80211]
> Jan 28 22:29:21 melissa.gathman.org kernel:  
> 8beeeb5f 8800368bfce0 813a626f
> Jan 28 22:29:21 melissa.gathman.org kernel:  
> 8800368bfd18 810a07c2 8800c2bc8850
> Jan 28 22:29:21 melissa.gathman.org kernel:  8800c2bc8000
> 8801275bd558  0286
> Jan 28 22:29:21 melissa.gathman.org kernel: Call Trace:
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> dump_stack+0x44/0x55
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> warn_slowpath_common+0x82/0xc0
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> warn_slowpath_null+0x1a/0x20
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> __cfg80211_ibss_joined+0x166/0x190 [cfg80211]
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> cfg80211_process_wdev_events+0x8c/0x190 [cfg80211]
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> cfg80211_process_rdev_events+0x32/0x70 [cfg80211]
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> cfg80211_event_work+0x1e/0x30 [cfg80211]
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> process_one_work+0x19e/0x3f0
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> worker_thread+0x4e/0x450
> Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
> process_one_work+0x3f0/0x3f0
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> kthread+0xd8/0xf0
> Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
> kthread_worker_fn+0x160/0x160
> Jan 28 22:29:21 melissa.gathman.org kernel:  []
> ret_from_fork+0x3f/0x70
> Jan 28 22:29:21 melissa.gathman.org kernel:  [] ?
> kthread_worker_fn+0x160/0x160
> Jan 28 22:29:21 melissa.gathman.org kernel: ---[ end trace 04ee7067960ce525 
> ]---
> Jan 28 22:29:21 melissa.gathman.org kernel: batman_adv: bat0: Adding
> interface: wlp0s26u1u4

Re: header conflict introduced by change to netfilter_ipv4/ip_tables.h

2016-02-03 Thread Josh Boyer 
On Thu, Jan 7, 2016 at 2:15 PM, Mikko Rapeli  wrote:
> On Thu, Jan 07, 2016 at 10:30:40AM -0800, Stephen Hemminger wrote:
>> On Thu, 7 Jan 2016 07:29:50 +
>> Mikko Rapeli  wrote:
>>
>> > On Wed, Jan 06, 2016 at 09:20:07AM -0800, Stephen Hemminger wrote:
>> > > This commit breaks compilation of iproute2 with net-next.
>> >
>> > Ok, linux/if.h and libc net/if.h have overlapping defines, and this is not
>> > the only one. I saw lots of them in the core dump headers.
>> >
>> > How should we handle them? Another ifndef for IFNAMSIZ into kernel uapi
>> > headers?
>> >
>> > -Mikko
>>
>> Probably need to do the same thing that was done previously for these
>> kind of conflicts.  This makes make linux/if.h change to adapt to net/if.h
>> being included before it.
>
> Ok, got it. And found include/uapi/linux/libc-compat.h. Did not know about it
> and was looking for solutions to these problems.
>
> But now I feel like writing a test script for mixing of kernel uapi
> and libc headers to find out how many other collitions are still there.
> Not good for the pile of over 70 patches in my branch
> https://github.com/torvalds/linux/compare/master...mcfrisk:headers_test_v05
>
>> Or revert your patch.
>
> I'm fine with this too.

This is causing a number of build failures in Fedora rawhide now.  Did
anyone submit a revert or patch to fix this issue?

josh

Re: ibss.c backtrace when batman-adv adds wireless interface

2016-02-03 Thread Josh Boyer 
On Wed, Feb 3, 2016 at 10:41 AM, Johannes Berg
<johan...@sipsolutions.net> wrote:
> On Wed, 2016-02-03 at 10:26 -0500, Josh Boyer wrote:
>> On Wed, Feb 3, 2016 at 10:24 AM, Josh Boyer <jwbo...@fedoraproject.or
>> g> wrote:
>> > Hi All,
>> >
>> > We've had a user report the backtrace below when loading batman-adv
>> > on
>> > his machine.  It looks like the cfg80211 layer is complaining about
>> > a
>> > null bss returned, but I cannot tell if the rtlwifi driver or
>> > batman-adv is in error here.
>> >
>> > Thoughts?
>>
>> Sorry, forgot to include the link to the actual bug report:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1304428
>>
>> Reporter says this is new with 4.3.y and did not happen on e.g.
>> 4.2.8.
>>
>
> AFAICT this should be a driver (or perhaps mac80211) issue, but I don't
> see any information about the driver used.

The backtrace has all the modules loaded included in it.  rtlwifi is
listed there and it's the only wireless driver in use (rtl8192cu
specifically via USB).

josh

Re: [PATCH 00/10] Netfilter fixes for net

2015-11-13 Thread Josh Boyer 
On Wed, Nov 11, 2015 at 12:33 PM, Pablo Neira Ayuso  wrote:
> Jozsef Kadlecsik (3):
>   netfilter: ipset: Fix extension alignment
>   netfilter: ipset: Fix hash:* type expiration
>   netfilter: ipset: Fix hash type expire: release empty hash bucket block

Should these three go to stable?  We've had reports in Fedora about
ipset crashing on e.g. ARM architectures with 4.2.y kernels.  If not
all three, then perhaps just the alignment fix?

josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net 1/2] isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

2015-10-30 Thread Josh Boyer 
On Fri, Oct 16, 2015 at 3:46 AM, David Miller  wrote:
> From: Ben Hutchings 
> Date: Wed, 14 Oct 2015 18:51:14 +0100
>
>> Compile-tested only.
>>
>> Signed-off-by: Ben Hutchings 
>> ---
>>  drivers/isdn/i4l/isdn_ppp.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
>> index c4198fa..86f9abe 100644
>> --- a/drivers/isdn/i4l/isdn_ppp.c
>> +++ b/drivers/isdn/i4l/isdn_ppp.c
>> @@ -301,6 +301,8 @@ isdn_ppp_open(int min, struct file *file)
>>   is->compflags = 0;
>>
>>   is->reset = isdn_ppp_ccp_reset_alloc(is);
>> + if (!is->reset)
>> + return -ENOMEM;
>
> Ben, your email client has corrupted both of these patches.
>
> Please fix this up and resubmit, thanks.

Ben, did you resubmit these as David suggested?  I haven't found a v2 anywhere.

josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Rate limiting AP bandwidth change messages in ieee80211_config_bw?

2015-09-30 Thread Josh Boyer 
On Wed, Sep 30, 2015 at 3:04 PM, Johannes Berg
 wrote:
>
>>
>> I'm not sure ratelimiting it would even work - it's not *that* high
>> frequency? Not really sure though.
>>
>> I think we can do either, it's not such a terribly important message as
>> far as I can tell.
>>
>
> Seems like Emmanuel would like to see the message stay in some form -

For what purpose?  Or rather, when a user sees this in their dmesg,
what are they supposed to do about it?

> perhaps we should try rate limiting it then? Could you check if that
> actually works?

I'll think on it, sure.  I was hoping sdata_dbg would be sufficient
because it's much easier, but if there's value in the message I can
look at limiting it in some fashion.

josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rate limiting AP bandwidth change messages in ieee80211_config_bw?

2015-09-30 Thread Josh Boyer 
Hi Johannes,

We've seen a handful of reports that seem to have verbose output from
the ieee80211_config_bw function in net/mac80211/mlme.c.  It looks
similar to this:

[   66.578652] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   68.522437] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   69.548353] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   70.568677] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   71.489416] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   72.512917] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   73.535866] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   81.777530] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   82.540576] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   94.513467] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   95.634855] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   97.474767] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[   98.498036] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[   99.520472] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[  100.551344] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[  101.571100] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 1 (2437/0 MHz)
[  102.490708] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)

Essentially, this looks like the AP is changing the bandwidth (and
only the width) every second or so.  Why it is doing this, I'm not
sure.  However, this doesn't seem to actually be an error case yet the
kernel logs are getting spammed with this message.

I'm wondering if we could either change this message to use sdata_dbg
instead of sdata_info, or if we could possibly ratelimit it somehow.
I'd be happy to come up with a patch for either, but I wanted to get
your feedback on it before I started.  Do you have any objections or
preference?

josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Bluetooth: Add reset_resume function

2015-06-02 Thread Josh Boyer 
On Mon, Jun 1, 2015 at 9:28 PM, Marcel Holtmann mar...@holtmann.org wrote:
 Hi Laura,

 Bluetooth devices off of some buses such as USB may lose power across
 suspend/resume. When this happens, drivers may need to have the setup
 function called again and behave differently than a cold power on.
 Add a reset_resume function for drivers to call. During the
 reset_resume case, the flag HCI_RESET_RESUME will be set to allow
 drivers to differentate.

 Signed-off-by: Laura Abbott labb...@fedoraproject.org
 ---
 This matches with what hci_reset_dev does and also ensures
 the setup function gets called again.
 ---
 include/net/bluetooth/hci.h  |  1 +
 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_core.c | 16 
 3 files changed, 18 insertions(+)

 diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
 index d95da83..6285410 100644
 --- a/include/net/bluetooth/hci.h
 +++ b/include/net/bluetooth/hci.h
 @@ -185,6 +185,7 @@ enum {
   HCI_RAW,

   HCI_RESET,
 + HCI_RESET_RESUME,
 };

 no more addition to this list of flags please. These are userspace exposed 
 flags and with that ABI that we are never ever touching again. If you need 
 flags on a per device basis, then use the second list.

It would be helpful for other developers if you added a comment to
that effect above the enum definition.  Otherwise you're going to wind
up repeating yourself over time.

Also, if they're exposed to userspace, should this file be using the
uapi mechanism?  I'm confused how they're exposed today, given that
they aren't installed via 'make headers_install'.  Is this manually
synced with some other .h file in a userspace package?

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Suspicious RCU usage in bridge with Linux v4.0-9362-g1fc149933fd4

2015-05-21 Thread Josh Boyer 
On Tue, May 12, 2015 at 2:27 PM, Dominick Grift dac.overr...@gmail.com wrote:
 On Mon, May 11, 2015 at 07:53:06AM -0700, Eric Dumazet wrote:

 Hi Dominick

 Have you tried this patch I sent last monday ?

 I will submit formally when I get a test result.

 Thanks

 Eric,

 I have tested the below patch and everything is in order!

 Thank you!


 diff --git a/net/bridge/br_stp_timer.c b/net/bridge/br_stp_timer.c
 index 
 4fcaa67750fda845ad0a180332c4cd96a9524086..7caf7fae2d5b8aa369b924e1c87a47c343fb8954
  100644
 --- a/net/bridge/br_stp_timer.c
 +++ b/net/bridge/br_stp_timer.c
 @@ -97,7 +97,9 @@ static void br_forward_delay_timer_expired(unsigned long 
 arg)
   netif_carrier_on(br-dev);
   }
   br_log_state(p);
 + rcu_read_lock();
   br_ifinfo_notify(RTM_NEWLINK, p);
 + rcu_read_unlock();
   spin_unlock(br-lock);
  }




I'm still seeing this with Linus' tree as of yesterday.  Is this
queued anywhere for 4.1?

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][v3.19.y] tun: return proper error code from tun_do_read

2015-04-28 Thread Josh Boyer 
On Tue, Apr 28, 2015 at 4:27 PM, Joseph Salisbury
joseph.salisb...@canonical.com wrote:
 Hello,

 Please consider including mainline commit
 957f094f221f81e457133b1f4c4d95ffa49ff731 in the next v3.19.y release.
 It was included in the mainline tree as of v4.0-rc1.  It has been tested
 and confirmed to resolve:
 http://bugs.launchpad.net/bugs/1448942
 And upstream bug report:
 https://bugzilla.kernel.org/show_bug.cgi?id=90901

 The bug was introduce in v3.19-rc1 by commit 9b067034d0, so it is not
 needed in any other stable kernels.



 commit 957f094f221f81e457133b1f4c4d95ffa49ff731
 Author: Alex Gartrell agartr...@fb.com
 Date:   Thu Dec 25 23:22:49 2014 -0800

 tun: return proper error code from tun_do_read

It's already queued for 3.19.6.  I pinged DaveM about it back in March
and it eventually got queued up.

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Suspicious RCU usage in bridge with Linux v4.0-9362-g1fc149933fd4

2015-04-23 Thread Josh Boyer 
Hi All,

We've had a user report the following backtrace from the bridge module
with a recent Linus' tree.  Has anything like this been reported yet?
If you have any questions on setup, the user is CC'd.

josh

[   29.382235] br0: port 1(tap0) entered forwarding state

[   29.382286] ===
[   29.382315] [ INFO: suspicious RCU usage. ]
[   29.382344] 4.1.0-0.rc0.git11.1.fc23.x86_64 #1 Not tainted
[   29.382380] ---
[   29.382409] net/bridge/br_private.h:626 suspicious
rcu_dereference_check() usage!
[   29.382455]
   other info that might help us debug this:

[   29.382507]
   rcu_scheduler_active = 1, debug_locks = 0
[   29.382549] 2 locks held by swapper/0/0:
[   29.382576]  #0:  (((p-forward_delay_timer))){+.-...}, at:
[81139f75] call_timer_fn+0x5/0x4f0
[   29.382660]  #1:  ((br-lock)-rlock){+.-...}, at:
[a0450dc1] br_forward_delay_timer_expired+0x31/0x140
[bridge]
[   29.382754]
   stack backtrace:
[   29.382787] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-0.rc0.git11.1.fc23.x86_64 #1
[   29.382838] Hardware name: LENOVO 422916G/LENOVO, BIOS A1KT53AUS 04/07/2015
[   29.382882]   3ebfc20364115825 88003c48
81892d4b
[   29.382943]   81e124e0 88003c78
8110bcd7
[   29.383004]  8800785c9d00 88065485ac58 880c62002800
880c5fc88ac0
[   29.383065] Call Trace:
[   29.383084]  IRQ  [81892d4b] dump_stack+0x4c/0x65
[   29.383130]  [8110bcd7] lockdep_rcu_suspicious+0xe7/0x120
[   29.383178]  [a04520f9] br_fill_ifinfo+0x4a9/0x6a0 [bridge]
[   29.383225]  [a045266b] br_ifinfo_notify+0x11b/0x4b0 [bridge]
[   29.383271]  [a0450d90] ? br_hold_timer_expired+0x70/0x70 [bridge]
[   29.383320]  [a0450de8]
br_forward_delay_timer_expired+0x58/0x140 [bridge]
[   29.383371]  [a0450d90] ? br_hold_timer_expired+0x70/0x70 [bridge]
[   29.383416]  [8113a033] call_timer_fn+0xc3/0x4f0
[   29.383454]  [81139f75] ? call_timer_fn+0x5/0x4f0
[   29.383493]  [8110a90f] ? lock_release_holdtime.part.29+0xf/0x200
[   29.383541]  [a0450d90] ? br_hold_timer_expired+0x70/0x70 [bridge]
[   29.383587]  [8113a6a4] run_timer_softirq+0x244/0x490
[   29.383629]  [810b68cc] __do_softirq+0xec/0x670
[   29.383666]  [810b70d5] irq_exit+0x145/0x150
[   29.383703]  [8189f506] smp_apic_timer_interrupt+0x46/0x60
[   29.383744]  [8189d523] apic_timer_interrupt+0x73/0x80
[   29.383782]  EOI  [816f131f] ? cpuidle_enter_state+0x5f/0x2f0
[   29.383832]  [816f131b] ? cpuidle_enter_state+0x5b/0x2f0
[   29.383873]  [816f15e7] cpuidle_enter+0x17/0x20
[   29.383908]  [81103c6f] cpu_startup_entry+0x36f/0x5f0
[   29.383949]  [81887cbd] rest_init+0x13d/0x150
[   29.383986]  [821c905b] start_kernel+0x4d2/0x4f3
[   29.384023]  [821c8120] ? early_idt_handlers+0x120/0x120
[   29.384064]  [821c8339] x86_64_start_reservations+0x2a/0x2c
[   29.384105]  [821c8485] x86_64_start_kernel+0x14a/0x16d
[   36.100347] IN=br0 OUT=
MAC=33:33:00:00:00:02:52:54:00:12:01:00:86:dd
SRC=fe80::::5054:00ff:fe12:0100
DST=ff02:::::::0002 LEN=56 TC=0 HOPLIMIT=255
FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0
[   40.113744] IN=br0 OUT=
MAC=33:33:00:00:00:02:52:54:00:12:01:00:86:dd
SRC=fe80::::5054:00ff:fe12:0100
DST=ff02:::::::0002 LEN=56 TC=0 HOPLIMIT=255
FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0
[   44.119727] IN=br0 OUT=
MAC=33:33:00:00:00:02:52:54:00:12:01:00:86:dd
SRC=fe80::::5054:00ff:fe12:0100
DST=ff02:::::::0002 LEN=56 TC=0 HOPLIMIT=255
FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove rgmii-interface from rgmii matching table

2008-02-06 Thread Josh Boyer 
On Wed,  6 Feb 2008 13:21:59 +0100
Stefan Roese [EMAIL PROTECTED] wrote:

 With the removal the the rgmii-interface device_type property from the
 dts files, the newemac driver needs an update to only rely on compatible
 property.
 
 Signed-off-by: Stefan Roese [EMAIL PROTECTED]
 Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

Acked-by: Josh Boyer [EMAIL PROTECTED]

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove rgmii-interface from rgmii matching table

2008-02-06 Thread Josh Boyer 
On Wed, 6 Feb 2008 10:01:57 -0600
Olof Johansson [EMAIL PROTECTED] wrote:

 On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
  With the removal the the rgmii-interface device_type property from the
  dts files, the newemac driver needs an update to only rely on compatible
  property.
 
 What about systems using an older dts, such as one kexec:ing from an
 older kernel?

Like what?  Kexec doesn't work on 4xx yet.

 Just because the device tree source is distributed in the kernel tree
 doesn't mean it can give up backwards compatibility.

We checked Axon, which is the only non-DTS machine that uses EMAC and
it will work fine with this change.

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove rgmii-interface from rgmii matching table

2008-02-05 Thread Josh Boyer 
On Thu, 31 Jan 2008 10:14:58 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
  On Wednesday 16 January 2008, Josh Boyer wrote:
   On Wed, 16 Jan 2008 20:53:59 +1100
  
   Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
 With the removal the the rgmii-interface device_type property from
 the dts files, the newemac driver needs an update to only rely on
 compatible property.

 Signed-off-by: Stefan Roese [EMAIL PROTECTED]
   
I need to test if it works on CAB, can't change the DT on those. I'll
let you know tomorrow.
  
   This should be fine on CAB.  The rgmii node has:
  
   compatible = ibm,rgmii-axon, ibm,rgmii
  
   so the match should still catch on the latter.
  
  How about this patch? Ben, if you think this is ok then we should make sure 
  that it goes in in this merge-window, since the other dts patch relies on 
  it.
 
 It's fine.

Jeff, any chance this can get into .25 soon?  I have another patch
queued up behind this one that requires it, and I don't see it in any
of your trees or branches.

Or, if you aren't opposed, I can take it through Paul's tree with your
Ack.

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove rgmii-interface from rgmii matching table

2008-01-16 Thread Josh Boyer 
On Wed, 16 Jan 2008 20:53:59 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
  With the removal the the rgmii-interface device_type property from the
  dts files, the newemac driver needs an update to only rely on compatible
  property.
  
  Signed-off-by: Stefan Roese [EMAIL PROTECTED]
 
 I need to test if it works on CAB, can't change the DT on those. I'll
 let you know tomorrow.

This should be fine on CAB.  The rgmii node has:

compatible = ibm,rgmii-axon, ibm,rgmii

so the match should still catch on the latter.

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers

2008-01-05 Thread Josh Boyer 
On Sun, 06 Jan 2008 07:53:06 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Sat, 2008-01-05 at 13:38 +0100, Stefan Roese wrote:
  On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
   On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
Performance tests done by AMCC have shown that 256 buffer increase the
performance of the Linux EMAC driver. So let's update the default
values to match this setup.
   
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
  
   Do we have the numbers ? Did they also measure latency ?
  
  I hoped this question would not come. ;) No, unfortunately I don't have any 
  numbers. Just the recommendation from AMCC to always use 256 buffers.
 
 Ok. Well, it's just a .config option so I suppose the patch is fine. Can
 you also update the defconfigs (at least for the recent AMCC boards) ?

No need for a defconfig update patch.  Paul or I usually do a general
defconfig update for most boards before the next kernel version.  This
will get picked up then.

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers

2008-01-05 Thread Josh Boyer 
On Sun, 06 Jan 2008 08:54:28 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Sat, 2008-01-05 at 15:48 -0600, Josh Boyer wrote:
  No need for a defconfig update patch.  Paul or I usually do a general
  defconfig update for most boards before the next kernel version.  This
  will get picked up then.
 
 Will it ? I think the defconfigs will stick to the old value.

Put another way, if Kconfig doesn't update it automagically, I'll be
sure to do it myself. :)

josh
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close

2007-11-21 Thread Josh Boyer 
On Wed, 21 Nov 2007 16:41:23 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:

 On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
  It's a bad idea to call flush_scheduled_work from within a
  netdev-stop because the linkwatch will occasionally take the
  rtnl lock from a workqueue context, and thus that can deadlock.
  
  This reworks things a bit in that area to avoid the problem.
 
 So from the name of the driver you want to keep the previous emac
 driver around.  Is there a good reason for that?

It's being kept around until arch/ppc dies.  Then things should get
renamed.

josh
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add 405EX support to new EMAC driver

2007-11-01 Thread Josh Boyer 
On Fri, 02 Nov 2007 07:37:01 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Thu, 2007-11-01 at 15:54 +0100, Stefan Roese wrote:
  This patch adds support for the 405EX to the new EMAC driver.
  
  Tested on AMCC Kilauea.
 
  .../...
 
  diff --git a/drivers/net/ibm_newemac/rgmii.c 
  b/drivers/net/ibm_newemac/rgmii.c
  index de41695..e393f68 100644
  --- a/drivers/net/ibm_newemac/rgmii.c
  +++ b/drivers/net/ibm_newemac/rgmii.c
  @@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
   
  RGMII_DBG2(dev, get_mdio(%d) NL, input);
   
  -   if (dev-type != RGMII_AXON)
  -   return;
  -
  mutex_lock(dev-lock);
 
 That will break 440GX boards that need to use the RGMII for data and the
 ZMII for MDIO.
 
 You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
 instead and set that for 405EX as well instead.

And perhaps adding a comment about that since the meaning of that code
isn't very obvious. That way people that aren't the original author
of the driver don't get confused again.

josh
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Remove pointless casts from void pointers,

2007-10-26 Thread Josh Boyer 
On Fri, 26 Oct 2007 05:40:22 -0400 (EDT)
Jeff Garzik [EMAIL PROTECTED] wrote:

 mostly in and around irq handlers.
 
 Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
 ---

  drivers/serial/uartlite.c  |2 +-

Acked-by: Josh Boyer [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.

2007-10-23 Thread Josh Boyer 
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 Valentine Barshak wrote:
  This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
  These PHY chips are used on PowerPC 440EPx boards.
  The PHY code is based on the previous work by Stefan Roese [EMAIL 
  PROTECTED]
  
  Signed-off-by: Stefan Roese [EMAIL PROTECTED]
  Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
  ---
   drivers/net/ibm_newemac/phy.c |   39 
  +++
   1 files changed, 39 insertions(+)
  
  --- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15 
  21:45:18.0 +0400
  +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0 
  +0400
  @@ -306,8 +306,47 @@
  .ops= cis8201_phy_ops
   };
   
  +static struct mii_phy_def bcm5248_phy_def = {
  +
  +   .phy_id = 0x0143bc00,
  +   .phy_id_mask= 0x0ff0,
  +   .name   = BCM5248 10/100 SMII Ethernet,
  +   .ops= generic_phy_ops
  +};
  +
  +static int m88e_init(struct mii_phy *phy)
  +{
  +   printk(%s: Marvell 88E Ethernet\n, __FUNCTION__);
  +   phy_write(phy, 0x14, 0x0ce3);
  +   phy_write(phy, 0x18, 0x4101);
  +   phy_write(phy, 0x09, 0x0e00);
  +   phy_write(phy, 0x04, 0x01e1);
  +   phy_write(phy, 0x00, 0x9140);
  +   phy_write(phy, 0x00, 0x1140);
  +
  +   return  0;
  +}
  +
  +static struct mii_phy_ops m88e_phy_ops = {
  +   .init   = m88e_init,
  +   .setup_aneg = genmii_setup_aneg,
  +   .setup_forced   = genmii_setup_forced,
  +   .poll_link  = genmii_poll_link,
  +   .read_link  = genmii_read_link
  +};
  +
  +static struct mii_phy_def m88e_phy_def = {
  +
  +   .phy_id = 0x01410CC0,
  +   .phy_id_mask= 0x0ff0,
  +   .name   = Marvell 88E Ethernet,
  +   .ops= m88e_phy_ops,
  +};
  +
   static struct mii_phy_def *mii_phy_table[] = {
  cis8201_phy_def,
  +   bcm5248_phy_def,
  +   m88e_phy_def,
  genmii_phy_def,
 
 Seems sane to me -- ACK -- but we have multiple people sending me 
 patches for a single driver.  That's normal for janitorial cleanups 
 across the whole tree, but discouraged when multiple people are actively 
 working on the same driver.
 
 Please coordinate, and have ONE person send me patches...

Jeff, could you please pull in this patch for 2.6.24?  We'll get the
coordination down for any further patches.

thx,
josh
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.

2007-10-23 Thread Josh Boyer 
On Tue, 23 Oct 2007 11:13:48 -0500
Kumar Gala [EMAIL PROTECTED] wrote:

 
 On Oct 23, 2007, at 10:20 AM, Josh Boyer wrote:
 
  On Mon, 15 Oct 2007 14:27:23 -0400
  Jeff Garzik [EMAIL PROTECTED] wrote:
 
  Valentine Barshak wrote:
  This patch adds BCM5248 and Marvell 88E PHY support to NEW  
  EMAC driver.
  These PHY chips are used on PowerPC 440EPx boards.
  The PHY code is based on the previous work by Stefan Roese  
  [EMAIL PROTECTED]
 
  Signed-off-by: Stefan Roese [EMAIL PROTECTED]
  Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
  ---
 
 You guys should really look at moving emac over to the phylib so we  
 don't have to duplicate drivers for the same phys all over the place :)

Yes, we should.  It's on the list.  Just not for 2.6.24 since it's way
too late.

josh
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll

2007-10-17 Thread Josh Boyer 
On Thu, 2007-10-18 at 08:04 +1000, Benjamin Herrenschmidt wrote:
 net: Add __napi_synchronize() to sync with napi poll
 
 The EMAC driver which needs to handle multiple devices with one
 NAPI instance implements its own per-channel disable bit. However,
 when setting such a bit, it needs to synchronize with the poller
 (that is make sure that any pending poller instance has completed,
 or is started late enough to see that disable bit).
 
 This implements a low level __napi_synchronize() function to acheive
 that. The underscores are to emphasis the low level aspect of it and
 to discourage driver writers who don't know what they are doing to
 use it (to please DaveM :-)

Erm.. your commit log calls it __napi_synchronize still.

josh

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll

2007-10-17 Thread Josh Boyer 
On Thu, 2007-10-18 at 08:04 +1000, Benjamin Herrenschmidt wrote:
 net: Add __napi_synchronize() to sync with napi poll
 
 The EMAC driver which needs to handle multiple devices with one
 NAPI instance implements its own per-channel disable bit. However,
 when setting such a bit, it needs to synchronize with the poller
 (that is make sure that any pending poller instance has completed,
 or is started late enough to see that disable bit).
 
 This implements a low level __napi_synchronize() function to acheive
 that. The underscores are to emphasis the low level aspect of it and
 to discourage driver writers who don't know what they are doing to
 use it (to please DaveM :-)
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

Ok, trying again, leaving the actual patch below.  In the above patch
description, you still call it __napi_synchronize.  In the patch below,
it's napi_syncronize.

I was just trying to point out to whomever commits this patch that the
actual description should probably be fixed.

 ---
 
 Back to msleep() since it fits my need well and that's what
 you used as well. Note that the smp_mb() will turn into barrier()
 on non-SMP.
 
 I'll send a separate patch to fix EMAC to use the non __ version.
 
 Index: linux-work/include/linux/netdevice.h
 ===
 --- linux-work.orig/include/linux/netdevice.h 2007-10-17 13:31:32.0 
 +1000
 +++ linux-work/include/linux/netdevice.h  2007-10-18 08:01:05.0 
 +1000
 @@ -394,6 +394,23 @@ static inline void napi_disable(struct n
  }
 
  /**
 + *   napi_synchronize - synchronize with a concurrent poll
 + *   @n: napi context
 + *
 + * Synchronizes with a concurrent poll. Not to be used in normal
 + * drivers, mostly useful if you end up with multiple interfaces
 + * on one NAPI instance. This must be called from task context.
 + */
 +static inline void napi_synchronize(struct napi_struct *n)
 +{
 + smp_mb();
 +#ifdef CONFIG_SMP
 + while (test_bit(NAPI_STATE_SCHED, n-state))
 + msleep(1);
 +#endif /* CONFIG_SMP */
 +}
 +
 +/**
   *   napi_enable - enable NAPI scheduling
   *   @n: napi context
   *
 
 
 ___
 Linuxppc-dev mailing list
 [EMAIL PROTECTED]
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.

2007-10-15 Thread Josh Boyer 
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 Valentine Barshak wrote:
  This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
  These PHY chips are used on PowerPC 440EPx boards.
  The PHY code is based on the previous work by Stefan Roese [EMAIL 
  PROTECTED]
  
  Signed-off-by: Stefan Roese [EMAIL PROTECTED]
  Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
  ---
   drivers/net/ibm_newemac/phy.c |   39 
  +++
   1 files changed, 39 insertions(+)
  
  --- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15 
  21:45:18.0 +0400
  +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0 
  +0400
  @@ -306,8 +306,47 @@
  .ops= cis8201_phy_ops
   };
   
  +static struct mii_phy_def bcm5248_phy_def = {
  +
  +   .phy_id = 0x0143bc00,
  +   .phy_id_mask= 0x0ff0,
  +   .name   = BCM5248 10/100 SMII Ethernet,
  +   .ops= generic_phy_ops
  +};
  +
  +static int m88e_init(struct mii_phy *phy)
  +{
  +   printk(%s: Marvell 88E Ethernet\n, __FUNCTION__);
  +   phy_write(phy, 0x14, 0x0ce3);
  +   phy_write(phy, 0x18, 0x4101);
  +   phy_write(phy, 0x09, 0x0e00);
  +   phy_write(phy, 0x04, 0x01e1);
  +   phy_write(phy, 0x00, 0x9140);
  +   phy_write(phy, 0x00, 0x1140);
  +
  +   return  0;
  +}
  +
  +static struct mii_phy_ops m88e_phy_ops = {
  +   .init   = m88e_init,
  +   .setup_aneg = genmii_setup_aneg,
  +   .setup_forced   = genmii_setup_forced,
  +   .poll_link  = genmii_poll_link,
  +   .read_link  = genmii_read_link
  +};
  +
  +static struct mii_phy_def m88e_phy_def = {
  +
  +   .phy_id = 0x01410CC0,
  +   .phy_id_mask= 0x0ff0,
  +   .name   = Marvell 88E Ethernet,
  +   .ops= m88e_phy_ops,
  +};
  +
   static struct mii_phy_def *mii_phy_table[] = {
  cis8201_phy_def,
  +   bcm5248_phy_def,
  +   m88e_phy_def,
  genmii_phy_def,
 
 Seems sane to me -- ACK -- but we have multiple people sending me 
 patches for a single driver.  That's normal for janitorial cleanups 
 across the whole tree, but discouraged when multiple people are actively 
 working on the same driver.
 
 Please coordinate, and have ONE person send me patches...

Who else is sending you patches?  Valentine is the only one I've seen
send patches recently...

josh
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.

2007-10-15 Thread Josh Boyer 
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
  Seems sane to me -- ACK -- but we have multiple people sending me 
  patches for a single driver.  That's normal for janitorial cleanups 
  across the whole tree, but discouraged when multiple people are actively 
  working on the same driver.
 
  Please coordinate, and have ONE person send me patches...
  
  Who else is sending you patches?  Valentine is the only one I've seen
  send patches recently...
 
 It's a zoo :)

Wow, indeed.

 Al Viro (3):
typo in ibm_newemac/rgmii.c

Val sent this as well.  Either one works.

skb-tail in ibm_newemac should be skb_tail_pointer()
ibm_newemac annotations (iomem, NULL noise)

Ack on those.

 David Gibson (1):
Device tree aware EMAC driver

That's the initial commit :)

 Michael Ellerman (3):
Update ibm_newemac to use dcr_host_t.base
Add dcr_host_t.base in dcr_read()/dcr_write()
Use dcr_host_t.base in dcr_unmap()

Missed those, but I see you applied them which is good.

 Roland Dreier (2):
ibm_new_emac: Nuke SET_MODULE_OWNER() use
ibm_emac: Convert to use napi_struct independent of struct net_device

I never saw either of these.  I'm also beginning to wonder if one of
them broke things because I can't currently get ibm_newemac to work.

 [EMAIL PROTECTED] (1):
Fix typo in new EMAC driver.

Same fix as Al's.

Anyway, we can queue patches to this through me if you'd like.

josh
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.

2007-10-15 Thread Josh Boyer 
On Tue, 2007-10-16 at 07:05 +1000, Benjamin Herrenschmidt wrote:
 On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
  I would ideally like a single active patch generator (even if they
  are 
  merely reviewed others work sometimes).
  
  Outside of that, I'm hoping you and the other people listed making 
  changes will self-organize without my help :)
 
 Josh, do you want to be the central point / maintainer for it or do you
 want me to do it ? There's a lot of code from me in there and I did this
 fork in the first place so I have a pretty good idea of what's going on
 in this driver and what still needs to be done :-)

As always, you're welcome to it.  You probably don't want to own it long
term, but I'd appreciate the help for the time being.

josh

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] NEW EMAC Fix RGMII build error: use of_device_is_compatible

2007-10-12 Thread Josh Boyer 
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
 Fix build RGMII error: use of_device_is_compatible()
 insteadof now deprecated device_is_compatible() function.
 
 Signed-off-by: Valentine Barshak [EMAIL PROTECTED]

Acked-by: Josh Boyer [EMAIL PROTECTED]

Jeff, this should go into 2.6.24 please.

josh
 ---
  drivers/net/ibm_newemac/rgmii.c |2 +-
  1 files changed, 1 insertion(+), 1 deletion(-)
 
 diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c 
 linux-2.6/drivers/net/ibm_newemac/rgmii.c
 --- linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c2007-10-12 
 16:02:41.0 +0400
 +++ linux-2.6/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:49:07.0 
 +0400
 @@ -251,7 +251,7 @@ static int __devinit rgmii_probe(struct 
   }
 
   /* Check for RGMII type */
 - if (device_is_compatible(ofdev-node, ibm,rgmii-axon))
 + if (of_device_is_compatible(ofdev-node, ibm,rgmii-axon))
   dev-type = RGMII_AXON;
   else
   dev-type = RGMII_STANDARD;
 ___
 Linuxppc-dev mailing list
 [EMAIL PROTECTED]
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y

2007-07-18 Thread Josh Boyer 
On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
 On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
  On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote:
  
   http://bugzilla.kernel.org/show_bug.cgi?id=8778
   
  Summary: Ocotea board: kernel reports access of bad area during
   boot with DEBUG_SLAB=y
 
 Slab debugging is probably the culprit here. I had similar problem 
 couple of years ago, not sure something has changed since then, 
 haven't checked.
 
 When slab debugging was enabled it made memory allocations non L1 
 cache line aligned. This is very bad for DMA on non-coherent cache 
 arches (PPC440 is one of those archs).
 
 I have a hack for EMAC which tries to workaround this problem:
   http://kernel.ebshome.net/emac_slab_debug.diff
 which might help.

Would you be opposed to including that patch in mainline?  I'd like to
have the bug reporter try it and then get it in if it fixes the issue.

josh

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y

2007-07-18 Thread Josh Boyer 
On Wed, 2007-07-18 at 08:59 -0700, Eugene Surovegin wrote:
 On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
  On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
   On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=8778
 
Summary: Ocotea board: kernel reports access of bad area 
 during
 boot with DEBUG_SLAB=y
   
   Slab debugging is probably the culprit here. I had similar problem 
   couple of years ago, not sure something has changed since then, 
   haven't checked.
   
   When slab debugging was enabled it made memory allocations non L1 
   cache line aligned. This is very bad for DMA on non-coherent cache 
   arches (PPC440 is one of those archs).
   
   I have a hack for EMAC which tries to workaround this problem:
 http://kernel.ebshome.net/emac_slab_debug.diff
   which might help.
  
  Would you be opposed to including that patch in mainline?
 
 Yes. I don't think it's the right way to fix this issue. IMO, the 
 right one is to fix slab allocator. You cannot change all drivers to 
 do this kind of cache flushing, and yes, I saw the same problem with 
 PCI based NIC I tried on Ocotea at the time.

Hm... good point.  I'd still like to see if your patch works around the
reporter's problem.

josh

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html