Re: [BUG]: WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x24d/0x260

2021-04-13 Thread Xose Vazquez Perez 



On 4/13/21 11:07 PM, Heiner Kallweit wrote:


On 13.04.2021 22:59, Xose Vazquez Perez wrote:

A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).

Thanks.


0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

[    2.968280] libphy: r8169: probed
[    2.968844] r8169 :0c:00.0 eth0: RTL8168e/8111e, 2c:41:38:9e:98:93, XID 
2c2, IRQ 47
[    2.968849] r8169 :0c:00.0 eth0: jumbo features [frames: 9194 bytes, tx 
checksumming: ko]
[    4.071966] RTL8211DN Gigabit Ethernet r8169-c00:00: attached PHY driver 
(mii_bus:phy_addr=r8169-c00:00, irq=IGNORE)
[    4.323834] r8169 :0c:00.0 eth0: Link is Down
[    6.729111] r8169 :0c:00.0 eth0: Link is Up - 1Gbps/Full - flow control 
rx/tx

[106378.638739] [ cut here ]
[106378.638757] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out


This is a standard tx timeout and can have very different reasons.
Few questions:

- Is this a regression? If yes, can you bisect?
- Can you reproduce it? If yes, which type of activity triggers it?


This is the first and only time I've seen a bug in r8169 on this machine in 
nine years.
Nothing special, web browsing, git cloning, dnf updating, ...
It's a non-recurring bug.

Now it's running 5.11.13-300.fc34.x86_64, stable as always.


Thank you.

[BUG]: WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x24d/0x260

2021-04-13 Thread Xose Vazquez Perez 

A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).

Thanks.


0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

[2.968280] libphy: r8169: probed
[2.968844] r8169 :0c:00.0 eth0: RTL8168e/8111e, 2c:41:38:9e:98:93, XID 
2c2, IRQ 47
[2.968849] r8169 :0c:00.0 eth0: jumbo features [frames: 9194 bytes, tx 
checksumming: ko]
[4.071966] RTL8211DN Gigabit Ethernet r8169-c00:00: attached PHY driver 
(mii_bus:phy_addr=r8169-c00:00, irq=IGNORE)
[4.323834] r8169 :0c:00.0 eth0: Link is Down
[6.729111] r8169 :0c:00.0 eth0: Link is Up - 1Gbps/Full - flow control 
rx/tx

[106378.638739] [ cut here ]
[106378.638757] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[106378.638783] WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:442 
dev_watchdog+0x24d/0x260
[106378.638796] Modules linked in: snd_hrtimer mei_hdcp pktcdvd snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel ath9k snd_intel_dspcfg soundwire_intel 
soundwire_generic_allocation ath9k_common snd_soc_core ath9k_hw snd_compress intel_rapl_msr iTCO_wdt snd_pcm_dmaengine i915 intel_rapl_common intel_pmc_bxt soundwire_cadence iTCO_vendor_support at24 
mac80211 snd_hda_codec snd_seq_dummy snd_seq_oss x86_pkg_temp_thermal intel_powerclamp snd_hda_core snd_seq_midi_event coretemp ac97_bus snd_pcm_oss ath snd_hwdep rapl hid_logitech_hidpp ses 
intel_cstate video snd_seq i2c_i801 enclosure intel_uncore i2c_smbus i2c_algo_bit snd_seq_device cfg80211 scsi_transport_sas drm_kms_helper snd_pcm r8169 mei_me rfkill libarc4 lpc_ich mei cec 
snd_timer snd_mixer_oss snd soundcore drm binfmt_misc fuse ip_tables hid_logitech_dj crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel uas usb_storage serio_raw

[106378.638958] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW 
5.11.12-300.fc34.x86_64 #1
[106378.638964] Hardware name: Hewlett-Packard p6-2004es/2ABF, BIOS 7.16 
03/23/2012
[106378.638967] RIP: 0010:dev_watchdog+0x24d/0x260
[106378.638974] Code: d9 a2 fd ff eb a9 4c 89 f7 c6 05 2a 46 30 01 01 e8 68 87 fa ff 44 89 e9 4c 89 f6 48 c7 c7 40 77 48 93 48 89 c2 e8 82 26 16 00 <0f> 0b eb 8a 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 
40 00 66 66 66

[106378.638979] RSP: 0018:b6dd801acec0 EFLAGS: 00010282
[106378.638984] RAX: 0039 RBX: 8d1945108a00 RCX: 

[106378.638987] RDX: 8d1a77566ba0 RSI: 8d1a77558ac0 RDI: 
0300
[106378.638991] RBP: 8d19436f43dc R08:  R09: 
b6dd801accf0
[106378.638994] R10: b6dd801acce8 R11: 93b44f08 R12: 
8d19436f4480
[106378.638998] R13:  R14: 8d19436f4000 R15: 
8d1945108a80
[106378.639001] FS:  () GS:8d1a7754() 
knlGS:
[106378.639005] CS:  0010 DS:  ES:  CR0: 80050033
[106378.639009] CR2: 7f160ef2d000 CR3: 48a10005 CR4: 
000606e0
[106378.639013] Call Trace:
[106378.639017]  
[106378.639022]  ? pfifo_fast_enqueue+0x150/0x150
[106378.639029]  call_timer_fn+0x29/0xf0
[106378.639036]  __run_timers.part.0+0x1b1/0x210
[106378.639042]  ? ktime_get+0x38/0x90
[106378.639049]  ? lapic_next_deadline+0x28/0x30
[106378.639055]  ? clockevents_program_event+0x95/0xf0
[106378.639062]  ? sched_clock+0x5/0x10
[106378.639069]  run_timer_softirq+0x26/0x50
[106378.639074]  __do_softirq+0xd0/0x28f
[106378.639081]  asm_call_irq_on_stack+0xf/0x20
[106378.639087]  
[106378.639090]  do_softirq_own_stack+0x37/0x40
[106378.639094]  __irq_exit_rcu+0xbf/0x100
[106378.639099]  sysvec_apic_timer_interrupt+0x36/0x80
[106378.639108]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[106378.639113] RIP: 0010:cpuidle_enter_state+0xc4/0x350
[106378.639120] Code: 7c ff 65 8b 3d 7d 3c 6c 6d e8 28 45 7c ff 49 89 c5 66 66 66 66 90 31 ff e8 59 5d 7c ff 45 84 ff 0f 85 fa 00 00 00 fb 66 66 90 <66> 66 90 45 85 f6 0f 88 06 01 00 00 49 63 d6 4c 2b 
2c 24 48 8d 04

[106378.639124] RSP: 0018:b6dd800b7eb0 EFLAGS: 0246
[106378.639129] RAX: 8d1a7756a000 RBX: 0004 RCX: 
001f
[106378.639133] RDX:  RSI: 25bb8b00 RDI: 

[106378.639136] RBP: 8d1a77575200 R08: 60c034f92547 R09: 
0018
[106378.639139] R10: afc8 R11: 8692 R12: 
93c56dc0
[106378.639142] R13: 60c034f92547 R14: 0004 R15: 

[106378.639148]  cpuidle_enter+0x29/0x40
[106378.639154]  do_idle+0x1c7/0x270
[106378.639160]  cpu_startup_entry+0x19/0x20
[106378.639164]  secondary_startup_64_no_verify+0xc2/0xcb
[106378.639173] ---[ end trace f4c1ff4fd6738c3a ]---

Re: [dm-devel] [PATCH v4 0/2] Historical Service Time Path Selector

2020-05-20 Thread Xose Vazquez Perez 

On 5/11/20 6:39 PM, Gabriel Krisman Bertazi wrote:


This fourth version of HST applies the suggestion from Mikulas Patocka
to do the ktime_get_ns inside the mpath map_bio instead of generic
device-mapper code. This means that struct dm_mpath_io gained another
64bit field.  For the request-based case, we continue to use the block
layer start time information.


You should add some info to the multipath.conf.5 man page ( 
https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=multipath/multipath.conf.5;h=05a5e8ffeb110d969f3b2381eb3b88d7f28380f6;hb=HEAD#l189 ),

or none one is going to use it.


Thanks.

Re: [PATCH] x86/mm: Prevent bogus warnings with "noexec=off"

2019-04-15 Thread Xose Vazquez Perez 
On 4/15/19 10:46 AM, Thomas Gleixner wrote:

> Xose reported warnings when NX is disabled on the kernel command line.

Thank you for doing the dirty work.

> 
> __early_set_fixmap() triggers:
> 
>   attempted to set unsupported pgprot:8163
>  bits:  8000
>  supported: 7fff
> 
>   WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgtable.h:537
>   __early_set_fixmap+0xa2/0xff
> 
> because it uses __default_kernel_pte_mask to mask out unsupported bits.
> 
> Use __supported_pte_mask instead.
> 
> Disabling NX on the command line also triggers the NX warning in the page
> table mapping check:
> 
>   WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:262 
> note_page+0x2ae/0x650
>   
> 
> Make the warning depend on NX set in __supported_pte_mask.
> 
> Reported-by: Xose Vazquez Perez 

And
Tested-by: Xose Vazquez Perez 

> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/mm/dump_pagetables.c |3 ++-
>  arch/x86/mm/ioremap.c |2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> --- a/arch/x86/mm/dump_pagetables.c
> +++ b/arch/x86/mm/dump_pagetables.c
> @@ -259,7 +259,8 @@ static void note_wx(struct pg_state *st)
>  #endif
>   /* Account the WX pages */
>   st->wx_pages += npages;
> - WARN_ONCE(1, "x86/mm: Found insecure W+X mapping at address %pS\n",
> + WARN_ONCE(__supported_pte_mask & _PAGE_NX,
> +   "x86/mm: Found insecure W+X mapping at address %pS\n",
> (void *)st->start_address);
>  }
>  
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -825,7 +825,7 @@ void __init __early_set_fixmap(enum fixe
>   pte = early_ioremap_pte(addr);
>  
>   /* Sanitize 'prot' against any unsupported bits: */
> - pgprot_val(flags) &= __default_kernel_pte_mask;
> + pgprot_val(flags) &= __supported_pte_mask;
>  
>   if (pgprot_val(flags))
>   set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
>

Re: bug disabling NX (noexec=off)

2019-04-14 Thread Xose Vazquez Perez 
On 4/14/19 11:59 AM, Thomas Gleixner wrote:
> On Sat, 13 Apr 2019, Xose Vazquez Perez wrote:
>> [0.00] NX (Execute Disable) protection: disabled by kernel command 
>> line option
>> [0.00] [ cut here ]
>> [0.00] attempted to set unsupported pgprot: 8163 bits: 
>> 8000 supported: 7fff
> 
> Does the below patch fix it for you?
> 
> Thanks,
> 
>   tglx
> 
> 8<
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 0029604af8a4..dd73d5d74393 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -825,7 +825,7 @@ void __init __early_set_fixmap(enum fixed_addresses idx,
>   pte = early_ioremap_pte(addr);
>  
>   /* Sanitize 'prot' against any unsupported bits: */
> - pgprot_val(flags) &= __default_kernel_pte_mask;
> + pgprot_val(flags) &= __supported_pte_mask;
>  
>   if (pgprot_val(flags))
>   set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
> 

Yes, it fixed it.


But there is another bug that I did not see before, but it was there:

---cut dmesg---
Freeing unused kernel image memory: 76K
[ cut here ]
x86/mm: Found insecure W+X mapping at address 0x9df5
WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:262 
note_page+0x2ae/0x650
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.0.7-300.fc30.x86_64 #1
Hardware name: Hewlett-Packard p6-2004es/2ABF, BIOS 7.16 03/23/2012
RIP: 0010:note_page+0x2ae/0x650
Code: 29 f0 48 c1 e8 0c 48 01 43 40 80 3d 54 15 2c 01 00 0f 85 07 ff ff ff 48 
c7 c7 a0 d9 0a b7 c6 05 40 15 2c 01 01 e8 41 2d 06 00 <0f> 0b 4c 8b 4b 20 e9 e9 
fe ff ff 48 29 d6 84 c9 0f 85 71 09 00 00
RSP: 0018:b35940c63e18 EFLAGS: 00010286
RAX:  RBX: b35940c63ec8 RCX: 0050
RDX: 0001 RSI: 0092 RDI: 0247
RBP: 0161 R08: 0001 R09: 02ca
R10: e844 R11: 0003 R12: 
R13: 0005 R14:  R15: 
FS:  () GS:9df73728() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f2e235a8a88 CR3: 00012b20e002 CR4: 000606e0
Call Trace:
 ? vprintk_emit+0x1ec/0x250
 ptdump_walk_pgd_level_core+0x46a/0x4c0
 ? rest_init+0xaa/0xaa
 kernel_init+0x2c/0x106
 ret_from_fork+0x1f/0x40
---[ end trace 3288a26b9a3da7ee ]---
x86/mm: Checked W+X mappings: FAILED, 2175454 W+X pages found.
rodata_test: all tests were successful
Run /init as init process
---cut dmesg---


Thank you.

bug disabling NX (noexec=off)

2019-04-13 Thread Xose Vazquez Perez 
Hi,

Intel Core i3-2120 + kernel-5.0.7 x86_64 from Fedora:

[0.00] microcode: microcode updated early to revision 0x2e, date = 
2018-04-10
[0.00] Linux version 5.0.7-300.fc30.x86_64 
(mockbu...@bkernel04.phx2.fedoraproject.org) (gcc version 9.0.1 20190312 (Red 
Hat 9.0.1-0.10) (GCC)) #1 SMP Mon Apr 8 18:28:09 UTC 2019
[0.00] Command line: 
BOOT_IMAGE=(hd0,msdos1)/boot/vmlinuz-5.0.7-300.fc30.x86_64 
root=UUID=ea93877a-9487-4416-9f32-9d1fba2a639a ro quiet audit=0 
usb-storage.delay_use=0 net.ifnames=0
plymouth.enable=0 pti=off spectre_v2=off spectre_v2_user=off 
spec_store_bypass_disable=off l1tf=off noexec=off
[...]
[0.00] NX (Execute Disable) protection: disabled by kernel command line 
option
[0.00] [ cut here ]
[0.00] attempted to set unsupported pgprot: 8163 bits: 
8000 supported: 7fff
[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgtable.h:537 
__early_set_fixmap+0xa2/0xff
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.7-300.fc30.x86_64 #1
[0.00] RIP: 0010:__early_set_fixmap+0xa2/0xff
[0.00] Code: ed be ff 49 21 cc 4c 39 e2 74 21 80 3d b8 a2 bb ff 00 75 
18 4c 31 e2 48 c7 c7 68 b6 09 ac c6 05 a5 a2 bb ff 01 e8 ae ba 95 fe <0f> 0b 4c 
89 e7 4c 09 ef ff 14 25 98 e2 22 ac 48 89
c6 48 89 df ff
[0.00] RSP: :ac203de8 EFLAGS: 00010082 ORIG_RAX: 

[0.00] RAX:  RBX: ac972000 RCX: 0078
[0.00] RDX: 0001 RSI: 0092 RDI: 0047
[0.00] RBP: ff20 R08: 0001 R09: 0024
[0.00] R10: 0c1c R11: 0003 R12: 0163
[0.00] R13: 000f R14: 0001 R15: 
[0.00] FS:  () GS:ac73a000() 
knlGS:
[0.00] CS:  0010 DS:  ES:  CR0: 80050033
[0.00] CR2: 888046212ff8 CR3: 467de000 CR4: 000406a0
[0.00] Call Trace:
[0.00]  ? __early_ioremap+0x10b/0x189
[0.00]  ? dmi_scan_machine+0xfe/0x209
[0.00]  ? setup_arch+0x436/0xc9f
[0.00]  ? start_kernel+0x65/0x519
[0.00]  ? secondary_startup_64+0xa4/0xb0
[0.00] random: get_random_bytes called from 
print_oops_end_marker+0x26/0x40 with crng_init=0
[0.00] ---[ end trace  ]---
[0.00] SMBIOS 2.6 present.
[...]


The same happens in a T61 with an Intel Core 2 Duo T7300.


Thanks.

git: cover letter and automatic Cc: [was Re: [PATCH 23/45] sched: add do_sched_yield() helper; remove in-kernel call to sched_yield()]

2018-03-22 Thread Xose Vazquez Perez 
Linus Torvalds wrote:

> On Thu, Mar 22, 2018 at 10:29 AM, Peter Zijlstra  wrote:
>>
>> But why !? Either Cc me on more of the series such that the whole makes
>> sense, or better yet, write a proper Changelog.
> 
> This is a common issue. We should encourage people to always send at
> least the cover-page to everybody who gets cc'd, even if they don't
> get the whole series.


git should be smart enough to do it automatically by itself.

git: cover letter and automatic Cc: [was Re: [PATCH 23/45] sched: add do_sched_yield() helper; remove in-kernel call to sched_yield()]

2018-03-22 Thread Xose Vazquez Perez 
Linus Torvalds wrote:

> On Thu, Mar 22, 2018 at 10:29 AM, Peter Zijlstra  wrote:
>>
>> But why !? Either Cc me on more of the series such that the whole makes
>> sense, or better yet, write a proper Changelog.
> 
> This is a common issue. We should encourage people to always send at
> least the cover-page to everybody who gets cc'd, even if they don't
> get the whole series.


git should be smart enough to do it automatically by itself.

[PATCH] trivial: remove exec bit from random files

2016-08-14 Thread Xose Vazquez Perez 
These are not scripts.

Cc: Jiri Kosina <triv...@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
---
 arch/nios2/boot/dts/10m50_devboard.dts  | 0
 arch/nios2/configs/10m50_defconfig  | 0
 arch/sh/boot/dts/j2_mimas_v2.dts| 0
 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h   | 0
 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 arch/nios2/boot/dts/10m50_devboard.dts
 mode change 100755 => 100644 arch/nios2/configs/10m50_defconfig
 mode change 100755 => 100644 arch/sh/boot/dts/j2_mimas_v2.dts
 mode change 100755 => 100644 
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h
 mode change 100755 => 100644 
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h

diff --git a/arch/nios2/boot/dts/10m50_devboard.dts 
b/arch/nios2/boot/dts/10m50_devboard.dts
old mode 100755
new mode 100644
diff --git a/arch/nios2/configs/10m50_defconfig 
b/arch/nios2/configs/10m50_defconfig
old mode 100755
new mode 100644
diff --git a/arch/sh/boot/dts/j2_mimas_v2.dts b/arch/sh/boot/dts/j2_mimas_v2.dts
old mode 100755
new mode 100644
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h
old mode 100755
new mode 100644
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h
old mode 100755
new mode 100644
-- 
2.7.4

[PATCH] trivial: remove exec bit from random files

2016-08-14 Thread Xose Vazquez Perez 
These are not scripts.

Cc: Jiri Kosina 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Xose Vazquez Perez 
---
 arch/nios2/boot/dts/10m50_devboard.dts  | 0
 arch/nios2/configs/10m50_defconfig  | 0
 arch/sh/boot/dts/j2_mimas_v2.dts| 0
 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h   | 0
 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 arch/nios2/boot/dts/10m50_devboard.dts
 mode change 100755 => 100644 arch/nios2/configs/10m50_defconfig
 mode change 100755 => 100644 arch/sh/boot/dts/j2_mimas_v2.dts
 mode change 100755 => 100644 
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h
 mode change 100755 => 100644 
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h

diff --git a/arch/nios2/boot/dts/10m50_devboard.dts 
b/arch/nios2/boot/dts/10m50_devboard.dts
old mode 100755
new mode 100644
diff --git a/arch/nios2/configs/10m50_defconfig 
b/arch/nios2/configs/10m50_defconfig
old mode 100755
new mode 100644
diff --git a/arch/sh/boot/dts/j2_mimas_v2.dts b/arch/sh/boot/dts/j2_mimas_v2.dts
old mode 100755
new mode 100644
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h
old mode 100755
new mode 100644
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h
old mode 100755
new mode 100644
-- 
2.7.4

checkpatch.pl: how to run --fix-inplace for just only one warning/error

2016-08-06 Thread Xose Vazquez Perez 
Hi,

Maybe it's tricky, but could it be possible?
For example for: ERROR: space prohibited after that open parenthesis '('
Any hint?

Thank you.

checkpatch.pl: how to run --fix-inplace for just only one warning/error

2016-08-06 Thread Xose Vazquez Perez 
Hi,

Maybe it's tricky, but could it be possible?
For example for: ERROR: space prohibited after that open parenthesis '('
Any hint?

Thank you.

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Xose Vazquez Perez 
Arnd Bergmann  wrote:

> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.

A replacement for "staging/rtl8712", with MAC80211 support, is
available at: https://github.com/chunkeey/rtl8192su

Also a fullmac/cfg80211 driver(r92su) is available at the
same repository.

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Xose Vazquez Perez 
Arnd Bergmann  wrote:

> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.

A replacement for "staging/rtl8712", with MAC80211 support, is
available at: https://github.com/chunkeey/rtl8192su

Also a fullmac/cfg80211 driver(r92su) is available at the
same repository.

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

2016-06-21 Thread Xose Vazquez Perez 
Hisashi Kanda wrote:

> In fact, BUG() in do_sparc64_fault occurred in modified version
> of linux-2.6.25.8 on SPARC64VIIIfx. I'm misunderstanding that
> the same problem remains in the latest.

Fujitsu K computer, with SPARC64 VIIIfx, runs a heavily modified
2.6.25.8 kernel. And maybe also binutils, glibc, gcc, gdb, ...
Even UTS_MACHINE was changed from sparc64 to s64fx.

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

2016-06-21 Thread Xose Vazquez Perez 
Hisashi Kanda wrote:

> In fact, BUG() in do_sparc64_fault occurred in modified version
> of linux-2.6.25.8 on SPARC64VIIIfx. I'm misunderstanding that
> the same problem remains in the latest.

Fujitsu K computer, with SPARC64 VIIIfx, runs a heavily modified
2.6.25.8 kernel. And maybe also binutils, glibc, gcc, gdb, ...
Even UTS_MACHINE was changed from sparc64 to s64fx.

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

2016-05-13 Thread Xose Vazquez Perez 
On 05/13/2016 05:23 PM, Joe Perches wrote:

> The meaning of * is all the files in a particular
> directory but not any subdirectories.

Then "*" is only relevant for these entries:
drivers/char/*
drivers/misc/*
drivers/net/wireless/ath/*
fs/*

drivers/cpuidle/* < This is a bug, it should be drivers/cpuidle

All the others only have files inside, and "*"
is redundant.

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

2016-05-13 Thread Xose Vazquez Perez 
On 05/13/2016 05:23 PM, Joe Perches wrote:

> The meaning of * is all the files in a particular
> directory but not any subdirectories.

Then "*" is only relevant for these entries:
drivers/char/*
drivers/misc/*
drivers/net/wireless/ath/*
fs/*

drivers/cpuidle/* < This is a bug, it should be drivers/cpuidle

All the others only have files inside, and "*"
is redundant.

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

2016-05-13 Thread Xose Vazquez Perez 
Matt Fleming wrote:

> Mark reported that having asterisks on the end of directory names
> confuses get_maintainer.pl when it encounters subdirectories, and that

If this's a get_maintainer.pl bug, it should also happen in:

F:  arch/arm64/boot/dts/qcom/*
F:  arch/mips/bcm47xx/*
F:  arch/mips/bmips/*
F:  arch/mips/include/asm/mach-bcm47xx/*
F:  arch/mips/include/asm/mach-bmips/*
F:  arch/x86/kernel/cpu/mcheck/*
F:  arch/x86/kernel/cpu/microcode/*
F:  arch/x86/net/*
F:  Documentation/devicetree/bindings/arc/*
F:  Documentation/misc-devices/mei/*
F:  Documentation/ptp/*
F:  drivers/block/xen-blkback/*
F:  drivers/char/*
F:  drivers/cpuidle/*
F:  drivers/firmware/broadcom/*
F:  drivers/hwtracing/coresight/*
F:  drivers/media/i2c/s5c73m3/*
F:  drivers/media/pci/netup_unidvb/*
F:  drivers/media/platform/vivid/*
F:  drivers/media/usb/pwc/*
F:  drivers/misc/*
F:  drivers/misc/mei/*
F:  drivers/mtd/nand/gpmi-nand/*
F:  drivers/net/ethernet/pasemi/*
F:  drivers/net/ethernet/tehuti/*
F:  drivers/net/wireless/ath/*
F:  drivers/net/xen-netback/*
F:  drivers/nvdimm/*
F:  drivers/ptp/*
F:  drivers/soc/samsung/*
F:  drivers/soc/ti/*
F:  fs/*
F:  kernel/events/*
F:  net/wireless/*
F:  sound/soc/blackfin/*
F:  sound/soc/samsung/*
F:  tools/testing/selftests/seccomp/*

> my name does not appear when run on drivers/firmware/efi/libstub.
> Reported-by: Mark Rutland 
> Cc: Ard Biesheuvel 
> Cc: Catalin Marinas 
> Cc: 
> Signed-off-by: Matt Fleming 
> ---
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42e65d128d01..4dca3b3895ba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4223,8 +4223,8 @@ F:  Documentation/efi-stub.txt
>  F:   arch/ia64/kernel/efi.c
>  F:   arch/x86/boot/compressed/eboot.[ch]
>  F:   arch/x86/include/asm/efi.h
> -F:   arch/x86/platform/efi/*
> -F:   drivers/firmware/efi/*
> +F:   arch/x86/platform/efi/
> +F:   drivers/firmware/efi/
>  F:   include/linux/efi*.h
>  
>  EFI VARIABLE FILESYSTEM
> -- 
> 2.7.3

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

2016-05-13 Thread Xose Vazquez Perez 
Matt Fleming wrote:

> Mark reported that having asterisks on the end of directory names
> confuses get_maintainer.pl when it encounters subdirectories, and that

If this's a get_maintainer.pl bug, it should also happen in:

F:  arch/arm64/boot/dts/qcom/*
F:  arch/mips/bcm47xx/*
F:  arch/mips/bmips/*
F:  arch/mips/include/asm/mach-bcm47xx/*
F:  arch/mips/include/asm/mach-bmips/*
F:  arch/x86/kernel/cpu/mcheck/*
F:  arch/x86/kernel/cpu/microcode/*
F:  arch/x86/net/*
F:  Documentation/devicetree/bindings/arc/*
F:  Documentation/misc-devices/mei/*
F:  Documentation/ptp/*
F:  drivers/block/xen-blkback/*
F:  drivers/char/*
F:  drivers/cpuidle/*
F:  drivers/firmware/broadcom/*
F:  drivers/hwtracing/coresight/*
F:  drivers/media/i2c/s5c73m3/*
F:  drivers/media/pci/netup_unidvb/*
F:  drivers/media/platform/vivid/*
F:  drivers/media/usb/pwc/*
F:  drivers/misc/*
F:  drivers/misc/mei/*
F:  drivers/mtd/nand/gpmi-nand/*
F:  drivers/net/ethernet/pasemi/*
F:  drivers/net/ethernet/tehuti/*
F:  drivers/net/wireless/ath/*
F:  drivers/net/xen-netback/*
F:  drivers/nvdimm/*
F:  drivers/ptp/*
F:  drivers/soc/samsung/*
F:  drivers/soc/ti/*
F:  fs/*
F:  kernel/events/*
F:  net/wireless/*
F:  sound/soc/blackfin/*
F:  sound/soc/samsung/*
F:  tools/testing/selftests/seccomp/*

> my name does not appear when run on drivers/firmware/efi/libstub.
> Reported-by: Mark Rutland 
> Cc: Ard Biesheuvel 
> Cc: Catalin Marinas 
> Cc: 
> Signed-off-by: Matt Fleming 
> ---
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42e65d128d01..4dca3b3895ba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4223,8 +4223,8 @@ F:  Documentation/efi-stub.txt
>  F:   arch/ia64/kernel/efi.c
>  F:   arch/x86/boot/compressed/eboot.[ch]
>  F:   arch/x86/include/asm/efi.h
> -F:   arch/x86/platform/efi/*
> -F:   drivers/firmware/efi/*
> +F:   arch/x86/platform/efi/
> +F:   drivers/firmware/efi/
>  F:   include/linux/efi*.h
>  
>  EFI VARIABLE FILESYSTEM
> -- 
> 2.7.3

Re: [PATCH v2] carl9170: Clarify kconfig text

2016-04-18 Thread Xose Vazquez Perez 
Christian Lamparter wrote:

> Sure, but this could be a different patch then. I think Intel devices 
> (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
> firmware from this device from our homepage here" too. So if we want,
> we can remove them altogether?

linux-firmware.git does not contain firmware for all drivers. _At least_
zd1211rw [1], atmel [2] and ipw2x00 [3] are out of the tree.

[1] http://sf.net/projects/zd1211/files/
[2] 
http://web.archive.org/web/20121016132320/http://at76c503a.berlios.de/fw_dl.html
[3] http://ipw2100.sf.net/firmware.php http://ipw2200.sf.net/firmware.php

Re: [PATCH v2] carl9170: Clarify kconfig text

2016-04-18 Thread Xose Vazquez Perez 
Christian Lamparter wrote:

> Sure, but this could be a different patch then. I think Intel devices 
> (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
> firmware from this device from our homepage here" too. So if we want,
> we can remove them altogether?

linux-firmware.git does not contain firmware for all drivers. _At least_
zd1211rw [1], atmel [2] and ipw2x00 [3] are out of the tree.

[1] http://sf.net/projects/zd1211/files/
[2] 
http://web.archive.org/web/20121016132320/http://at76c503a.berlios.de/fw_dl.html
[3] http://ipw2100.sf.net/firmware.php http://ipw2200.sf.net/firmware.php

Re: [PATCH kernel.org] change 3.12 EOL

2016-04-11 Thread Xose Vazquez Perez 
Jiri Slaby wrote:

> diff --git a/content/releases.rst b/content/releases.rst
> index 28ebf47834..14494a64cd 100644
> --- a/content/releases.rst
> +++ b/content/releases.rst
> @@ -44,7 +44,7 @@ Longterm
>  4.1  Sasha Levin  2015-06-21   Sep, 2017
>  3.18 Sasha Levin  2014-12-07   Jan, 2017
>  3.14 Greg Kroah-Hartman   2014-03-30   Aug, 2016
> -3.12 Jiri Slaby   2013-11-03   2016
> +3.12 Jiri Slaby   2013-11-03   Jan, 2017
>  3.10 Greg Kroah-Hartman   2013-06-30   End of 2015 <<<---
  ^^^
3.10 is still alive(3.10.101 2016-03-16)

>  3.4  Li Zefan 2012-05-20   Sep, 2016
>  3.2  Ben Hutchings2012-01-04   May, 2018
> -- 
> 2.8.1

Re: [PATCH kernel.org] change 3.12 EOL

2016-04-11 Thread Xose Vazquez Perez 
Jiri Slaby wrote:

> diff --git a/content/releases.rst b/content/releases.rst
> index 28ebf47834..14494a64cd 100644
> --- a/content/releases.rst
> +++ b/content/releases.rst
> @@ -44,7 +44,7 @@ Longterm
>  4.1  Sasha Levin  2015-06-21   Sep, 2017
>  3.18 Sasha Levin  2014-12-07   Jan, 2017
>  3.14 Greg Kroah-Hartman   2014-03-30   Aug, 2016
> -3.12 Jiri Slaby   2013-11-03   2016
> +3.12 Jiri Slaby   2013-11-03   Jan, 2017
>  3.10 Greg Kroah-Hartman   2013-06-30   End of 2015 <<<---
  ^^^
3.10 is still alive(3.10.101 2016-03-16)

>  3.4  Li Zefan 2012-05-20   Sep, 2016
>  3.2  Ben Hutchings2012-01-04   May, 2018
> -- 
> 2.8.1

Re: Generic kernel features that need architecture(mips) support

2015-06-10 Thread Xose Vazquez Perez 
On 06/10/2015 04:58 PM, Ralf Baechle wrote:

> How are the documentation files in Documentation/features/ maintained?
> They were automatically generated so I wonder if I have to take care
> of anything.

CC: Ingo and related ml.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic kernel features that need architecture(mips) support

2015-06-10 Thread Xose Vazquez Perez 
On 06/10/2015 04:58 PM, Ralf Baechle wrote:

 How are the documentation files in Documentation/features/ maintained?
 They were automatically generated so I wonder if I have to take care
 of anything.

CC: Ingo and related ml.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] firmware: Update information in linux.git about adding firmware

2015-04-17 Thread Xose Vazquez Perez 
On 04/13/2015 04:20 AM, Ben Hutchings wrote:
> Kyle McMartin joined the linux-firmware maintainers, and we now
> have an alias  which reaches all of us.
> Include that instead of the individual addresses.
> 
> Add some further recommendations that were already included in the
> README in linux-firmware.git added by Xose Vazquez Perez
> .
> 
> Signed-off-by: Ben Hutchings 
> ---
>  firmware/README.AddingFirmware | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/firmware/README.AddingFirmware b/firmware/README.AddingFirmware
> index ea78c3a..bcb5f46 100644
> --- a/firmware/README.AddingFirmware
> +++ b/firmware/README.AddingFirmware
> @@ -21,15 +21,25 @@ been permitted to redistribute under separate cover.
>  
>  To submit firmware to that repository, please send either a git binary
>  diff or preferably a git pull request to:
> -  David Woodhouse 
> -  Ben Hutchings 
> +  linux-firmw...@kernel.org
> +and also cc: to related mailing lists.
>  
>  Your commit should include an update to the WHENCE file clearly
>  identifying the licence under which the firmware is available, and
>  that it is redistributable. If the licence is long and involved, it's
>  permitted to include it in a separate file and refer to it from the
>  WHENCE file.
> +And if it were possible, a changelog of the firmware itself.
>  
>  Ideally, your commit should contain a Signed-Off-By: from someone
>  authoritative on the licensing of the firmware in question (i.e. from
>  within the company that owns the code).
> +
> +
> +WARNING:
> +===
> +
> +Don't send any "CONFIDENTIALITY STATEMENT" in your e-mail, patch or
> +request. Otherwise your firmware _will never be accepted_.
> +
> +Maintainers are really busy, so don't expect a prompt reply.
> 
> 
> 

Hi Jonathan,

Could you take this patch?

-thanks-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] firmware: Update information in linux.git about adding firmware

2015-04-17 Thread Xose Vazquez Perez 
On 04/13/2015 04:20 AM, Ben Hutchings wrote:
 Kyle McMartin joined the linux-firmware maintainers, and we now
 have an alias linux-firmw...@kernel.org which reaches all of us.
 Include that instead of the individual addresses.
 
 Add some further recommendations that were already included in the
 README in linux-firmware.git added by Xose Vazquez Perez
 xose.vazq...@gmail.com.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
  firmware/README.AddingFirmware | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/firmware/README.AddingFirmware b/firmware/README.AddingFirmware
 index ea78c3a..bcb5f46 100644
 --- a/firmware/README.AddingFirmware
 +++ b/firmware/README.AddingFirmware
 @@ -21,15 +21,25 @@ been permitted to redistribute under separate cover.
  
  To submit firmware to that repository, please send either a git binary
  diff or preferably a git pull request to:
 -  David Woodhouse dw...@infradead.org
 -  Ben Hutchings b...@decadent.org.uk
 +  linux-firmw...@kernel.org
 +and also cc: to related mailing lists.
  
  Your commit should include an update to the WHENCE file clearly
  identifying the licence under which the firmware is available, and
  that it is redistributable. If the licence is long and involved, it's
  permitted to include it in a separate file and refer to it from the
  WHENCE file.
 +And if it were possible, a changelog of the firmware itself.
  
  Ideally, your commit should contain a Signed-Off-By: from someone
  authoritative on the licensing of the firmware in question (i.e. from
  within the company that owns the code).
 +
 +
 +WARNING:
 +===
 +
 +Don't send any CONFIDENTIALITY STATEMENT in your e-mail, patch or
 +request. Otherwise your firmware _will never be accepted_.
 +
 +Maintainers are really busy, so don't expect a prompt reply.
 
 
 

Hi Jonathan,

Could you take this patch?

-thanks-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Fix Free Software Foundation address in file headers

2013-12-01 Thread Xose Vazquez Perez 
Jeff Kirsher wrote:

> This came up when John Fastabend got a patch to fix up the headers in
> the drivers/scsi/ directory and so I did a quick search of the network
> drivers and found several instances in the file headers where an old FSF
> address remains.  The old address is:
> 
> 59 Temple Place - Suite 330
> Boston, MA 02111-1307
> 
> The current address is:
> 
> 51 Franklin Street - Fifth Floor
> Boston, MA 02110-1301
> 
> I am wondering whether it may be best to just put a link to the Free
> Software Foundation web page instead of having to update the address any
> time a change is made.
> 
> Either way, I feel the address either needs to get corrected or changed
> to the URL, even though I am not a fan of huge patch series to make
> trivial changes like this.
> 
> Thoughts?

Something like that should be enough:

 [...]
 You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+with this program.  If not, see .
 [...]

This was changed in that form in gpl3.


There are about 3684 references with, at least, 140 variations. Infinite 
Patience(TM).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Fix Free Software Foundation address in file headers

2013-12-01 Thread Xose Vazquez Perez 
Jeff Kirsher wrote:

 This came up when John Fastabend got a patch to fix up the headers in
 the drivers/scsi/ directory and so I did a quick search of the network
 drivers and found several instances in the file headers where an old FSF
 address remains.  The old address is:
 
 59 Temple Place - Suite 330
 Boston, MA 02111-1307
 
 The current address is:
 
 51 Franklin Street - Fifth Floor
 Boston, MA 02110-1301
 
 I am wondering whether it may be best to just put a link to the Free
 Software Foundation web page instead of having to update the address any
 time a change is made.
 
 Either way, I feel the address either needs to get corrected or changed
 to the URL, even though I am not a fan of huge patch series to make
 trivial changes like this.
 
 Thoughts?

Something like that should be enough:

 [...]
 You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+with this program.  If not, see http://www.gnu.org/licenses/.
 [...]

This was changed in that form in gpl3.


There are about 3684 references with, at least, 140 variations. Infinite 
Patience(TM).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -rc1] s390: increase the NR_CPUS limit

2013-11-29 Thread Xose Vazquez Perez 
In current models, maximum number of active cores is 101.

Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: 
Cc: 
Cc: 
Signed-off-by: Xose Vazquez Perez 
---
 arch/s390/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 314fced..87afb9a 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -347,14 +347,14 @@ config SMP
  Even if you don't know what to do here, say Y.
 
 config NR_CPUS
-   int "Maximum number of CPUs (2-64)"
-   range 2 64
+   int "Maximum number of CPUs (2-101)"
+   range 2 101
depends on SMP
default "32" if !64BIT
default "64" if 64BIT
help
  This allows you to specify the maximum number of CPUs which this
- kernel will support.  The maximum supported value is 64 and the
+ kernel will support.  The maximum supported value is 101 and the
  minimum value which makes sense is 2.
 
  This is purely to save memory - each supported CPU adds
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -rc1] s390: increase the NR_CPUS limit

2013-11-29 Thread Xose Vazquez Perez 
In current models, maximum number of active cores is 101.

Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Cc: linux...@de.ibm.com
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com
---
 arch/s390/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 314fced..87afb9a 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -347,14 +347,14 @@ config SMP
  Even if you don't know what to do here, say Y.
 
 config NR_CPUS
-   int Maximum number of CPUs (2-64)
-   range 2 64
+   int Maximum number of CPUs (2-101)
+   range 2 101
depends on SMP
default 32 if !64BIT
default 64 if 64BIT
help
  This allows you to specify the maximum number of CPUs which this
- kernel will support.  The maximum supported value is 64 and the
+ kernel will support.  The maximum supported value is 101 and the
  minimum value which makes sense is 2.
 
  This is purely to save memory - each supported CPU adds
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] linux-firmware: add MISSING file

2013-01-12 Thread Xose Vazquez Perez 
to document the reason why a firmware is not present

Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Cc: David Woodhouse 
Cc: Ben Hutchings 
Cc: 
Cc: 
Signed-off-by: Xose Vazquez Perez 
---
 MISSING | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 MISSING

diff --git a/MISSING b/MISSING
new file mode 100644
index 000..f228099
--- /dev/null
+++ b/MISSING
@@ -0,0 +1,20 @@
+ ***
+ * MISSING *
+ ***
+
+This file attempts to document the reason why a firmware is not present
+in this bundle.
+
+--
+
+Driver: zd1211rw -- ZyDAS/Atheros ZD1211/ZD1211B/AR5007UG wireless driver
+
+Trouble: Allegedly GPLv2, but no source visible. Found in hex form in the
+ vendor driver.
+
+URL: http://sf.net/projects/zd1211/files/
+
+Implication: CRITICAL, hardware undetected.
+
+--
+
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] linux-firmware: add MISSING file

2013-01-12 Thread Xose Vazquez Perez 
to document the reason why a firmware is not present

Cc: Daniel Drake d...@laptop.org
Cc: Ulrich Kunitz k...@deine-taler.de
Cc: David Woodhouse dw...@infradead.org
Cc: Ben Hutchings b...@decadent.org.uk
Cc: linux-wirel...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com
---
 MISSING | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 MISSING

diff --git a/MISSING b/MISSING
new file mode 100644
index 000..f228099
--- /dev/null
+++ b/MISSING
@@ -0,0 +1,20 @@
+ ***
+ * MISSING *
+ ***
+
+This file attempts to document the reason why a firmware is not present
+in this bundle.
+
+--
+
+Driver: zd1211rw -- ZyDAS/Atheros ZD1211/ZD1211B/AR5007UG wireless driver
+
+Trouble: Allegedly GPLv2, but no source visible. Found in hex form in the
+ vendor driver.
+
+URL: http://sf.net/projects/zd1211/files/
+
+Implication: CRITICAL, hardware undetected.
+
+--
+
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

what's about 2.2 kernel?

2007-08-05 Thread Xose Vazquez Perez 

hi,

time to release a final 2.2.27 and close the
2.2 tree ???


The latest 2.2 version  : 2.2.26 2004-02-25 00:28 UTC
The latest prepatch 2.2 : 2.2.27-rc2 2005-01-12 23:55 UTC


regards,
--
Politicos de mierda, yo no soy un terrorista.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

what's about 2.2 kernel?

2007-08-05 Thread Xose Vazquez Perez 

hi,

time to release a final 2.2.27 and close the
2.2 tree ???


The latest 2.2 version  : 2.2.26 2004-02-25 00:28 UTC
The latest prepatch 2.2 : 2.2.27-rc2 2005-01-12 23:55 UTC


regards,
--
Politicos de mierda, yo no soy un terrorista.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] ISIC + 2.6.22 (via-rhine)

2007-07-31 Thread Xose Vazquez Perez 

Arjan van de Ven wrote:


=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (>lock){++..}, at: [] rhine_tx_timeout+0x6f/0xf4 [via_rhine]




this is a case of homegrown locking: the via-rhine driver does

/* protect against concurrent rx interrupts */
disable_irq(rp->pdev->irq);

spin_lock(>lock);

/* clear all descriptors */
free_tbufs(dev);
free_rbufs(dev);
alloc_tbufs(dev);
alloc_rbufs(dev);

/* Reinitialize the hardware. */
rhine_chip_reset(dev);
init_registers(dev);  


spin_unlock(>lock);
enable_irq(rp->pdev->irq);


as a way to protect code against interrupts... rather than using the
normal mechanism.


the annotation is pretty simple (untested, not even compiled):

--- linux-2.6.22/drivers/net/via-rhine.c.org2007-07-31 14:22:06.0 
-0700
+++ linux-2.6.22/drivers/net/via-rhine.c2007-07-31 14:22:26.0 
-0700
@@ -1191,7 +1191,7 @@
   mdio_read(dev, rp->mii_if.phy_id, MII_BMSR));
 
 	/* protect against concurrent rx interrupts */

-   disable_irq(rp->pdev->irq);
+   disable_irq_lockdep(rp->pdev->irq);
 
 	spin_lock(>lock);
 
@@ -1206,7 +1206,7 @@

init_registers(dev);
 
 	spin_unlock(>lock);

-   enable_irq(rp->pdev->irq);
+   enable_irq_lockdep(rp->pdev->irq);
 
 	dev->trans_start = jiffies;

rp->stats.tx_errors++;


thanks Arjan. Patch applied and now I get:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status , PHY status 786d, resetting...

==
[ INFO: hard-safe -> hard-unsafe lock order detected ]
2.6.22 #1
--
swapper/0 [HC0[0]:SC1[1]:HE0:SE0] is trying to acquire:
 (af_callback_keys + sk->sk_family#3){-.-?}, at: [] 
sock_def_write_space+0x18/0x96

and this task is already holding:
 (>lock){++..}, at: [] rhine_tx_timeout+0x75/0x102 [via_rhine]
which would create a new lock dependency:
 (>lock){++..} -> (af_callback_keys + sk->sk_family#3){-.-?}

but this new dependency connects a hard-irq-safe lock:
 (>lock){++..}
... which became hard-irq-safe at:
  [] __lock_acquire+0x38c/0xb12
  [] lock_acquire+0x56/0x6f
  [] _spin_lock+0x2b/0x38
  [] rhine_interrupt+0x16b/0x69b [via_rhine]
  [] handle_IRQ_event+0x1a/0x46
  [] handle_fasteoi_irq+0x7d/0xb6
  [] do_IRQ+0xb1/0xd8
  [] 0x

to a hard-irq-unsafe lock:
 (af_callback_keys + sk->sk_family#3){-.-?}
... which became hard-irq-unsafe at:
...  [] __lock_acquire+0x3fc/0xb12
  [] lock_acquire+0x56/0x6f
  [] _write_lock_bh+0x30/0x3d
  [] tcp_close+0x24e/0x531
  [] inet_release+0x43/0x49
  [] sock_release+0x17/0x62
  [] sock_close+0x2d/0x33
  [] __fput+0xbe/0x168
  [] fput+0x17/0x19
  [] filp_close+0x54/0x5c
  [] sys_close+0x78/0xb0
  [] sysenter_past_esp+0x5f/0x99
  [] 0x

other info that might help us debug this:

2 locks held by swapper/0:
 #0:  (_xmit_ETHER){-+..}, at: [] dev_watchdog+0x14/0xbf
 #1:  (>lock){++..}, at: [] rhine_tx_timeout+0x75/0x102 
[via_rhine]

the hard-irq-safe lock's dependencies:
-> (>lock){++..} ops: 0 {
   initial-use  at:
[] __lock_acquire+0x435/0xb12
[] lock_acquire+0x56/0x6f
[] _spin_lock_irqsave+0x34/0x44
[] rhine_get_stats+0x2d/0x9d [via_rhine]
[] rtnl_fill_ifinfo+0x2e9/0x414
[] rtmsg_ifinfo+0x57/0xd4
[] rtnetlink_event+0x38/0x3c
[] notifier_call_chain+0x2b/0x4a
[] __raw_notifier_call_chain+0x19/0x1e
[] raw_notifier_call_chain+0x1a/0x1c
[] register_netdevice+0x335/0x33f
[] register_netdev+0x40/0x4d
[] rhine_init_one+0x515/0x6c7 [via_rhine]
[] pci_device_probe+0x39/0x5b
[] driver_probe_device+0xe9/0x16a
[] __driver_attach+0x76/0xaf
[] bus_for_each_dev+0x3a/0x5f
[] driver_attach+0x19/0x1b
[] bus_add_driver+0x79/0x181
[] driver_register+0x67/0x6c
[] __pci_register_driver+0x56/0x83
[] 0xf885f06c
[] sys_init_module+0x1579/0x16ca
[] sysenter_past_esp+0x5f/0x99
[] 0x
   in-hardirq-W at:
[] __lock_acquire+0x38c/0xb12
[] lock_acquire+0x56/0x6f
[] _spin_lock+0x2b/0x38
[] rhine_interrupt+0x16b/0x69b [via_rhine]
[] handle_IRQ_event+0x1a/0x46

[BUG] ISIC + 2.6.22 (via-rhine)

2007-07-31 Thread Xose Vazquez Perez 

hi,

Running  ISIC -- IP Stack Integrity Checker ( http://isic.sf.net ),
in Fedora-7-i386 with 2.6.22, the NIC stopped to send packages.
But one second latter it began to send out more of them.
dmesg shows the bug.


command is:
# tcpsic -s rand -d 172.26.0.2 -I100


driver is:
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine II at 0xbc00, 00:11:d8:54:e9:3c, IRQ 19.
eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present

---lspci--
00:12.0 0200: 1106:3065 (rev 78)
Subsystem: 1043:80ed
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-  {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (>lock){++..}, at: [] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
{in-hardirq-W} state was registered at:
  [] __lock_acquire+0x38c/0xb12
  [] lock_acquire+0x56/0x6f
  [] _spin_lock+0x2b/0x38
  [] rhine_interrupt+0x16b/0x69b [via_rhine]
  [] handle_IRQ_event+0x1a/0x46
  [] handle_fasteoi_irq+0x7d/0xb6
  [] do_IRQ+0xb1/0xd8
  [] 0x
irq event stamp: 18052892
hardirqs last  enabled at (18052892): [] 
_spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (18052891): [] _spin_lock_irqsave+0x12/0x44
softirqs last  enabled at (18052876): [] __do_softirq+0xe3/0xe9
softirqs last disabled at (18052887): [] do_softirq+0x61/0xc7

other info that might help us debug this:
1 lock held by swapper/0:
 #0:  (_xmit_ETHER){-+..}, at: [] dev_watchdog+0x14/0xbf

stack backtrace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_trace+0x12/0x14
 [] dump_stack+0x16/0x18
 [] print_usage_bug+0x141/0x14b
 [] mark_lock+0x1fd/0x409
 [] __lock_acquire+0x3fc/0xb12
 [] lock_acquire+0x56/0x6f
 [] _spin_lock+0x2b/0x38
 [] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
 [] dev_watchdog+0x76/0xbf
 [] run_timer_softirq+0x11a/0x182
 [] __do_softirq+0x6f/0xe9
 [] do_softirq+0x61/0xc7
 ===
via-rhine: Reset not complete yet. Trying harder.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
--end---



-thanks-


--
Politicos de mierda, yo no soy un terrorista.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] ISIC + 2.6.22 (via-rhine)

2007-07-31 Thread Xose Vazquez Perez 

hi,

Running  ISIC -- IP Stack Integrity Checker ( http://isic.sf.net ),
in Fedora-7-i386 with 2.6.22, the NIC stopped to send packages.
But one second latter it began to send out more of them.
dmesg shows the bug.


command is:
# tcpsic -s rand -d 172.26.0.2 -I100


driver is:
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine II at 0xbc00, 00:11:d8:54:e9:3c, IRQ 19.
eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present

---lspci--
00:12.0 0200: 1106:3065 (rev 78)
Subsystem: 1043:80ed
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 32 (750ns min, 2000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 7000 [size=256]
Region 1: Memory at bc00 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--end--


--dmesg output--
[...]
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status , PHY status 786d, resetting...

=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (rp-lock){++..}, at: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
{in-hardirq-W} state was registered at:
  [c04440d4] __lock_acquire+0x38c/0xb12
  [c0444c1b] lock_acquire+0x56/0x6f
  [c0615279] _spin_lock+0x2b/0x38
  [f8c87b49] rhine_interrupt+0x16b/0x69b [via_rhine]
  [c045aac6] handle_IRQ_event+0x1a/0x46
  [c045bbc0] handle_fasteoi_irq+0x7d/0xb6
  [c0407089] do_IRQ+0xb1/0xd8
  [] 0x
irq event stamp: 18052892
hardirqs last  enabled at (18052892): [c061567d] 
_spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (18052891): [c061558d] _spin_lock_irqsave+0x12/0x44
softirqs last  enabled at (18052876): [c042d272] __do_softirq+0xe3/0xe9
softirqs last disabled at (18052887): [c0406f72] do_softirq+0x61/0xc7

other info that might help us debug this:
1 lock held by swapper/0:
 #0:  (_xmit_ETHER){-+..}, at: [c05c042a] dev_watchdog+0x14/0xbf

stack backtrace:
 [c0405e6a] show_trace_log_lvl+0x1a/0x2f
 [c04068cf] show_trace+0x12/0x14
 [c0406928] dump_stack+0x16/0x18
 [c0442ccd] print_usage_bug+0x141/0x14b
 [c04434fd] mark_lock+0x1fd/0x409
 [c0444144] __lock_acquire+0x3fc/0xb12
 [c0444c1b] lock_acquire+0x56/0x6f
 [c0615279] _spin_lock+0x2b/0x38
 [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
 [c05c048c] dev_watchdog+0x76/0xbf
 [c04303be] run_timer_softirq+0x11a/0x182
 [c042d1fe] __do_softirq+0x6f/0xe9
 [c0406f72] do_softirq+0x61/0xc7
 ===
via-rhine: Reset not complete yet. Trying harder.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
--end---



-thanks-


--
Politicos de mierda, yo no soy un terrorista.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] ISIC + 2.6.22 (via-rhine)

2007-07-31 Thread Xose Vazquez Perez 

Arjan van de Ven wrote:


=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (rp-lock){++..}, at: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]




this is a case of homegrown locking: the via-rhine driver does

/* protect against concurrent rx interrupts */
disable_irq(rp-pdev-irq);

spin_lock(rp-lock);

/* clear all descriptors */
free_tbufs(dev);
free_rbufs(dev);
alloc_tbufs(dev);
alloc_rbufs(dev);

/* Reinitialize the hardware. */
rhine_chip_reset(dev);
init_registers(dev);  


spin_unlock(rp-lock);
enable_irq(rp-pdev-irq);


as a way to protect code against interrupts... rather than using the
normal mechanism.


the annotation is pretty simple (untested, not even compiled):

--- linux-2.6.22/drivers/net/via-rhine.c.org2007-07-31 14:22:06.0 
-0700
+++ linux-2.6.22/drivers/net/via-rhine.c2007-07-31 14:22:26.0 
-0700
@@ -1191,7 +1191,7 @@
   mdio_read(dev, rp-mii_if.phy_id, MII_BMSR));
 
 	/* protect against concurrent rx interrupts */

-   disable_irq(rp-pdev-irq);
+   disable_irq_lockdep(rp-pdev-irq);
 
 	spin_lock(rp-lock);
 
@@ -1206,7 +1206,7 @@

init_registers(dev);
 
 	spin_unlock(rp-lock);

-   enable_irq(rp-pdev-irq);
+   enable_irq_lockdep(rp-pdev-irq);
 
 	dev-trans_start = jiffies;

rp-stats.tx_errors++;


thanks Arjan. Patch applied and now I get:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status , PHY status 786d, resetting...

==
[ INFO: hard-safe - hard-unsafe lock order detected ]
2.6.22 #1
--
swapper/0 [HC0[0]:SC1[1]:HE0:SE0] is trying to acquire:
 (af_callback_keys + sk-sk_family#3){-.-?}, at: [c05ab7d3] 
sock_def_write_space+0x18/0x96

and this task is already holding:
 (rp-lock){++..}, at: [f8d0a0e1] rhine_tx_timeout+0x75/0x102 [via_rhine]
which would create a new lock dependency:
 (rp-lock){++..} - (af_callback_keys + sk-sk_family#3){-.-?}

but this new dependency connects a hard-irq-safe lock:
 (rp-lock){++..}
... which became hard-irq-safe at:
  [c04440d4] __lock_acquire+0x38c/0xb12
  [c0444c1b] lock_acquire+0x56/0x6f
  [c0615279] _spin_lock+0x2b/0x38
  [f8d08b49] rhine_interrupt+0x16b/0x69b [via_rhine]
  [c045aac6] handle_IRQ_event+0x1a/0x46
  [c045bbc0] handle_fasteoi_irq+0x7d/0xb6
  [c0407089] do_IRQ+0xb1/0xd8
  [] 0x

to a hard-irq-unsafe lock:
 (af_callback_keys + sk-sk_family#3){-.-?}
... which became hard-irq-unsafe at:
...  [c0444144] __lock_acquire+0x3fc/0xb12
  [c0444c1b] lock_acquire+0x56/0x6f
  [c061532b] _write_lock_bh+0x30/0x3d
  [c05d829e] tcp_close+0x24e/0x531
  [c05f1175] inet_release+0x43/0x49
  [c05a85d4] sock_release+0x17/0x62
  [c05a89fb] sock_close+0x2d/0x33
  [c047db0f] __fput+0xbe/0x168
  [c047dbd0] fput+0x17/0x19
  [c047b4b5] filp_close+0x54/0x5c
  [c047c444] sys_close+0x78/0xb0
  [c0404e26] sysenter_past_esp+0x5f/0x99
  [] 0x

other info that might help us debug this:

2 locks held by swapper/0:
 #0:  (_xmit_ETHER){-+..}, at: [c05c042a] dev_watchdog+0x14/0xbf
 #1:  (rp-lock){++..}, at: [f8d0a0e1] rhine_tx_timeout+0x75/0x102 
[via_rhine]

the hard-irq-safe lock's dependencies:
- (rp-lock){++..} ops: 0 {
   initial-use  at:
[c044417d] __lock_acquire+0x435/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c06155af] _spin_lock_irqsave+0x34/0x44
[f8d0a19b] rhine_get_stats+0x2d/0x9d [via_rhine]
[c05b9017] rtnl_fill_ifinfo+0x2e9/0x414
[c05b9547] rtmsg_ifinfo+0x57/0xd4
[c05b95fc] rtnetlink_event+0x38/0x3c
[c0616f9e] notifier_call_chain+0x2b/0x4a
[c0433984] __raw_notifier_call_chain+0x19/0x1e
[c04339a3] raw_notifier_call_chain+0x1a/0x1c
[c05b14a3] register_netdevice+0x335/0x33f
[c05b27d6] register_netdev+0x40/0x4d
[f8d09d07] rhine_init_one+0x515/0x6c7 [via_rhine]
[c04f8085] pci_device_probe+0x39/0x5b
[c055cffc] driver_probe_device+0xe9/0x16a
[c055d1a6] __driver_attach+0x76/0xaf
[c055c4ec] bus_for_each_dev+0x3a/0x5f
[c055ce47] driver_attach+0x19/0x1b
[c055c80a] bus_add_driver+0x79/0x181
[c055d3a1] driver_register+0x67/0x6c
[c04f81dd] __pci_register_driver+0x56/0x83
[f885f06c] 0xf885f06c
[c044b77f] sys_init_module+0x1579/0x16ca

[PATCH 2.6.12 1/1] docs: updated some code docs

2005-07-26 Thread Xose Vazquez Perez 
Updated docs about how to write and submit patches/code.
diff -Nuar old/Documentation/CodingStyle new/Documentation/CodingStyle
--- old/Documentation/CodingStyle	2005-07-26 00:10:55.0 +0200
+++ new/Documentation/CodingStyle	2005-07-25 23:58:37.0 +0200
@@ -422,10 +422,13 @@
 URL: http://cm.bell-labs.com/cm/cs/tpop/
 
 GNU manuals - where in compliance with K and this text - for cpp, gcc,
-gcc internals and indent, all available from http://www.gnu.org
+gcc internals and indent, all available from http://www.gnu.org/manual/
 
 WG14 is the international standardization working group for the programming
 language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/
 
+Kernel CodingStyle by [EMAIL PROTECTED] at OLS 2002:
+http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
+
 --
 Last updated on 16 February 2004 by a community effort on LKML.
diff -Nuar old/Documentation/SubmittingDrivers new/Documentation/SubmittingDrivers
--- old/Documentation/SubmittingDrivers	2005-07-26 00:11:01.0 +0200
+++ new/Documentation/SubmittingDrivers	2005-07-27 00:07:10.0 +0200
@@ -26,17 +26,17 @@
 
 
 Linux 2.0:
-	No new drivers are accepted for this kernel tree
+	No new drivers are accepted for this kernel tree.
 
 Linux 2.2:
+	No new drivers are accepted for this kernel tree.
+
+Linux 2.4:
 	If the code area has a general maintainer then please submit it to
 	the maintainer listed in MAINTAINERS in the kernel file. If the
 	maintainer does not respond or you cannot find the appropriate
-	maintainer then please contact Alan Cox <[EMAIL PROTECTED]>
-
-Linux 2.4:
-	The same rules apply as 2.2. The final contact point for Linux 2.4
-	submissions is Marcelo Tosatti <[EMAIL PROTECTED]>.
+	maintainer then please contact Marcelo Tosatti
+	<[EMAIL PROTECTED]>.
 
 Linux 2.6:
 	The same rules apply as 2.4 except that you should follow linux-kernel
@@ -51,6 +51,7 @@
 		of exclusively GPL licensing, and if you wish the driver
 		to be useful to other communities such as BSD you may well
 		wish to release under multiple licenses.
+		See accepted licenses at include/linux/module.h
 
 Copyright:	The copyright owner must agree to use of GPL.
 		It's best if the submitter and copyright owner
@@ -141,5 +142,13 @@
 	http://kernelnewbies.org/
 
 Linux USB project:
-	http://sourceforge.net/projects/linux-usb/
+	http://linux-usb.sourceforge.net/
+
+How to NOT write kernel driver by [EMAIL PROTECTED]
+	http://people.redhat.com/arjanv/olspaper.pdf
+
+Kernel Janitor:
+	http://janitor.kernelnewbies.org/
 
+--
+Last updated on 25 Jul 2005.
diff -Nuar old/Documentation/SubmittingPatches new/Documentation/SubmittingPatches
--- old/Documentation/SubmittingPatches	2005-07-26 00:11:01.0 +0200
+++ new/Documentation/SubmittingPatches	2005-07-27 00:03:56.0 +0200
@@ -35,7 +35,7 @@
 
 To create a patch for a single file, it is often sufficient to do:
 
-	SRCTREE= linux-2.4
+	SRCTREE= linux-2.6
 	MYFILE=  drivers/net/mydriver.c
 
 	cd $SRCTREE
@@ -48,9 +48,9 @@
 or unmodified kernel source tree, and generate a diff against your
 own source tree.  For example:
 
-	MYSRC= /devel/linux-2.4
+	MYSRC= /devel/linux-2.6
 
-	tar xvfz linux-2.4.0-test11.tar.gz
+	tar xvfz linux-2.6.0.tar.gz
 	mv linux linux-vanilla
 	wget http://www.moses.uklinux.net/patches/dontdiff
 	diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch
@@ -77,7 +77,7 @@
 http://developer.osdl.org/rddunlap/scripts/patching-scripts.tgz
 
 Andrew Morton's patch scripts:
-http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16
+http://www.zip.com.au/~akpm/linux/patches/
 
 2) Describe your changes.
 
@@ -94,7 +94,7 @@
 
 3) Separate your changes.
 
-Separate each logical change into its own patch.
+Separate each _logical changes_ into its own patch.
 
 For example, if your changes include both bug fixes and performance
 enhancements for a single driver, separate those changes into two
@@ -102,13 +102,17 @@
 driver which uses that new API, separate those into two patches.
 
 On the other hand, if you make a single change to numerous files,
-group those changes into a single patch.  Thus a single logical change
-is contained within a single patch.
+group those changes into a single patch.  Thus single logical changes
+are contained within a single patch.
 
 If one patch depends on another patch in order for a change to be
 complete, that is OK.  Simply note "this patch depends on patch X"
 in your patch description.
 
+If you cannot condense your patch set into a smaller set of patches,
+then only post say 15 or so at a time and wait for review and integration.
+
+
 
 4) Select e-mail destination.
 
@@ -121,6 +125,8 @@
 [EMAIL PROTECTED]  Most kernel developers monitor this
 e-mail list, and can comment on your changes.
 
+Do not send more than 15 patches at once to the vger mailing lists!!!
+
 Linus Torvalds is the final arbiter of all changes accepted into the
 Linux kernel.  His e-mail address is <[EMAIL PROTECTED]>.

[PATCH 2.6.12 1/1] docs: updated some code docs

2005-07-26 Thread Xose Vazquez Perez 
Updated docs about how to write and submit patches/code.
diff -Nuar old/Documentation/CodingStyle new/Documentation/CodingStyle
--- old/Documentation/CodingStyle	2005-07-26 00:10:55.0 +0200
+++ new/Documentation/CodingStyle	2005-07-25 23:58:37.0 +0200
@@ -422,10 +422,13 @@
 URL: http://cm.bell-labs.com/cm/cs/tpop/
 
 GNU manuals - where in compliance with KR and this text - for cpp, gcc,
-gcc internals and indent, all available from http://www.gnu.org
+gcc internals and indent, all available from http://www.gnu.org/manual/
 
 WG14 is the international standardization working group for the programming
 language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/
 
+Kernel CodingStyle by [EMAIL PROTECTED] at OLS 2002:
+http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
+
 --
 Last updated on 16 February 2004 by a community effort on LKML.
diff -Nuar old/Documentation/SubmittingDrivers new/Documentation/SubmittingDrivers
--- old/Documentation/SubmittingDrivers	2005-07-26 00:11:01.0 +0200
+++ new/Documentation/SubmittingDrivers	2005-07-27 00:07:10.0 +0200
@@ -26,17 +26,17 @@
 
 
 Linux 2.0:
-	No new drivers are accepted for this kernel tree
+	No new drivers are accepted for this kernel tree.
 
 Linux 2.2:
+	No new drivers are accepted for this kernel tree.
+
+Linux 2.4:
 	If the code area has a general maintainer then please submit it to
 	the maintainer listed in MAINTAINERS in the kernel file. If the
 	maintainer does not respond or you cannot find the appropriate
-	maintainer then please contact Alan Cox [EMAIL PROTECTED]
-
-Linux 2.4:
-	The same rules apply as 2.2. The final contact point for Linux 2.4
-	submissions is Marcelo Tosatti [EMAIL PROTECTED].
+	maintainer then please contact Marcelo Tosatti
+	[EMAIL PROTECTED].
 
 Linux 2.6:
 	The same rules apply as 2.4 except that you should follow linux-kernel
@@ -51,6 +51,7 @@
 		of exclusively GPL licensing, and if you wish the driver
 		to be useful to other communities such as BSD you may well
 		wish to release under multiple licenses.
+		See accepted licenses at include/linux/module.h
 
 Copyright:	The copyright owner must agree to use of GPL.
 		It's best if the submitter and copyright owner
@@ -141,5 +142,13 @@
 	http://kernelnewbies.org/
 
 Linux USB project:
-	http://sourceforge.net/projects/linux-usb/
+	http://linux-usb.sourceforge.net/
+
+How to NOT write kernel driver by [EMAIL PROTECTED]
+	http://people.redhat.com/arjanv/olspaper.pdf
+
+Kernel Janitor:
+	http://janitor.kernelnewbies.org/
 
+--
+Last updated on 25 Jul 2005.
diff -Nuar old/Documentation/SubmittingPatches new/Documentation/SubmittingPatches
--- old/Documentation/SubmittingPatches	2005-07-26 00:11:01.0 +0200
+++ new/Documentation/SubmittingPatches	2005-07-27 00:03:56.0 +0200
@@ -35,7 +35,7 @@
 
 To create a patch for a single file, it is often sufficient to do:
 
-	SRCTREE= linux-2.4
+	SRCTREE= linux-2.6
 	MYFILE=  drivers/net/mydriver.c
 
 	cd $SRCTREE
@@ -48,9 +48,9 @@
 or unmodified kernel source tree, and generate a diff against your
 own source tree.  For example:
 
-	MYSRC= /devel/linux-2.4
+	MYSRC= /devel/linux-2.6
 
-	tar xvfz linux-2.4.0-test11.tar.gz
+	tar xvfz linux-2.6.0.tar.gz
 	mv linux linux-vanilla
 	wget http://www.moses.uklinux.net/patches/dontdiff
 	diff -uprN -X dontdiff linux-vanilla $MYSRC  /tmp/patch
@@ -77,7 +77,7 @@
 http://developer.osdl.org/rddunlap/scripts/patching-scripts.tgz
 
 Andrew Morton's patch scripts:
-http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16
+http://www.zip.com.au/~akpm/linux/patches/
 
 2) Describe your changes.
 
@@ -94,7 +94,7 @@
 
 3) Separate your changes.
 
-Separate each logical change into its own patch.
+Separate each _logical changes_ into its own patch.
 
 For example, if your changes include both bug fixes and performance
 enhancements for a single driver, separate those changes into two
@@ -102,13 +102,17 @@
 driver which uses that new API, separate those into two patches.
 
 On the other hand, if you make a single change to numerous files,
-group those changes into a single patch.  Thus a single logical change
-is contained within a single patch.
+group those changes into a single patch.  Thus single logical changes
+are contained within a single patch.
 
 If one patch depends on another patch in order for a change to be
 complete, that is OK.  Simply note this patch depends on patch X
 in your patch description.
 
+If you cannot condense your patch set into a smaller set of patches,
+then only post say 15 or so at a time and wait for review and integration.
+
+
 
 4) Select e-mail destination.
 
@@ -121,6 +125,8 @@
 [EMAIL PROTECTED]  Most kernel developers monitor this
 e-mail list, and can comment on your changes.
 
+Do not send more than 15 patches at once to the vger mailing lists!!!
+
 Linus Torvalds is the final arbiter of all changes accepted into the
 Linux kernel.  His e-mail address is [EMAIL PROTECTED].  He gets
 a