Re: perf script : wrong symoff in callchain

[Matthieu CASTET]

Le Tue, 3 Oct 2017 13:34:37 +0300,
Adrian Hunter  a écrit :

> On 03/10/17 13:19, Matthieu CASTET wrote:
> > Hi,
> > 
> > while using perf on x86_64, I saw strange output for symoff.
> > 
> > $ perf record -g -- sleep 1
> > $ perf script -F comm,tid,pid,time,ip,sym,dso,symoff
> > 
> > [...]
> > sleep 11656/11656 1045318.546436: 
> > 7fff9542e5b5 __d_lookup_rcu+0x80006ae02035 ([kernel.kallsyms])
> > 7fff9541e132 lookup_fast+0x80006ae02052 ([kernel.kallsyms])
> > 7fff9541eae8 walk_component+0x80006ae02048 ([kernel.kallsyms])
> > 7fff9541efa2 link_path_walk+0x80006ae021b2 ([kernel.kallsyms])
> > 7fff9541c92d path_init+0x80006ae021bd ([kernel.kallsyms])
> > 7fff9542100b path_openat+0x80006ae020fb ([kernel.kallsyms])
> > 7fff953c14fe handle_mm_fault+0x80006ae020ee ([kernel.kallsyms])
> > 7fff95423669 do_filp_open+0x80006ae02099 ([kernel.kallsyms])
> > 7fff95433414 __alloc_fd+0x80006ae02044 ([kernel.kallsyms])
> > 7fff9540ff6e do_sys_open+0x80006ae0212e ([kernel.kallsyms])
> > 7fff9540ff6e do_sys_open+0x80006ae0212e ([kernel.kallsyms])
> > 7fff95850abb system_call_fast_compare_end+0x80006ae0200c 
> > ([kernel.kallsyms])
> >2aecf _nl_load_locale_from_archive+0x014b5a92841f 
> > (/lib/x86_64-linux-gnu/libc-2.24.so)
> > 
> > 
> > I tried to revert a4eb24a49566db77ee999b46603f602a0302f481 and I got
> > good result :
> > [...]
> > sleep 11656/11656 1045318.546436: 
> > 7fff9542e5b5 __d_lookup_rcu+0x35 ([kernel.kallsyms])
> > 7fff9541e132 lookup_fast+0x52 ([kernel.kallsyms])
> > 7fff9541eae8 walk_component+0x48 ([kernel.kallsyms])
> > 7fff9541efa2 link_path_walk+0x1b2 ([kernel.kallsyms])
> > 7fff9541c92d path_init+0x1bd ([kernel.kallsyms])
> > 7fff9542100b path_openat+0xfb ([kernel.kallsyms])
> > 7fff953c14fe handle_mm_fault+0xee ([kernel.kallsyms])
> > 7fff95423669 do_filp_open+0x99 ([kernel.kallsyms])
> > 7fff95433414 __alloc_fd+0x44 ([kernel.kallsyms])
> > 7fff9540ff6e do_sys_open+0x12e ([kernel.kallsyms])
> > 7fff9540ff6e do_sys_open+0x12e ([kernel.kallsyms])
> > 7fff95850abb system_call_fast_compare_end+0xc 
> > ([kernel.kallsyms])
> >2aecf _nl_load_locale_from_archive+0x41f 
> > (/lib/x86_64-linux-gnu/libc-2.24.so)
> > 
> > 
> > Any idea ?  
> 
> It could be the problem with add_callchain_ip() described here:
> 
>   https://www.spinics.net/lists/linux-perf-users/msg03172.html

The db-export code removed the remapping [1]

So there a mix of mapping in callchain code :
- add_callchain_ip() store al.addr (ip remapped)
- fill_callchain_info do the translation (map_ip)
- sample__fprintf_callchain do the translation
- call_path_from_sample (db-export) don't do anymore the translation


So what should we do : 
- assume we store al.addr and remove mapping from all consumers ?
- store ip and do the mapping in consumers ?



[1]
commit 7a2544c004a6c576b1e307f30925b165affe6a22
Author: Chris Phlipot 
Date:   Tue May 10 20:26:48 2016 -0700

perf script: Fix callchain addresses in db-export

Remove the call to map_ip() to adjust al.addr, because it has already
been called when assembling the callchain, in:

  thread__resolve_callchain_sample(perf_sample)
  add_callchain_ip(ip = perf_sample->callchain->ips[j])
  thread__find_addr_location(addr = ip)
  thread__find_addr_map(addr) {
  al->addr = addr
  if (al->map)
  al->addr = al->map->map_ip(al->map, al->addr);
  }

Calling it a second time can result in incorrect addresses being used.
This can have effects such as duplicate symbols being created and
exported.

perf script : wrong symoff in callchain

[Matthieu CASTET]

Hi,

while using perf on x86_64, I saw strange output for symoff.

$ perf record -g -- sleep 1
$ perf script -F comm,tid,pid,time,ip,sym,dso,symoff

[...]
sleep 11656/11656 1045318.546436: 
7fff9542e5b5 __d_lookup_rcu+0x80006ae02035 ([kernel.kallsyms])
7fff9541e132 lookup_fast+0x80006ae02052 ([kernel.kallsyms])
7fff9541eae8 walk_component+0x80006ae02048 ([kernel.kallsyms])
7fff9541efa2 link_path_walk+0x80006ae021b2 ([kernel.kallsyms])
7fff9541c92d path_init+0x80006ae021bd ([kernel.kallsyms])
7fff9542100b path_openat+0x80006ae020fb ([kernel.kallsyms])
7fff953c14fe handle_mm_fault+0x80006ae020ee ([kernel.kallsyms])
7fff95423669 do_filp_open+0x80006ae02099 ([kernel.kallsyms])
7fff95433414 __alloc_fd+0x80006ae02044 ([kernel.kallsyms])
7fff9540ff6e do_sys_open+0x80006ae0212e ([kernel.kallsyms])
7fff9540ff6e do_sys_open+0x80006ae0212e ([kernel.kallsyms])
7fff95850abb system_call_fast_compare_end+0x80006ae0200c 
([kernel.kallsyms])
   2aecf _nl_load_locale_from_archive+0x014b5a92841f 
(/lib/x86_64-linux-gnu/libc-2.24.so)


I tried to revert a4eb24a49566db77ee999b46603f602a0302f481 and I got
good result :
[...]
sleep 11656/11656 1045318.546436: 
7fff9542e5b5 __d_lookup_rcu+0x35 ([kernel.kallsyms])
7fff9541e132 lookup_fast+0x52 ([kernel.kallsyms])
7fff9541eae8 walk_component+0x48 ([kernel.kallsyms])
7fff9541efa2 link_path_walk+0x1b2 ([kernel.kallsyms])
7fff9541c92d path_init+0x1bd ([kernel.kallsyms])
7fff9542100b path_openat+0xfb ([kernel.kallsyms])
7fff953c14fe handle_mm_fault+0xee ([kernel.kallsyms])
7fff95423669 do_filp_open+0x99 ([kernel.kallsyms])
7fff95433414 __alloc_fd+0x44 ([kernel.kallsyms])
7fff9540ff6e do_sys_open+0x12e ([kernel.kallsyms])
7fff9540ff6e do_sys_open+0x12e ([kernel.kallsyms])
7fff95850abb system_call_fast_compare_end+0xc ([kernel.kallsyms])
   2aecf _nl_load_locale_from_archive+0x41f 
(/lib/x86_64-linux-gnu/libc-2.24.so)


Any idea ?


Regards,

Matthieu

[PATCH] [DEV] dma mapping : export caller to vmallocinfo

[Matthieu CASTET]

For example on arm64 board, this add info to "user" entries in vmallocinfo

Before :
[...]
0xff8008997000 0xff80089d8000 266240 user
[...]

Afer :
[...]
0xff8008997000 0xff80089d8000 266240 atomic_pool_init+0x0/0x1d8 user
[...]

This help to debug mapping issues, and is consistent with others entries
(ioremap, vmalloc, ...) that already provide caller.

Signed-off-by: Matthieu CASTET 
---
 arch/arm64/mm/dma-mapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 614af886b7ef..115b32639a3c 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -166,7 +166,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
/* create a coherent mapping */
page = virt_to_page(ptr);
coherent_ptr = dma_common_contiguous_remap(page, size, VM_USERMAP,
-  prot, NULL);
+  prot, 
__builtin_return_address(0));
if (!coherent_ptr)
goto no_map;
 
-- 
2.14.2

futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

[Matthieu CASTET]

Hi,

the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.

It seems wrong to me, because in case of FUTEX_WAIT, in
"SYSCALL_DEFINE6(futex", we convert relative timeout to absolute
timeout [1].

So FUTEX_CLOCK_REALTIME | FUTEX_WAIT is expecting a relative timeout
when FUTEX_WAIT_BITSET take an absolute timeout.

To make it work you have to use something like the (untested) attached
patch.

Matthieu

[1]
if (cmd == FUTEX_WAIT)
t = ktime_add_safe(ktime_get(), t);diff --git a/kernel/futex.c b/kernel/futex.c
index 33664f7..4bee915 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3230,7 +3230,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
 			return -EINVAL;
 
 		t = timespec_to_ktime(ts);
-		if (cmd == FUTEX_WAIT)
+		if (cmd == FUTEX_WAIT && !(op & FUTEX_CLOCK_REALTIME))
 			t = ktime_add_safe(ktime_get(), t);
 		tp = &t;
 	}

Re: Buffer I/O error after s2ram with usb storage

[Matthieu CASTET]

Le Wed, 27 Aug 2014 10:54:53 -0400,
Alan Stern  a écrit :

> On Wed, 27 Aug 2014, Matthieu CASTET wrote:
> 
> > Ping
> > 
> > I have got also a problem with a usb sdcard reader (without power cut
> > during suspend)
> 
> > > > The usb storage driver call scsi_report_bus_reset after device reset,
> > > > but because of commit dfcf7775 <4>, we don't ignore unit attention if
> > > > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
> > > > 
> > > > If dfcf7775 is reverted there is no more Buffer I/O error.
> > > > 
> > > > Is that possible to find a way to restore the behavior before dfcf7775
> > > > commit (no Buffer I/O error after device reset) after a suspend to ram ?
> 
> Since that commit was written to fix a problem with certain cdrom
> drives, maybe we would work around the issue by modifying the commit.  
> Have it go back to the original behavior if the device isn't a cdrom 
> drive.
> 
> That's not a complete fix (it won't help when a CD drive is attached 
> via USB), but maybe it's better than nothing.
> 
Ok,

note to handle all case we need also to filter unit_attention in
scsi_test_unit_ready. Otherwise DISK_EVENT_MEDIA_CHANGE event is set and 
check_disk_change will invalidate vfs cache.


Matthieu

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2bc0362..e994061 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2030,8 +2030,12 @@ scsi_test_unit_ready(struct scsi_device *sdev, int 
timeout, int retries,
result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0, sshdr,
  timeout, retries, NULL);
if (sdev->removable && scsi_sense_valid(sshdr) &&
-   sshdr->sense_key == UNIT_ATTENTION)
-   sdev->changed = 1;
+   sshdr->sense_key == UNIT_ATTENTION) {
+   if (sdev->expecting_cc_ua)
+   sdev->expecting_cc_ua = 0;
+   else
+   sdev->changed = 1;
+   }
} while (scsi_sense_valid(sshdr) &&
 sshdr->sense_key == UNIT_ATTENTION && --retries);
 
--
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: Buffer I/O error after s2ram with usb storage

[Matthieu CASTET]

Ping

I have got also a problem with a usb sdcard reader (without power cut
during suspend)

[ 1073.606668] PM: Entering mem sleep
[ 1073.606742] Suspending console(s) (use no_console_suspend to debug)
[ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 1073.639076] sd 1:0:0:0: [sda] Stopping disk
[ 1074.186688] PM: suspend of devices complete after 580.127 msecs
[...]
[ 1075.265183] PM: resume of devices complete after 615.990 msecs
[ 1075.265627] PM: Finishing wakeup.
[ 1075.265630] Restarting tasks ... 
[...]
[ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. 
[ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). 
There's a risk of filesystem corruption in case of system crash.
[ 1204.141482] sd 8:0:0:0: [sdb] Media Changed
[ 1204.141490] sd 8:0:0:0: [sdb]
[ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1204.141497] sd 8:0:0:0: [sdb]
[ 1204.141499] Sense Key : Unit Attention [current]
[ 1204.141504] Info fld=0x0
[ 1204.141506] sd 8:0:0:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed
[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560



Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET  a écrit :

> Hi,
> 
> any news on this.
> 
> Matthieu CASTET
> 
> Le Tue, 22 Apr 2014 16:01:15 +0200,
> Matthieu CASTET  a écrit :
> 
> > Hi,
> > 
> > while playing with suspend to ram I found a strange behavior with usb
> > key.
> > 
> > This can be easily reproduced by doing :
> > - plug a usb key
> > - start to read the usb key : "cat /dev/sdx > /dev/null"
> > - go to suspend : "echo mem > /sys/power/state"
> > - while in suspend, unplug and replug the usb key (simulate usb power
> > loss for computer that keep power)
> > - exit suspend
> > - there is read error on the usb key
> > 
> > 
> > Because the power was cut during s2ram, the usb stack reset the device
> > <1>.
> > When new data transfer are done, we got a UNIT_ATTENTION from the
> > device <2> and IO error are returned to user space application.
> > 
> > After some investigation it seems some (all on the 3 I tested) usb key
> > report as removable, and scsi layer abort the transfer in case of
> > UNIT_ATTENTION <3>.
> > 
> > The usb storage driver call scsi_report_bus_reset after device reset,
> > but because of commit dfcf7775 <4>, we don't ignore unit attention if
> > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
> > 
> > If dfcf7775 is reverted there is no more Buffer I/O error.
> > 
> > Is that possible to find a way to restore the behavior before dfcf7775
> > commit (no Buffer I/O error after device reset) after a suspend to ram ?
> > 
> > 
> > Matthieu CASTET
> > 
> > PS : the same error happen if sg_reset -b /dev/sdx is used on the
> > device.
> > 
> > 
> > <1>
> > [  117.070255] usb 2-1.4: reset high-speed USB device number 3 using
> > ehci-pci [...]
> > [  117.543922] Restarting tasks ... done.
> > [  117.548390] video LNXVIDEO:01: Restoring backlight state
> > <2>
> > [  117.549179] sd 6:0:0:0: [sdb] Media Changed
> > [  117.549184] sd 6:0:0:0: [sdb]  
> > [  117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > [  117.549189] sd 6:0:0:0: [sdb]  
> > [  117.549191] Sense Key : Unit Attention [current] 
> > [  117.549195] Info fld=0x0
> > [  117.549197] sd 6:0:0:0: [sdb]  
> > [  117.549201] Add. Sense: Not ready to ready change, medium may have
> > changed [  117.549203] sd 6:0:0:0: [sdb] CDB: 
> > [  117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
> > [  117.549212] end_request: I/O error, dev sdb, sector 182528
> > [  117.549218] Buffer I/O error on device sdb1, logical block 2

Re: perf on biarch

[Matthieu CASTET]

Le Fri, 8 Aug 2014 13:50:52 -0600,
David Ahern  a écrit :

> On 8/8/14, 10:40 AM, Matthieu CASTET wrote:
> > Hi,
> >
> > I have a 64 bits kernel running with 32 bits binaries.
> > If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :
> >
> > - perf trace doesn't work [1]
> 
> I have patches that fix that:
>  git clone https://github.com/dsahern/linux.git
>  git checkout perf-full-monty
> 
> And if autodetection fails you can manually force it with -M x86.
> 
Thanks david. 
It is better, but it seems there are problem with argument parsing.

For example for 
"mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xf77e2000"
I got :
- 2.847 ( 0.004 ms): mmap2(arg0: 0, arg1: 0, arg2: 4096, arg3: 0, arg4:
3, arg5: 0 ) = -143273984


Note the 4096 position. Running perf trace on a 32 bits kernel give
4096 at arg1.


Matthieu
--
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/

perf on biarch

[Matthieu CASTET]

Hi,

I have a 64 bits kernel running with 32 bits binaries.
If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :

- perf trace doesn't work [1]
- perf record with dwarf call-graph doesn't work [2]


Matthieu


[1]
$ sudo perf trace ls
 0.009 ( 0.000 ms):  ... [continued]: close()) = 1
 0.040 ( 0.000 ms):  ... [continued]: munmap()) = -1 ENOENT No such file or 
directory
 0.046 ( 0.005 ms): munmap(arg0: -2632121, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = -1 ENOENT No such file or directory
 0.052 ( 0.004 ms): munmap(arg0: -2632120, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = -1 ENOENT No such file or directory
 0.058 ( 0.004 ms): munmap(arg0: -2632115, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = -1 ENOENT No such file or directory
 0.064 ( 0.004 ms): munmap(arg0: -2632114, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = -1 ENOENT No such file or directory
 0.069 ( 0.004 ms): munmap(arg0: -2632111, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = -1 ENOENT No such file or directory
 4.570 ( 4.498 ms): munmap(arg0: -2632110, arg1: 0, arg2: -2621656, arg3: 
0, arg4: 159334824, arg5: 0) = 0
 4.603 ( 4.532 ms):  ... [continued]: recvfrom()) = 145719296
 4.635 ( 4.564 ms):  ... [continued]: dup2()) = -1 ENOENT No such file or 
directory
 4.643 ( 4.572 ms):  ... [continued]: lgetxattr()) = -143216640
 4.658 ( 0.004 ms): dup2(arg0: 1303966526, arg1: 0, arg2: 4, arg3: 0, arg4: 
1303994368, arg5: 0) = -1 ENOENT No such file or directory
 4.678 ( 0.023 ms):  ... [continued]: fstat()) = 3
 4.682 ( 0.028 ms):  ... [continued]: removexattr()) = 0
 4.689 ( 0.005 ms): lgetxattr(arg0: 0, arg1: 0, arg2: 164475, arg3: 0, 
arg4: 1, arg5: 0   ) = -143384576
 4.693 ( 0.009 ms):  ... [continued]: lstat()) = 0
 4.702 ( 0.003 ms): dup2(arg0: 1303967744, arg1: 0, arg2: 0, arg3: 0, arg4: 
1303994368, arg5: 0) = -1 ENOENT No such file or directory
 4.721 ( 0.005 ms): fstat(arg0: -143294523, arg1: 0, arg2: 524288, arg3: 0, 
arg4: 0, arg5: 0) = 3
 4.725 ( 0.003 ms): close(arg0: 3, arg1: 0, arg2: -4714640, arg3: 0, arg4: 
512, arg5: 0   ) = 512
 4.736 ( 0.002 ms): removexattr(arg0: 3, arg1: 0, arg2: -4714864, arg3: 0, 
arg4: 1303994368, arg5: 0) = 0
 4.747 ( 0.006 ms): lgetxattr(arg0: 1096056832, arg1: 0, arg2: 142540, 
arg3: 0, arg4: 5, arg5: 0) = 1096056832
 4.760 ( 0.010 ms): lgetxattr(arg0: 1096187904, arg1: 0, arg2: 8192, arg3: 
0, arg4: 3, arg5: 0) = 1096187904
 4.777 ( 0.005 ms): lgetxattr(arg0: 1096196096, arg1: 0, arg2: 3276, arg3: 
0, arg4: 3, arg5: 0) = 1096196096
 4.783 ( 0.002 ms): lstat(arg0: 3, arg1: 0, arg2: 10, arg3: 0, arg4: 
1303994368, arg5: 0  ) = 0
 4.794 ( 0.003 ms): dup2(arg0: 1303967744, arg1: 0, arg2: 0, arg3: 0, arg4: 
1303994368, arg5: 0) = -1 ENOENT No such file or directory
 4.813 ( 0.007 ms): fstat(arg0: -143227586, arg1: 0, arg2: 524288, arg3: 0, 
arg4: 0, arg5: 0) = 3
 4.817 ( 0.003 ms): close(arg0: 3, arg1: 0, arg2: -4714672, arg3: 0, arg4: 
512, arg5: 0   ) = 512
 4.822 ( 0.002 ms): removexattr(arg0: 3, arg1: 0, arg2: -4714896, arg3: 0, 
arg4: 1303994368, arg5: 0) = 0
 4.830 ( 0.005 ms): lgetxattr(arg0: 1325760512, arg1: 0, arg2: 33148, arg3: 
0, arg4: 5, arg5: 0) = 1325760512
 4.839 ( 0.006 ms): lgetxattr(arg0: 1325789184, arg1: 0, arg2: 8192, arg3: 
0, arg4: 3, arg5: 0) = 1325789184
 4.851 ( 0.002 ms): lstat(arg0: 3, arg1: 0, arg2: 10, arg3: 0, arg4: 
1303994368, arg5: 0  ) = 0
 4.859 ( 0.003 ms): dup2(arg0: 1303967744, arg1: 0, arg2: 0, arg3: 0, arg4: 
1303994368, arg5: 0) = -1 ENOENT No such file or directory
 4.872 ( 0.007 ms): fstat(arg0: -143237622, arg1: 0, arg2: 524288, arg3: 0, 
arg4: 0, arg5: 0) = 3
 4.876 ( 0.003 ms): close(arg0: 3, arg1: 0, arg2: -4714704, arg3: 0, arg4: 
512, arg5: 0   ) = 512
 4.881 ( 0.002 ms): removexattr(arg0: 3, arg1: 0, arg2: -4714928, arg3: 0, 
arg4: 1303994368, arg5: 0) = 0
 4.887 ( 0.004 ms): lgetxattr(arg0: 0, arg1: 0, arg2: 4096, arg3: 0, arg4: 
3, arg5: 0 ) = -143388672
 4.899 ( 0.006 ms): lgetxattr(arg0: 1304006656, arg1: 0, arg2: 1747580, 
arg3: 0, arg4: 5, arg5: 0) = 1304006656
 4.911 ( 0.010 ms): lgetxattr(arg0: 1305731072, arg1: 0, arg2: 12288, arg3: 
0, arg4: 3, arg5: 0) = 1305731072
 4.927 ( 0.006 ms): lgetxattr(arg0: 1305743360, arg1: 0, arg2: 10876, arg3: 
0, arg4: 3, arg5: 0) = 1305743360
 4.933 ( 0.002 ms): lstat(arg0: 3, arg1: 0, arg2: 10, arg3: 0, arg4: 
1303994368, arg5: 0  ) = 0
 4.943 ( 0.003 ms): dup2(arg0: 1303967744, arg1: 0, arg2: 0, arg3: 0, arg4: 
1303994368, arg5: 0) = -1 ENOENT No such file or directory
 4.959 ( 0.006 ms): fstat(arg0: -143285411, arg1: 0, arg2: 524288, arg3: 0, 
arg4: 0, arg5: 0) = 3
 6.218 ( 1.251 ms): close(arg0: 3, arg1: 0, arg2: -4714880, arg3: 0, arg4: 
512, arg5: 0   ) = 512
 6.229 ( 0.003 ms): removexattr(arg0: 3, arg1: 0, arg2: -47

Re: [PATCH 1/2] mtd: nand: define struct nand_timings

[Matthieu CASTET]

Hi Boris,

Le Tue, 22 Jul 2014 14:12:19 +0200,
Boris BREZILLON  a écrit :

> Hi Matthieu
> 
> On Tue, 22 Jul 2014 12:03:46 +0200
> Matthieu CASTET  wrote:
> 
> > Hi,
> > 
> > 

> > 
> > I did a similar patch [1] (that wasn't merged :( ), and I used reduced
> > timing info.
> 
> I'm sorry it didn't make it to mainline, do you know why ?
For the omap part there was a gpmc code rewrite that conflict with the
patch.
For the mtd stuff, I don't know/remember (I think for was no reply).

> Could you point out where "reduced timing info" is defined in the ONFI
> specification ?
It is not defined on onfi.
This was more a simplification of timings in order to simplify the
driver side (avoid code duplication). Most controller allow to control
nRE and nWE pulse and the setup time.

Do you have drivers that use onfi timings ?
> 
> > 
> > I also have support for the omap driver
> > (http://article.gmane.org/gmane.linux.ports.arm.omap/88606/match=) and
> > a controller we use in our chip (not upstream).
> 
> It should be pretty easy to convert the full timings list into a
> reduced one (actually, that's what your patch is doing), and you can
> thus port your work on top of these patches.
Yes I think an helper will be useful in order to help driver to use
these timings.
It can be a function that return the reduced version for a onfi mode
and edo support.

> 
> Anyway, I'm not sure what you have in mind, but unless there is a strong
> reason to drop full timings in favor of reduced ones I'd like to
> keep them (even if this implies adding a new converter to get reduced
> timings list).
> 
No problem. I have nothing special in mind. I hope this could give ideas
how to use the onfi timings in mtd drivers (understanding how to use
ONFI timings can be tricky).


Matthieu
--
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 1/2] mtd: nand: define struct nand_timings

[Matthieu CASTET]

Hi,


Do you know if all these timings will be used by the nand drivers ?

I did a similar patch [1] (that wasn't merged :( ), and I used reduced
timing info.

I also have support for the omap driver
(http://article.gmane.org/gmane.linux.ports.arm.omap/88606/match=) and
a controller we use in our chip (not upstream).

Matthieu

[1]
[PATCH 2/3] mtd nand : get timings from onfi

We get from onfi param the max speed supported by the chip.
A precomputed table for ONFI timings is generated.

Signed-off-by: Matthieu CASTET 
---
 drivers/mtd/nand/Makefile  |2 +-
 drivers/mtd/nand/nand_base.c   |1 +
 drivers/mtd/nand/nand_timing.c |  170 
 include/linux/mtd/nand.h   |   56 +
 4 files changed, 228 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/nand_timing.c

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 2cbd091..2fc1a99 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -54,4 +54,4 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
 obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
 
-nand-objs := nand_base.o nand_bbt.o
+nand-objs := nand_base.o nand_bbt.o nand_timing.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 8916bc6..0d6bd88 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3238,6 +3238,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (*maf_id != NAND_MFR_SAMSUNG && !type->pagesize)
chip->options &= ~NAND_SAMSUNG_LP_OPTIONS;
 ident_done:
+   nand_select_speed(chip, *maf_id, *dev_id);
 
/* Try to identify manufacturer */
for (maf_idx = 0; nand_manuf_ids[maf_idx].id != 0x0; maf_idx++) {
diff --git a/drivers/mtd/nand/nand_timing.c b/drivers/mtd/nand/nand_timing.c
new file mode 100644
index 000..7211c9c
--- /dev/null
+++ b/drivers/mtd/nand/nand_timing.c
@@ -0,0 +1,170 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * this table is precomputed from onfi timings with the following program
+ */
+#if 0
+int print_timing(const struct onfi_timings *timings, int edo_off)
+{
+   struct reduced_onfi t;
+   int tmp;
+   int edo = timings->tRC < 30 && !edo_off;
+
+   /* nWE low */
+   t.twp = max(timings->tWP, timings->tDS);
+
+   /* nCS low to nWE low */
+   tmp = max(timings->tCLS, timings->tCS);
+   tmp = max(tmp, timings->tALS);
+   t.twsetup = tmp - t.twp;
+   assert(t.twsetup >= 0);
+
+   /* nWE high */
+   tmp = max(timings->tWH, timings->tDH); /* nWE high & data hold */
+   tmp = max(tmp, timings->tCH); /* cs hold */
+   tmp = max(tmp, timings->tCLH); /* cmd hold */
+   t.twh = max(tmp, timings->tALH); /* addr hold */
+
+   assert(t.twp + t.twh <= timings->tWC);
+   t.twc = timings->tWC;
+
+   t.edo = edo;
+   if (edo == 0) {
+
+   /* nRE low */
+   t.trp = max(timings->tRP, timings->tREA);
+
+   /* nRE high */
+   t.treh = timings->tREH;
+   t.trc = max(timings->tRC, t.trp + t.treh);
+   }
+   else {
+   /* nRE low */
+   t.trp = timings->tRP;
+
+   /* nRE high */
+   t.treh = timings->tREH;
+
+   t.trc = max(timings->tRC, timings->tREA);
+   }
+
+   /* nCS low to nRE low */
+   t.trsetup = max(timings->tCEA - timings->tREA, timings->tCLR);
+
+   /* Min time from rdn rising edge to output hi-Z */
+   t.bta = timings->tRHZ;
+
+   /* Min time from busy rising edge and rdn falling edge (read).*/
+   t.tbusy = timings->tRR;
+
+   /* Min time from wrn rising edge to rdn falling edge. */
+   t.twhr = timings->tWHR;
+   assert(t.twhr >= 0);
+
+   t.tceh = 0;
+
+   printf("{\n");
+   printf("/* %s edo=%d */\n", timings->name, t.edo);
+   printf(".twp = %3d,  .twh = %3d, .twc = %3d, .twsetup = %d,\n",
+   t.twp, t.twh, t.twc, t.twsetup);
+   printf(".trp = %3d,  .treh = %3d, .trc = %3d, .trsetup = %d,\n",
+   t.trp, t.treh, t.trc, t.trsetup);
+   printf(".twhr = %d, .tceh = %d,  .bta = %d, .tbusy = %d, .edo = %d,\n",
+   t.twhr, t.tceh, t.bta, t.tbusy, t.edo);
+   printf("},\n");
+#endif
+
+static struct reduced_onfi nand_timing[] =
+{
+   {
+   /* onfi mode 0 edo=0 */
+   .twp =  50,  .twh =  30, .twc = 100, .twsetup = 20,
+

Re: Buffer I/O error after s2ram with usb storage

[Matthieu CASTET]

Hi,

any news on this.

Matthieu CASTET

Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET  a écrit :

> Hi,
> 
> while playing with suspend to ram I found a strange behavior with usb
> key.
> 
> This can be easily reproduced by doing :
> - plug a usb key
> - start to read the usb key : "cat /dev/sdx > /dev/null"
> - go to suspend : "echo mem > /sys/power/state"
> - while in suspend, unplug and replug the usb key (simulate usb power
> loss for computer that keep power)
> - exit suspend
> - there is read error on the usb key
> 
> 
> Because the power was cut during s2ram, the usb stack reset the device
> <1>.
> When new data transfer are done, we got a UNIT_ATTENTION from the
> device <2> and IO error are returned to user space application.
> 
> After some investigation it seems some (all on the 3 I tested) usb key
> report as removable, and scsi layer abort the transfer in case of
> UNIT_ATTENTION <3>.
> 
> The usb storage driver call scsi_report_bus_reset after device reset,
> but because of commit dfcf7775 <4>, we don't ignore unit attention if
> "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
> 
> If dfcf7775 is reverted there is no more Buffer I/O error.
> 
> Is that possible to find a way to restore the behavior before dfcf7775
> commit (no Buffer I/O error after device reset) after a suspend to ram ?
> 
> 
> Matthieu CASTET
> 
> PS : the same error happen if sg_reset -b /dev/sdx is used on the
> device.
> 
> 
> <1>
> [  117.070255] usb 2-1.4: reset high-speed USB device number 3 using
> ehci-pci [...]
> [  117.543922] Restarting tasks ... done.
> [  117.548390] video LNXVIDEO:01: Restoring backlight state
> <2>
> [  117.549179] sd 6:0:0:0: [sdb] Media Changed
> [  117.549184] sd 6:0:0:0: [sdb]  
> [  117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [  117.549189] sd 6:0:0:0: [sdb]  
> [  117.549191] Sense Key : Unit Attention [current] 
> [  117.549195] Info fld=0x0
> [  117.549197] sd 6:0:0:0: [sdb]  
> [  117.549201] Add. Sense: Not ready to ready change, medium may have
> changed [  117.549203] sd 6:0:0:0: [sdb] CDB: 
> [  117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
> [  117.549212] end_request: I/O error, dev sdb, sector 182528
> [  117.549218] Buffer I/O error on device sdb1, logical block 22560
> [  117.549225] Buffer I/O error on device sdb1, logical block 22561
> [  117.549228] Buffer I/O error on device sdb1, logical block 22562
> [  117.549231] Buffer I/O error on device sdb1, logical block 22563
> [  117.549233] Buffer I/O error on device sdb1, logical block 22564
> [  117.549235] Buffer I/O error on device sdb1, logical block 22565
> [  117.549238] Buffer I/O error on device sdb1, logical block 22566
> [  117.549240] Buffer I/O error on device sdb1, logical block 22567
> [  117.549243] Buffer I/O error on device sdb1, logical block 22568
> [  117.549245] Buffer I/O error on device sdb1, logical block 22569
> [  117.809462] sd 6:0:0:0: [sdb] No Caching mode page found
> [  117.809470] sd 6:0:0:0: [sdb] Assuming drive cache: write through
> [  117.812696] sd 6:0:0:0: [sdb] No Caching mode page found
> [  117.812703] sd 6:0:0:0: [sdb] Assuming drive cache: write through
> [  117.813688]  sdb: sdb1
> 
> 
> <3>
> case UNIT_ATTENTION:
> if (cmd->device->removable) {
> /* Detected disc change.  Set a bit
>  * and quietly refuse further access.
>  */
> cmd->device->changed = 1;
> description = "Media Changed";
> action = ACTION_FAIL;
> } else {
> /* Must have been a power glitch, or a
>  * bus reset.  Could not have been a
>  * media change, so we just retry the
>  * command and see what happens.
>  */
> action = ACTION_RETRY;
> }
> 
> <4>
> commit dfcf7775815504d13a1d273073810058caf84b9d
> Author: TARUISI Hiroaki 
> Date:   Thu Aug 11 20:25:20 2011 +0900
> 
> [SCSI] Fix out of spec CD-ROM problem with media change
> 
> Some CD-ROMs fail to report a media change correctly.  The specific
> one for this patch simply fails to respond to commands, then gives a
> UNIT ATTENTION after being reset which returns ASC/ASCQ 28/00.  This
> is out of spec behaviour, but add a check in the eat CC/UA on reset
> path to catch this case so the CD-ROM will function somewhat properly.
> 
> [jejb: fixed up white space and accepted without signoff]
> 

Re: [PATCH 0/6] bug fix for mv_udc_core.c

[Matthieu CASTET]

Le Mon, 24 Feb 2014 16:03:10 +0800,
Neil Zhang  a écrit :

> This patch set is mainly for bug fix.
> 
> Neil Zhang (6):
>   usb: gadget: mv_udc: remove redundant pull up in udc_start
>   usb: gadget: mv_udc: disable HW zlt for ep0
>   usb: gadget: mv_udc: clear corresponding interrupt when flush fifo
>   usb: gadget: mv_udc: check endpoint before queue dtd
>   USB: gadget: mv_udc: workaroud for missing dTD
>   USB: gadget: mv_udc: fix corner case for missiong dTD
> 
>  drivers/usb/gadget/mv_udc_core.c |   47 
> ++
>  1 file changed, 42 insertions(+), 5 deletions(-)
> 

Do you have plan to move to the chipidea udc driver ?

You could have some bug fix for free or share your bug fix with others.


Matthieu
--
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 1/6] usb: host: add has_tdi_phy_lpm capability bit

[Matthieu CASTET]

Hi,

Le Wed, 31 Jul 2013 18:41:57 +0100,
Tuomas Tynkkynen  a écrit :

> The has_hostpc capability bit indicates that the host controller has
> the HOSTPC register extensions, but at the same time enables clock
> disabling power saving features with the PHY Low Power Clock Disable
> (PHCD) bit.
> 
> However, some host controllers have the HOSTPC extensions but don't
> support the low-power feature, so the PHCD bit must not be set on
> those controllers. Add a separate capability bit for the low-power
> feature instead, and change all existing users of has_hostpc to use
> this new capability bit.
> 
> The idea for this commit is taken from an old 2012 commit that never
> got merged ("disociate chipidea PHY low power suspend control from
> hostpc")
Note that because of the different register layout (see "add phy low
power suspend for older chipidea core" commit in the same series), we
should not set has_tdi_phy_lpm if has_hostpc == 0 with the current code.

May be you should have change the ehci->has_hostpc to (ehci->has_hostpc
&& ehci->has_tdi_phy_lpm).

BTW Alan make some comment on the commit :
http://marc.info/?l=linux-usb&m=133701342028213&w=2

They may apply to your commit.

> 
> Inspired-by: Matthieu CASTET 
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/usb/chipidea/host.c |  1 +
>  drivers/usb/host/ehci-hub.c | 14 +++---
>  drivers/usb/host/ehci.h |  1 +
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index 40d0fda..9b3aaf1 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -63,6 +63,7 @@ static int host_start(struct ci_hdrc *ci)
>   ehci = hcd_to_ehci(hcd);
>   ehci->caps = ci->hw_bank.cap;
>   ehci->has_hostpc = ci->hw_bank.lpm;
> + ehci->has_tdi_phy_lpm = ci->hw_bank.lpm;
>  
>   ret = usb_add_hcd(hcd, 0, 0);
>   if (ret)
> diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
> index 2b70277..8044a74 100644
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -183,7 +183,7 @@ static void ehci_adjust_port_wakeup_flags(struct
> ehci_hcd *ehci, spin_lock_irq(&ehci->lock);
>  
>   /* clear phy low-power mode before changing wakeup flags */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   port = HCS_N_PORTS(ehci->hcs_params);
>   while (port--) {
>   u32 __iomem *hostpc_reg =
> &ehci->regs->hostpc[port]; @@ -217,7 +217,7 @@ static void
> ehci_adjust_port_wakeup_flags(struct ehci_hcd *ehci, }
>  
>   /* enter phy low-power mode again */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   port = HCS_N_PORTS(ehci->hcs_params);
>   while (port--) {
>   u32 __iomem *hostpc_reg =
> &ehci->regs->hostpc[port]; @@ -309,7 +309,7 @@ static int
> ehci_bus_suspend (struct usb_hcd *hcd) }
>   }
>  
> - if (changed && ehci->has_hostpc) {
> + if (changed && ehci->has_tdi_phy_lpm) {
>   spin_unlock_irq(&ehci->lock);
>   msleep(5);  /* 5 ms for HCD to enter low-power
> mode */ spin_lock_irq(&ehci->lock);
> @@ -435,7 +435,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
>   goto shutdown;
>  
>   /* clear phy low-power mode before resume */
> - if (ehci->bus_suspended && ehci->has_hostpc) {
> + if (ehci->bus_suspended && ehci->has_tdi_phy_lpm) {
>   i = HCS_N_PORTS(ehci->hcs_params);
>   while (i--) {
>   if (test_bit(i, &ehci->bus_suspended)) {
> @@ -788,7 +788,7 @@ static int ehci_hub_control (
>   goto error;
>  
>   /* clear phy low-power mode before resume */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   temp1 = ehci_readl(ehci, hostpc_reg);
>   ehci_writel(ehci, temp1 &
> ~HOSTPC_PHCD, hostpc_reg);
> @@ -1031,12 +1031,12 @@ static int ehci_hub_control (
>  
>   /* After above check the port must be
> connected.
>* Set appropriate bit thus could put phy
> into low power
> -  * mode if we have hostpc feature
> +  * mode if we have tdi_phy_lpm feature
>*/
>   temp &= ~PORT_WKCONN_E;
> 

Re : A bug about system call on ARM

[Matthieu CASTET]

Hello,

> Hi  all,
> 
> I am a new comer to this mailing list ,
> I am happy to join this community .
> 

You should send this to arm ML.

Also I believe most of people don't enable CONFIG_OABI_COMPAT, that's why they
don't hit the bug.


Matthieu


> I have a bug reported from our android phones which is caused by  the system 
> call .
> It seems like kernel bugs from my view .
> 
> Crash in  file  arch\arm\kernel\ entry-common.S
> 
> /***/
> 
> ENTRY(vector_swi)
>   sub sp, sp, #S_FRAME_SIZE
>   stmia   sp, {r0 - r12}  @ Calling r0 - r12
>  ARM( add r8, sp, #S_PC   )
>  ARM( stmdb   r8, {sp, lr}^   )   @ Calling sp, lr
>  THUMB(   mov r8, sp  )
>  THUMB(   store_user_sp_lr r8, r10, S_SP  )   @ calling sp, lr
>   mrs r8, spsr@ called from non-FIQ mode, so 
> ok.
>   str lr, [sp, #S_PC] @ Save calling PC
>   str r8, [sp, #S_PSR]@ Save CPSR
>   str r0, [sp, #S_OLD_R0] @ Save OLD_R0
>   zero_fp
> 
>   /*
>* Get the system call number.
>*/
> 
> #if defined(CONFIG_OABI_COMPAT)
> 
>   /*
>* If we have CONFIG_OABI_COMPAT then we need to look at the swi
>* value to determine if it is an EABI or an old ABI call.
>*/
> #ifdef CONFIG_ARM_THUMB
>   tst r8, #PSR_T_BIT
>   movne   r10, #0 @ no thumb OABI emulation
>   ldreq   r10, [lr, #-4]  @ get SWI instruction  
> // crash at this instruction, \
> when get SWI instruction #else
>   ldr r10, [lr, #-4]  @ get SWI instruction
>   A710(   and ip, r10, #0x0f00@ check for SWI 
> )
>   A710(   teq ip, #0x0f00 
> )
>   A710(   bne .Larm710bug 
> )
> #endif
> #ifdef CONFIG_CPU_ENDIAN_BE8
>   rev r10, r10@ little endian instruction
> #endif
> 
> /*
>  \
> **/
> 
> Then reason why it will crash when get SWI instruction is maybe 
> This page is clear to aged by kernel,
> But this MMU fault happpened in kernel,
> So the kernel do_page_fault function will not clear this page to young,
> So that  will crash .
> 
> It should poll this page to make it present or the fault should be handled by 
> fixup \
> section , Anyway, this place should not crash by kernel .
> 
> The kernel version I used  is  3.4.0
> I have add the kernel log and the call stack recovered  by trace32 tools 
> Pls have a look at it .
> 
> 
--
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] binfmt_elf: fix return value in case of interpreter load failure

[Matthieu CASTET]

Hi Andrew,

thanks for your quick review.

Andrew Morton a écrit :
> On Thu, 11 Apr 2013 15:53:09 +0200 Matthieu CASTET 
>  wrote:
> 
>> The current code return the address instead of using PTR_ERR.
> 
> I don't understand what you mean here - please describe this error in
> much more detail.  Help people to identify the section of code which
> is being discussed.

I was speaking of


 elf_entry = load_elf_interp(&loc->interp_elf_ex,
interpreter,
&interp_map_addr,
load_bias);
[...]
if (BAD_ADDR(elf_entry)) {
force_sig(SIGSEGV, current);
retval = IS_ERR((void *)elf_entry) ?
(int)elf_entry : -EINVAL;
goto out_free_dentry;
}

and was expecting we should use PTR_ERR when IS_ERR is true to match what is
done in [1].

But didn't saw that PTR_ERR((void *)elf_entry) and (int)elf_entry are 
equivalent.

> 
>> Also the check is done after adding e_entry. This can cause weird behaviour
>> because -errno + loc->interp_elf_ex.e_entry can produce a valid address.
> 
> Which check?

I am really confused here. Reading again the code this can't happen because if
load_elf_interp return -errno


We don't enter this condition
> if (!IS_ERR((void *)elf_entry)) {
> /*
>  * load_elf_interp() returns relocation
>  * adjustment
>  */
> interp_load_addr = elf_entry;
> elf_entry += loc->interp_elf_ex.e_entry;
> }
we still have -errno here
> if (BAD_ADDR(elf_entry)) {
> force_sig(SIGSEGV, current);
> retval = IS_ERR((void *)elf_entry) ?
> (int)elf_entry : -EINVAL;
> goto out_free_dentry;
> }


Sorry for my mistake.

The only valid remaining part of my patch is to return SIGKILL when
load_elf_interp fail (IS_ERR((void *)elf_entry) is true) (for example load
address of linker is bad) instead of SIGSEGV. This will follow what is done when
loading binary.

But is it even worth doing?


> 
>> Add a check to test load error before adding entry address. Also in this
>> case send SIGKILL instead of SIGSEGV to match what is done when loading 
>> binary.
>>
>> ...
>>
>> --- a/fs/binfmt_elf.c
>> +++ b/fs/binfmt_elf.c
>> @@ -900,18 +900,21 @@ static int load_elf_binary(struct linux_binprm *bprm)
>>  interpreter,
>>  &interp_map_addr,
>>  load_bias);
>> -if (!IS_ERR((void *)elf_entry)) {
>> -/*
>> - * load_elf_interp() returns relocation
>> - * adjustment
>> - */
>> -interp_load_addr = elf_entry;
>> -elf_entry += loc->interp_elf_ex.e_entry;
>> +if (BAD_ADDR(elf_entry)) {
>> +force_sig(SIGKILL, current);
>> +retval = IS_ERR((void *)elf_entry) ?
>> +PTR_ERR((void *)elf_entry) : -EINVAL;
> 
> Thats's a bit verbose - "PTR_ERR((void *)elf_entry)" is equivalent to
> "elf_entry".  I suppose we can do it this way to document the intent or
> something.
Ok, I see.
Note that [1] use PTR_ERR but elf_map already return unsigned long like
load_elf_interp.



Matthieu



[1]
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
elf_prot, elf_flags, 0);
if (BAD_ADDR(error)) {
send_sig(SIGKILL, current, 0);
retval = IS_ERR((void *)error) ?
PTR_ERR((void*)error) : -EINVAL;
goto out_free_dentry;
}
--
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] binfmt_elf: fix return value in case of interpreter load failure

[Matthieu CASTET]

The current code return the address instead of using PTR_ERR.

Also the check is done after adding e_entry. This can cause weird behaviour
because -errno + loc->interp_elf_ex.e_entry can produce a valid address.

Add a check to test load error before adding entry address. Also in this
case send SIGKILL instead of SIGSEGV to match what is done when loading binary.

Signed-off-by: Matthieu CASTET 
Cc: Al Viro 
Cc: Andrew Morton 
---
 fs/binfmt_elf.c |   21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..8397f80 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -900,18 +900,21 @@ static int load_elf_binary(struct linux_binprm *bprm)
interpreter,
&interp_map_addr,
load_bias);
-   if (!IS_ERR((void *)elf_entry)) {
-   /*
-* load_elf_interp() returns relocation
-* adjustment
-*/
-   interp_load_addr = elf_entry;
-   elf_entry += loc->interp_elf_ex.e_entry;
+   if (BAD_ADDR(elf_entry)) {
+   force_sig(SIGKILL, current);
+   retval = IS_ERR((void *)elf_entry) ?
+   PTR_ERR((void *)elf_entry) : -EINVAL;
+   goto out_free_dentry;
}
+   /*
+* load_elf_interp() returns relocation
+* adjustment
+*/
+   interp_load_addr = elf_entry;
+   elf_entry += loc->interp_elf_ex.e_entry;
if (BAD_ADDR(elf_entry)) {
force_sig(SIGSEGV, current);
-   retval = IS_ERR((void *)elf_entry) ?
-   (int)elf_entry : -EINVAL;
+   retval = -EINVAL;
goto out_free_dentry;
}
reloc_func_desc = interp_load_addr;
-- 
1.7.10.4

--
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] arm: Preserve TPIDRURW on context switch

[Matthieu CASTET]

Will Deacon a écrit :
> Hi Andre,
> 
> On Tue, Feb 12, 2013 at 02:02:59PM +, André Hentschel wrote:
>> Am 08.02.2013 16:48, schrieb Will Deacon:
>>> On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote:
 No, i'm not sure how to improve this. How does the process can continue, 
 can you or someone else fix that and add his Signed-off-by?
>>> How about something like the (completely untested) diff below?
>>>
>>> Andre: if this works for you, I'm happy to write a commit message etc.
>> Thx for your effort, but it doesn't work, at least not with my 3.4.6 suse 
>> kernel.
>> Be free to have another try, i'll be happy to test it.
> 
> Well, cheers for testing. Can you be more specific about what goes wrong
> please? What do you see in TPIDRURW?
> 
The tls value is never saved to : thread->tp_value[1].

Also I don't know if you can avoid the extra ldr in the software case.

Matthieu
--
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 v3 1/2] mtd: Add a common JEDEC flash device table

[Matthieu CASTET]

INBOND, 0x3017),  8192 },
> +};
> +
> +/*
> + * jedec_match_device - match a jedec id against the flash_devices table
> + * @jedecid: JEDEC formatted id to match
> + *   bits 16..24: manufacturer id
> + *   bits  0..15: device id
> + * Returns a valid flash_device_info* or ERR_PTR(-ENODEV) if an entry is
> + * not found
> + */
> +struct flash_device_info *jedec_match_device(u32 jedec_id)
> +{
> + int i;
> + for (i = 0; i < ARRAY_SIZE(flash_devices); i++)
> + if (flash_devices[i].jedec_id == jedec_id)
> + return &flash_devices[i];
> +
> + return ERR_PTR(-ENODEV);
> +}
> diff --git a/drivers/mtd/devices/flash_jedec.h 
> b/drivers/mtd/devices/flash_jedec.h
> new file mode 100644
> index 000..27b978a
> --- /dev/null
> +++ b/drivers/mtd/devices/flash_jedec.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright Tony Prisk 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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
> + */
> +
> +#ifndef __MTD_FLASH_JEDEC
> +#define __MTD_FLASH_JEDEC
> +
> +struct flash_device_info {
> + const char  *name;
> + u32 jedec_id;
> + u32 size_kb;
> +};
> +
> +extern struct flash_device_info *jedec_match_device(u32 jedec_id);
> +
> +#endif


-- 
Matthieu Castet
Ingénieur Développement Logiciel
Parrot SA
174 Quai de Jemmapes
75010 Paris, France

Tél: +33 (0) 1 48 03 74 78
Fax: +33 (0) 1 48 03 06 66
Email: matthieu.cas...@parrot.fr
http://www.parrot.biz
--
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] mtd: fix the wrong timeo for panic_nand_wait()

[Matthieu CASTET]

Could you explain why the old code was wrong ?

With HZ=100

timeo = jiffies + 2 and it should be working.


Huang Shijie a écrit :
> In nand_wait(), the timeo for panic_nand_wait() is assigned with
> wrong value(jiffies + some delay).
> 
> This patch fixes it, and also uses the msecs_to_jiffies() to make the
> code more readable.
> 
> Signed-off-by: Huang Shijie 
> ---
>  drivers/mtd/nand/nand_base.c |8 ++--
>  1 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 8323ac9..acdd508 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -825,14 +825,9 @@ static void panic_nand_wait(struct mtd_info *mtd, struct 
> nand_chip *chip,
>  static int nand_wait(struct mtd_info *mtd, struct nand_chip *chip)
>  {
>  
> - unsigned long timeo = jiffies;
> + unsigned long timeo = (state == FL_ERASING) ? 400 : 20;
>   int status, state = chip->state;
>  
> - if (state == FL_ERASING)
> - timeo += (HZ * 400) / 1000;
> - else
> - timeo += (HZ * 20) / 1000;
> -
>   led_trigger_event(nand_led_trigger, LED_FULL);
>  
>   /*
> @@ -849,6 +844,7 @@ static int nand_wait(struct mtd_info *mtd, struct 
> nand_chip *chip)
>   if (in_interrupt() || oops_in_progress)
>   panic_nand_wait(mtd, chip, timeo);
>   else {
> + timeo = jiffies + msecs_to_jiffies(timeo);
>   while (time_before(jiffies, timeo)) {
>   if (chip->dev_ready) {
>   if (chip->dev_ready(mtd))
--
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] slab : allow SLAB_RED_ZONE and SLAB_STORE_USER to work on arm

[Matthieu CASTET]

The current slab code only allow to put redzone( and user store) info if "buffer
alignment(ralign) <= __alignof__(unsigned long long)". This was done because we
want to keep the buffer aligned for user even after adding redzone at the
beginning of the buffer (the user store is stored after user buffer) [1]

But instead of disabling this feature when "ralign > __alignof__(unsigned long
long)", we can force the alignment by allocating ralign before user buffer.

This is done by setting ralign in obj_offset when "ralign > __alignof__(unsigned
long long)" and keeping the old behavior when  "ralign <= __alignof__(unsigned
long long)" (we set sizeof(unsigned long long)).

The 5c5e3b33b7cb959a401f823707bee006caadd76e commit wasn't handling "ralign <=
__alignof__(unsigned long long)", that's why it broked some configuration.

This was tested on omap3 (ralign is 64 and __alignof__(unsigned long long) is 8)

[1]
/*
 * memory layout of objects:
 * 0: objp
 * 0 .. cachep->obj_offset - BYTES_PER_WORD - 1: padding. This ensures that
 *  the end of an object is aligned with the end of the real
 *  allocation. Catches writes behind the end of the allocation.
 * cachep->obj_offset - BYTES_PER_WORD .. cachep->obj_offset - 1:
 *  redzone word.
 * cachep->obj_offset: The real object.
 * cachep->buffer_size - 2* BYTES_PER_WORD: redzone word [BYTES_PER_WORD long]
 * cachep->buffer_size - 1* BYTES_PER_WORD: last caller address
 *  [BYTES_PER_WORD long]
 */

Signed-off-by: Matthieu Castet 
CC: Russell King 
CC: Pekka Enberg 
---
 mm/slab.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e7667a3..d2380d9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2392,9 +2392,6 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned 
long flags)
if (ralign < cachep->align) {
ralign = cachep->align;
}
-   /* disable debug if necessary */
-   if (ralign > __alignof__(unsigned long long))
-   flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
/*
 * 4) Store it.
 */
@@ -2414,8 +2411,9 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned 
long flags)
 */
if (flags & SLAB_RED_ZONE) {
/* add space for red zone words */
-   cachep->obj_offset += sizeof(unsigned long long);
-   size += 2 * sizeof(unsigned long long);
+   int offset = max(ralign, sizeof(unsigned long long));
+   cachep->obj_offset += offset;
+   size += offset + sizeof(unsigned long long);
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-- 
1.7.10.4

--
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] mtd: apply tPROG delay for ONFI nand's page program

[Matthieu CASTET]

Huang Shijie a écrit :
> With some latest Micron's onfi nand(such as MT29F64G08CBABAWP),
> I find that if we do not apply the tPROG delay as the datasheet tells us,
> the page program may fails. You will read out the all 0xff from this page
> in this case.
> 
> This patch adds the tPROG delay for page program when it is an onfi nand.
> 
> Signed-off-by: Huang Shijie 
> ---
>  drivers/mtd/nand/nand_base.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 8323ac9..b628dd5 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -841,6 +841,10 @@ static int nand_wait(struct mtd_info *mtd, struct 
> nand_chip *chip)
>*/
>   ndelay(100);
>  
> + /* Apply the tPROG delay for ONFI nand program. */
> + if (chip->onfi_version && state == FL_WRITING)
> + udelay(le16_to_cpu(chip->onfi_params.t_prog));
> +
>   if ((state == FL_ERASING) && (chip->options & NAND_IS_AND))
>   chip->cmdfunc(mtd, NAND_CMD_STATUS_MULTI, -1, -1);
>   else
It looks wrong : why should be wait tPROG before using status command to monitor
program end ?

tPROG is the Page program time (Measured from the falling edge of SR[6] to the
rising edge of SR[6]), but because we monitor SR[6] with status command, we
already wait for that time.

Are you sure that it is not a bug in your nand driver with status command ?



Matthieu
--
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 : Re: Sound+USB: deadlock problem

[Matthieu CASTET]

A deadlock was detected with this patch. You need the following patch [1]


Matthieu


> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Takashi Iwai 
> 
> commit 34f3c89fda4fba9fe689db22253ca8db2f5e6386 upstream.
> 
> Replace mutex with rwsem for codec->shutdown protection so that
> concurrent accesses are allowed.
> 
> Also add the protection to snd_usb_autosuspend() and
> snd_usb_autoresume(), too.
> 
> Reported-by: Matthieu CASTET 
> Signed-off-by: Takashi Iwai 
> Signed-off-by: Ben Hutchings 
> ---
>  sound/usb/card.c | 12 
>  sound/usb/mixer.c| 12 ++--
>  sound/usb/pcm.c  | 12 ++--
>  sound/usb/usbaudio.h |  2 +-
>  4 files changed, 21 insertions(+), 17 deletions(-)



[1]

Takashi Iwai a écrit :
> At Tue, 13 Nov 2012 10:39:14 +0100,
> Jiri Slaby wrote:
>> On 11/13/2012 09:45 AM, Takashi Iwai wrote:
>>> At Tue, 13 Nov 2012 09:30:10 +0100,
>>> Jiri Slaby wrote:
>>>> On 11/13/2012 09:28 AM, Takashi Iwai wrote:
>>>>> At Tue, 13 Nov 2012 09:26:17 +0100,
>>>>> Jiri Slaby wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I've just plugged+unplugged+plugged my USB audio card and the audio
>>>>>> subsystem got stuck:
>>>>> Which kernel?  If it's older than 3.7-rc5, could you try 3.7-rc5?
>>>> Oh, forgot to mention:
>>>> 3.7.0-rc5-next-20121112_64+
>>> Through a quick glance, one of mutex locks seems stuck.
>>> Just a blind short -- does the patch below cure the problem?
>> Yes, this helps.
>>
>> Adding a LOCKDEP splash _before_ applying the patch:
> 
> Thanks, this helps much for understanding the cause.
> It's a new rwsem in the usb-audio driver that deadlocks.
> 
> Although the previous patch fixes the deadlock it opens the race
> again. 
> 
> Could you try the patch below instead?  The rwsem above doesn't have
> to be taken for the whole operation, but just needs to protect for
> turning on the flag.  The patch below should suffice for protecting
> races but avoids the deadlock.
> 
> 
> Takashi
> 
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 282f0fc..dbf7999 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -559,9 +559,11 @@ static void snd_usb_audio_disconnect(struct usb_device 
> *dev,
>   return;
>  
>   card = chip->card;
> - mutex_lock(®ister_mutex);
>   down_write(&chip->shutdown_rwsem);
>   chip->shutdown = 1;
> + up_write(&chip->shutdown_rwsem);
> +
> + mutex_lock(®ister_mutex);
>   chip->num_interfaces--;
>   if (chip->num_interfaces <= 0) {
>   snd_card_disconnect(card);
> @@ -582,11 +584,9 @@ static void snd_usb_audio_disconnect(struct usb_device 
> *dev,
>   snd_usb_mixer_disconnect(p);
>   }
>   usb_chip[chip->index] = NULL;
> - up_write(&chip->shutdown_rwsem);
>   mutex_unlock(®ister_mutex);
>   snd_card_free_when_closed(card);
>   } else {
> - up_write(&chip->shutdown_rwsem);
>   mutex_unlock(®ister_mutex);
>   }
>  }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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] arm: memtest

[Matthieu Castet]

Note memtester is also a great userspace tool for testing memory :
http://pyropus.ca/software/memtester/

It works fine on arm and other arch (but work on malloc or /dev/mem memory)--
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] dmapool : make DMAPOOL_DEBUG detect corruption of free marker

[Matthieu CASTET]

This can help to catch case where hardware is writting after dma free.

Signed-off-by: Matthieu Castet 
---
 mm/dmapool.c |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..e10898a 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -346,6 +346,29 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t 
mem_flags,
retval = offset + page->vaddr;
*handle = offset + page->dma;
 #ifdef DMAPOOL_DEBUG
+   {
+   int i;
+   u8 *data = retval;
+   /* page->offset is stored in first 4 bytes */
+   for (i = sizeof(int); i < pool->size; i++) {
+   if (data[i] != POOL_POISON_FREED) {
+   if (pool->dev)
+   dev_err(pool->dev,
+   "dma_pool_alloc %s, %p 
(corruped)\n",
+   pool->name, retval);
+   else
+   printk(KERN_ERR
+   "dma_pool_alloc %s, %p 
(corruped)\n",
+   pool->name, retval);
+
+   /* we dump the first 4 bytes even if there are 
not
+  POOL_POISON_FREED */
+   print_hex_dump(KERN_ERR, "", 
DUMP_PREFIX_OFFSET, 16, 1,
+   data, pool->size, 1);
+   break;
+   }
+   }
+   }
memset(retval, POOL_POISON_ALLOCATED, pool->size);
 #endif
  done:
-- 
1.7.10.4

--
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] slab : allow SLAB_RED_ZONE and SLAB_STORE_USER to work on arm

[Matthieu CASTET]

Pekka Enberg a écrit :
> Hi,
> 
> (Adding more people to CC.)
> 
> On Tue, Oct 16, 2012 at 2:17 PM, Matthieu CASTET
>  wrote:
>> From: Matthieu CASTET 
>>
>> on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
>> So we always disable debug.
>>
>> This patch is based on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
>> case were align < sizeof(unsigned long long).
>>
>> Signed-off-by: Matthieu Castet 
>> CC: Russell King 
>> CC: Pekka Enberg 
>> ---
>>  mm/slab.c |8 +++-
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index c685475..8427901 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -2462,9 +2462,6 @@ __kmem_cache_create (const char *name, size_t size, 
>> size_t align,
>> if (ralign < align) {
>> ralign = align;
>> }
>> -   /* disable debug if necessary */
>> -   if (ralign > __alignof__(unsigned long long))
>> -   flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
>> /*
>>  * 4) Store it.
>>  */
>> @@ -2491,8 +2488,9 @@ __kmem_cache_create (const char *name, size_t size, 
>> size_t align,
>>  */
>> if (flags & SLAB_RED_ZONE) {
>> /* add space for red zone words */
>> -   cachep->obj_offset += sizeof(unsigned long long);
>> -   size += 2 * sizeof(unsigned long long);
>> +   int offset = max(align, sizeof(unsigned long long));
>> +   cachep->obj_offset += offset;
>> +   size += offset + sizeof(unsigned long long);
>> }
>> if (flags & SLAB_STORE_USER) {
>> /* user store requires one word storage behind the end of
> 
> This piece of code tends to break in peculiar ways every time someone
> touches it. I could use some more convincing in the changelog this
> time it won't...
> 
Ok, is the following changelog is ok ?

The current slab code only allow to put redzone( and user store) info if "buffer
alignment(ralign) <= __alignof__(unsigned long long)". This was done because we
want to keep the buffer aligned for user even after adding redzone at the
beginning of the buffer (the user store is stored after user buffer) [1]

But instead of disabling this feature when "ralign > __alignof__(unsigned long
long)", we can force the alignment by allocating ralign before user buffer.

This is done by setting ralign in obj_offset when "ralign > __alignof__(unsigned
long long)" and keeping the old behavior when  "ralign <= __alignof__(unsigned
long long)" (we set sizeof(unsigned long long)).

The 5c5e3b33b7cb959a401f823707bee006caadd76e commit wasn't handling "ralign <=
__alignof__(unsigned long long)", that's why it broked some configuration.

This was tested on omap3 (ralign is 64 and __alignof__(unsigned long long) is 8)


[1]
/*
 * memory layout of objects:
 * 0: objp
 * 0 .. cachep->obj_offset - BYTES_PER_WORD - 1: padding. This ensures that
 *  the end of an object is aligned with the end of the real
 *  allocation. Catches writes behind the end of the allocation.
 * cachep->obj_offset - BYTES_PER_WORD .. cachep->obj_offset - 1:
 *  redzone word.
 * cachep->obj_offset: The real object.
 * cachep->buffer_size - 2* BYTES_PER_WORD: redzone word [BYTES_PER_WORD long]
 * cachep->buffer_size - 1* BYTES_PER_WORD: last caller address
 *  [BYTES_PER_WORD long]
 */
--
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] slab : allow SLAB_RED_ZONE and SLAB_STORE_USER to work on arm

[Matthieu CASTET]

From: Matthieu CASTET 

on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
So we always disable debug.

This patch is based on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
case were align < sizeof(unsigned long long).

Signed-off-by: Matthieu Castet 
CC: Russell King 
CC: Pekka Enberg 
---
 mm/slab.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index c685475..8427901 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2462,9 +2462,6 @@ __kmem_cache_create (const char *name, size_t size, 
size_t align,
if (ralign < align) {
ralign = align;
}
-   /* disable debug if necessary */
-   if (ralign > __alignof__(unsigned long long))
-   flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
/*
 * 4) Store it.
 */
@@ -2491,8 +2488,9 @@ __kmem_cache_create (const char *name, size_t size, 
size_t align,
 */
if (flags & SLAB_RED_ZONE) {
/* add space for red zone words */
-   cachep->obj_offset += sizeof(unsigned long long);
-   size += 2 * sizeof(unsigned long long);
+   int offset = max(align, sizeof(unsigned long long));
+   cachep->obj_offset += offset;
+   size += offset + sizeof(unsigned long long);
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-- 
1.7.10.4

--
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 v2] hvc_dcc : add support to armv4 and armv5 core

[matthieu castet]

Le Tue, 25 Sep 2012 15:44:57 +,
Arnd Bergmann  a écrit :

> 
> It's not possible to build a kernel that runs on ARMv5 (or below) and
> also on ARMv6 (or above), so the effect would be exactly the same.
> While we are putting a lot of effort into making all sorts of ARMv6
> and ARMv7 based systems work with the same kernel binary, it's highly
> unlikely we would ever need the above to be runtime selected, because
> there are a lot of other differences at assembly level.
> 
I know but Alan was not happy with the static version with ifdef [1]
[2]. That why a dynamic version was done.


Matthieu


[1]
> > There are no plans to ever make it possible; there are too many
> > significant differences between ARMv4, v5 architectures and
> > ARMv6,v7 architectures to warrant making this runtime selectable.  
> 
> Then bury this crap in platform files please not in the drivers/tty
> layer code. Make it a platform driver provided callback or something.
> 
> Alan

[2]
> > I posted a new v2 patch that make the selection dynamic.  
> 
> Thanks - fine with that one - or with burying it in headers etc in
> the arm subdirs.
--
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 v2] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Stephen Boyd a écrit :
> On 8/31/2012 4:47 AM, Matthieu CASTET wrote:
>> Signed-off-by: Matthieu Castet 
> 
> Please consider adding some sort of commit text. Does this add some new
> feature I may want on some downstream distro kernel?
> 
ok
> 
> It's unfortunate that the main logic is duplicated. I wonder if we could
> push the runtime decision slightly lower into the accessor functions
> instead and make some new functions dcc_tx_busy() and dcc_rx_busy() or
> something. Then these loops stay the same.
see my previous mail

>> +static inline char __dcc_getchar(void)
>> +{
>> +char c;
>> +
>> +asm __volatile__ ("mrc p14, 0, %0, c1, c0   @ read comms data reg"
>> +: "=r" (c));
>> +
> 
> Do you see any multiple character inputs? I think you may need an isb
> here similar to the v6/7 code and in the putchar as well.
I don't see multiple character.
On armv5 isb is only a memory barrier (__asm__ __volatile__ ("" : : : "memory"))
 and it may be not need for dcc operation.


Matthieu
--
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 v2] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Arnd Bergmann a écrit :
> On Friday 31 August 2012, Stephen Boyd wrote:
>>> +static int hvc_dcc_put_chars_v6(uint32_t vt, const char *buf, int count)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < count; i++) {
>>> + while (__dcc_getstatus_v6() & DCC_STATUS_TX_V6)
>>> + cpu_relax();
>>> +
>>> + __dcc_putchar_v6(buf[i]);
>>> + }
>>> +
>>> + return count;
>>> +}
>> It's unfortunate that the main logic is duplicated. I wonder if we could
>> push the runtime decision slightly lower into the accessor functions
>> instead and make some new functions dcc_tx_busy() and dcc_rx_busy() or
>> something. Then these loops stay the same.
The code is so small (30 asm + 30 C code) that I wonder if worth adding
complexity in the code.
Also calling cpu_architecture isn't free and if the want to put the runtime
decision into the hot path, this means we need to cache the result.

> 
> Agreed. Ideally, you should be able to get the code to be compiled into
> the same binary as before for ARMv6+. If only the inline assembly differs,
> you can do something like
> 
> static inline char __dcc_getchar(void)
> {
> char __c;
> 
> if (__LINUX_ARM_ARCH >= 6)
>   asm volatile("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
>   : "=r" (__c));
>   else
>   asm volatile ("mrc p14, 0, %0, c1, c0  @ read comms data reg"
>   : "=r" (ret));
> isb();
> 
> return __c;
> }
> 
>   Arnd
> 
Yes doing that will be great!

But Alan wanted "all be runtime handled".

May be we can do something like:


static int cpu_arch;

static inline char __dcc_getchar(void)
{
 char __c;

 if (cpu_arch >= 6)
asm volatile("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
: "=r" (__c));
else
asm volatile ("mrc p14, 0, %0, c1, c0  @ read comms data reg"
: "=r" (ret));
 isb();

 return __c;
}

static int __init hvc_dcc_console_init(void)
{
cpu_arch = cpu_architecture();
...

}
Matthieu
--
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] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Alan Cox a écrit :
> On Fri, 31 Aug 2012 11:33:51 +0100
> Russell King - ARM Linux  wrote:
> 
>> On Fri, Aug 31, 2012 at 12:29:04PM +0200, Matthieu CASTET wrote:
>>> Alan Cox a écrit :
>>>> On Fri, 31 Aug 2012 11:21:56 +0200
>>>> Matthieu CASTET  wrote:
>>>>
>>>>> Signed-off-by: Matthieu Castet 
>>>>> ---
>>>>>  drivers/tty/hvc/hvc_dcc.c |   34 ++
>>>>>  1 file changed, 34 insertions(+)
>>>> This is a step in the wrong direction. This should all be runtime handled
>>>>
>>>> NAK.
>>>>
>>> AFAIK you can't build a arm kernel that support arm6/armv7 and armv5.
>>> And I am not sure it will be possible one day.
>> There are no plans to ever make it possible; there are too many significant
>> differences between ARMv4, v5 architectures and ARMv6,v7 architectures
>> to warrant making this runtime selectable.
> 
> Then bury this crap in platform files please not in the drivers/tty layer
> code. Make it a platform driver provided callback or something.
> 
I posted a new v2 patch that make the selection dynamic.


Matthieu
--
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 v2] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Signed-off-by: Matthieu Castet 
---
 drivers/tty/hvc/hvc_dcc.c |   83 +
 1 file changed, 76 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..5f8827f 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -27,10 +27,10 @@
 #include "hvc_console.h"
 
 /* DCC Status Bits */
-#define DCC_STATUS_RX  (1 << 30)
-#define DCC_STATUS_TX  (1 << 29)
+#define DCC_STATUS_RX_V6   (1 << 30)
+#define DCC_STATUS_TX_V6   (1 << 29)
 
-static inline u32 __dcc_getstatus(void)
+static inline u32 __dcc_getstatus_v6(void)
 {
u32 __ret;
asm volatile("mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg"
@@ -40,7 +40,7 @@ static inline u32 __dcc_getstatus(void)
 }
 
 
-static inline char __dcc_getchar(void)
+static inline char __dcc_getchar_v6(void)
 {
char __c;
 
@@ -51,7 +51,7 @@ static inline char __dcc_getchar(void)
return __c;
 }
 
-static inline void __dcc_putchar(char c)
+static inline void __dcc_putchar_v6(char c)
 {
asm volatile("mcr p14, 0, %0, c0, c5, 0 @ write a char"
: /* no output register */
@@ -59,6 +59,69 @@ static inline void __dcc_putchar(char c)
isb();
 }
 
+static int hvc_dcc_put_chars_v6(uint32_t vt, const char *buf, int count)
+{
+   int i;
+
+   for (i = 0; i < count; i++) {
+   while (__dcc_getstatus_v6() & DCC_STATUS_TX_V6)
+   cpu_relax();
+
+   __dcc_putchar_v6(buf[i]);
+   }
+
+   return count;
+}
+
+static int hvc_dcc_get_chars_v6(uint32_t vt, char *buf, int count)
+{
+   int i;
+
+   for (i = 0; i < count; ++i)
+   if (__dcc_getstatus_v6() & DCC_STATUS_RX_V6)
+   buf[i] = __dcc_getchar_v6();
+   else
+   break;
+
+   return i;
+}
+
+static const struct hv_ops hvc_dcc_get_put_ops_v6 = {
+   .get_chars = hvc_dcc_get_chars_v6,
+   .put_chars = hvc_dcc_put_chars_v6,
+};
+
+#define DCC_STATUS_RX  (1 << 0)
+#define DCC_STATUS_TX  (1 << 1)
+
+/* primitive JTAG1 protocol utilities */
+static inline u32 __dcc_getstatus(void)
+{
+   u32 ret;
+
+   asm __volatile__ ("mrc p14, 0, %0, c0, c0   @ read comms ctrl reg"
+   : "=r" (ret));
+
+   return ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+   char c;
+
+   asm __volatile__ ("mrc p14, 0, %0, c1, c0   @ read comms data reg"
+   : "=r" (c));
+
+   return c;
+}
+
+static inline void __dcc_putchar(unsigned char c)
+{
+   asm __volatile__ ("mcr p14, 0, %0, c1, c0   @ write a char"
+   : /* no output register */
+   : "r" (c));
+}
+
 static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
 {
int i;
@@ -93,14 +156,20 @@ static const struct hv_ops hvc_dcc_get_put_ops = {
 
 static int __init hvc_dcc_console_init(void)
 {
-   hvc_instantiate(0, 0, &hvc_dcc_get_put_ops);
+   if (cpu_architecture() >= CPU_ARCH_ARMv6)
+   hvc_instantiate(0, 0, &hvc_dcc_get_put_ops_v6);
+   else
+   hvc_instantiate(0, 0, &hvc_dcc_get_put_ops);
return 0;
 }
 console_initcall(hvc_dcc_console_init);
 
 static int __init hvc_dcc_init(void)
 {
-   hvc_alloc(0, 0, &hvc_dcc_get_put_ops, 128);
+   if (cpu_architecture() >= CPU_ARCH_ARMv6)
+   hvc_alloc(0, 0, &hvc_dcc_get_put_ops_v6, 128);
+   else
+   hvc_alloc(0, 0, &hvc_dcc_get_put_ops, 128);
return 0;
 }
 device_initcall(hvc_dcc_init);
-- 
1.7.10.4

--
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] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Alan Cox a écrit :
> On Fri, 31 Aug 2012 11:21:56 +0200
> Matthieu CASTET  wrote:
> 
>> Signed-off-by: Matthieu Castet 
>> ---
>>  drivers/tty/hvc/hvc_dcc.c |   34 ++
>>  1 file changed, 34 insertions(+)
> 
> This is a step in the wrong direction. This should all be runtime handled
> 
> NAK.
> 

AFAIK you can't build a arm kernel that support arm6/armv7 and armv5.
And I am not sure it will be possible one day.


--
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] hvc_dcc : add support to armv4 and armv5 core

[Matthieu CASTET]

Signed-off-by: Matthieu Castet 
---
 drivers/tty/hvc/hvc_dcc.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..489e9e5 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -26,6 +26,7 @@
 
 #include "hvc_console.h"
 
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7)
 /* DCC Status Bits */
 #define DCC_STATUS_RX  (1 << 30)
 #define DCC_STATUS_TX  (1 << 29)
@@ -58,6 +59,39 @@ static inline void __dcc_putchar(char c)
: "r" (c));
isb();
 }
+#else
+/* DCC Status Bits */
+#define DCC_STATUS_RX  (1 << 0)
+#define DCC_STATUS_TX  (1 << 1)
+
+/* primitive JTAG1 protocol utilities */
+static inline u32 __dcc_getstatus(void)
+{
+   u32 ret;
+
+   asm __volatile__ ("mrc p14, 0, %0, c0, c0   @ read comms ctrl reg"
+   : "=r" (ret));
+
+   return ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+   char c;
+
+   asm __volatile__ ("mrc p14, 0, %0, c1, c0   @ read comms data reg"
+   : "=r" (c));
+
+   return c;
+}
+
+static inline void __dcc_putchar(unsigned char c)
+{
+   asm __volatile__ ("mcr p14, 0, %0, c1, c0   @ write a char"
+   : /* no output register */
+   : "r" (c));
+}
+#endif
 
 static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
 {
-- 
1.7.10.4

--
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] ueagle-atm: Declare MODULE_FIRMWARE usage

[matthieu castet]

Ack-by: matthieu castet 

Le Wed, 25 Jul 2012 14:32:50 -0600,
Tim Gardner  a écrit :

> Cc: Matthieu CASTET 
> Cc: Stanislaw Gruszka 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Tim Gardner 
> ---
>  drivers/usb/atm/ueagle-atm.c |   79
> +++--- 1 file changed, 66
> insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/usb/atm/ueagle-atm.c
> b/drivers/usb/atm/ueagle-atm.c index d7e422d..e1f8b2c 100644
> --- a/drivers/usb/atm/ueagle-atm.c
> +++ b/drivers/usb/atm/ueagle-atm.c
> @@ -307,6 +307,34 @@ enum {
>  #define FW_GET_BYTE(p) (*((__u8 *) (p)))
>  
>  #define FW_DIR "ueagle-atm/"
> +#define EAGLE_FIRMWARE FW_DIR "eagle.fw"
> +#define ADI930_FIRMWARE FW_DIR "adi930.fw"
> +#define EAGLE_I_FIRMWARE FW_DIR "eagleI.fw"
> +#define EAGLE_II_FIRMWARE FW_DIR "eagleII.fw"
> +#define EAGLE_III_FIRMWARE FW_DIR "eagleIII.fw"
> +#define EAGLE_IV_FIRMWARE FW_DIR "eagleIV.fw"
> +
> +#define DSP4I_FIRMWARE FW_DIR "DSP4i.bin"
> +#define DSP4P_FIRMWARE FW_DIR "DSP4p.bin"
> +#define DSP9I_FIRMWARE FW_DIR "DSP9i.bin"
> +#define DSP9P_FIRMWARE FW_DIR "DSP9p.bin"
> +#define DSPEI_FIRMWARE FW_DIR "DSPei.bin"
> +#define DSPEP_FIRMWARE FW_DIR "DSPep.bin"
> +#define FPGA930_FIRMWARE FW_DIR "930-fpga.bin"
> +
> +#define CMV4P_FIRMWARE FW_DIR "CMV4p.bin"
> +#define CMV4PV2_FIRMWARE FW_DIR "CMV4p.bin.v2"
> +#define CMV4I_FIRMWARE FW_DIR "CMV4i.bin"
> +#define CMV4IV2_FIRMWARE FW_DIR "CMV4i.bin.v2"
> +#define CMV9P_FIRMWARE FW_DIR "CMV9p.bin"
> +#define CMV9PV2_FIRMWARE FW_DIR "CMV9p.bin.v2"
> +#define CMV9I_FIRMWARE FW_DIR "CMV9i.bin"
> +#define CMV9IV2_FIRMWARE FW_DIR "CMV9i.bin.v2"
> +#define CMVEP_FIRMWARE FW_DIR "CMVep.bin"
> +#define CMVEPV2_FIRMWARE FW_DIR "CMVep.bin.v2"
> +#define CMVEI_FIRMWARE FW_DIR "CMVei.bin"
> +#define CMVEIV2_FIRMWARE FW_DIR "CMVei.bin.v2"
> +
>  #define UEA_FW_NAME_MAX 30
>  #define NB_MODEM 4
>  
> @@ -694,26 +722,26 @@ err:
>  static int uea_load_firmware(struct usb_device *usb, unsigned int
> ver) {
>   int ret;
> - char *fw_name = FW_DIR "eagle.fw";
> + char *fw_name = EAGLE_FIRMWARE;
>  
>   uea_enters(usb);
>   uea_info(usb, "pre-firmware device, uploading firmware\n");
>  
>   switch (ver) {
>   case ADI930:
> - fw_name = FW_DIR "adi930.fw";
> + fw_name = ADI930_FIRMWARE;
>   break;
>   case EAGLE_I:
> - fw_name = FW_DIR "eagleI.fw";
> + fw_name = EAGLE_I_FIRMWARE;
>   break;
>   case EAGLE_II:
> - fw_name = FW_DIR "eagleII.fw";
> + fw_name = EAGLE_II_FIRMWARE;
>   break;
>   case EAGLE_III:
> - fw_name = FW_DIR "eagleIII.fw";
> + fw_name = EAGLE_III_FIRMWARE;
>   break;
>   case EAGLE_IV:
> - fw_name = FW_DIR "eagleIV.fw";
> + fw_name = EAGLE_IV_FIRMWARE;
>   break;
>   }
>  
> @@ -869,19 +897,19 @@ static int request_dsp(struct uea_softc *sc)
>  
>   if (UEA_CHIP_VERSION(sc) == EAGLE_IV) {
>   if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSP4i.bin";
> + dsp_name = DSP4I_FIRMWARE;
>   else
> - dsp_name = FW_DIR "DSP4p.bin";
> + dsp_name = DSP4P_FIRMWARE;
>   } else if (UEA_CHIP_VERSION(sc) == ADI930) {
>   if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSP9i.bin";
> + dsp_name = DSP9I_FIRMWARE;
>   else
> - dsp_name = FW_DIR "DSP9p.bin";
> + dsp_name = DSP9P_FIRMWARE;
>   } else {
>   if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSPei.bin";
> + dsp_name = DSPEI_FIRMWARE;
>   else
> - dsp_name = FW_DIR "DSPep.bin";
> + dsp_name = DSPEP_FIRMWARE;
>   }
>  
>   ret = request_firmware(&sc->dsp_firm, dsp_name,
> &sc->usb_dev->dev); @@ -1925,7 +1953,7 @@ static int
> load_XILINX_firmware(struct uea_softc *sc) int ret, size, u, ln;
>   const u8 *pfw;
>   u8 value;
> - char *fw_name = FW_DIR "930-fpga.bin";
> + char *fw_name = FPGA930_FIRMW

Re: [RFC] [PATCH] Fix b43 driver build for arm

[Matthieu CASTET]

Sam Ravnborg  ravnborg.org> writes:

> 
> In at least 99% of the cases this is OK and the check has found
> several bugs where things would not have worked due to different
> alignmnet between kernel and userland. Just think about the
> issues in a mixed 32/64 bit world.
> 
I don't see how this check is supposed to work.
For some arch userspace can have different alignement depending on compilation
option :
- x86_64 : 32 or 64 bits mode
- arm : 32 bits or thumb mode
- mips : 32 bits or mips16 mode
[...]

The check is done only for one case ?


> In this particular case you _could_ be right that it would work
> on ARM userland. But the only way to be sure is to pad the
> structure so it become 8 byte in size.
> Or as was recently done in the m68k case to tell the
> compiler to specifically align it to 8 byte boundary.
An easy way to fix this is just to issue a warning but not an error. So it could
ignored on cross compilation case.

Matthieu

--
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: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Matthieu castet]

Hi,

David P. Reed  reed.com> writes:

> And actually, if I had looked at the /sys/bus/pnp definitions, rather 
> than /proc/ioports, I would have noticed that port 80 was part of a 
> PNP0C02 resource set.   That means exactly one thing:  ACPI says that 
> port 80 is NOT free to be used, for delays or anything else.

I have some computers where port 0x80 is claimed by 8237A DMA controller [1]
But in this case it seems a lasy acpi programmer that doesn't want to convert
the hole in  0x80-0x8f range...


PS : I post from gmane web interface, so I can't keep CC.

[1]
This happen with a old 7 years old siemens PIII and a new hp core2duo.
state = active
io 0x0-0xf
io 0x80-0x8f
io 0xc0-0xdf
dma 4 

--
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/

Clocksource tsc unstable after sysrq-t

[matthieu castet]

Hi,

I am on a 2.6.23.11 on a AMD Athlon(tm) XP 1800+.

When I do a sysrq-t, after the dump of task state (that is quite slow 
because of the vesa console framebuffer), I got the message


"Clocksource tsc unstable (delta = 28115415756 ns)
Time: acpi_pm clocksource has been installed."

Is that normal ?


Matthieu
--
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: [PATCH] signals: real-time signals delivery order

[Matthieu CASTET]

Anton Salikhmetov  gmail.com> writes:

> 
> From: Anton Salikhmetov  gmail.com>
> 
> According to the POSIX standard, multiple real-time signals
> pending to a process should be delivered in a strict order.
> Specifically, the lowest-numbered signal should be delivered
> first and multiple occurrences of signals with the same number
> should be delivered in FIFO order.
> 
> Current Linux kernel delivers the highest-numbered signals
> pending to a process first, not the lowest-numbered ones. This
> contradicts to the requirement explained above. The problem can
> be demonstrated by the following test program:
I believe you should check that you mask or signal in your signal handler.
If you don't the high-prio handler will be prempted by low-prio, and they will
be executed in the reverse order.


Matthieu 

-
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: [patch 09/10] Remove the SLOB allocator for 2.6.23

[Matthieu CASTET]

Ingo Molnar  elte.hu> writes:


> A year ago the -rt kernel defaulted to the SLOB for a few releases, and 
> barring some initial scalability issues (which were solved in -rt) it 
> worked pretty well on generic PCs, so i dont buy the 'it doesnt work' 
> argument either.
> 
Last time I tried it, I cannot mount (or mount very slowly) jffs2 flash with 
slob.
Changing slob to slab fix the issue.


Matthieu

-
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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Matthieu CASTET]

Hi,

On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:

> OTOH, you also didn't supply a patch.  If you do this, I'll be glad to
> consider it.  If I can read it, that is.

"s|/bin/sh|/bin/bash" is so hard to do ?

Matthieu

PS : this remind me http://www.landley.net/code/firmware/ . Is it so 
difficult to understand that sh is not bash. It is like assuming that 
everybody as a "qwerty" keyboard.

-
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: FW : airo suspend problem

[matthieu castet]

Hi,

Pavel Machek wrote:

Hi!


  Sujet : airo suspend problem
  ? : [EMAIL PROTECTED]

Hi,

the airo driver (drivers/net/wireless/airo.c) does in its suspend routine [1].
But not all the pci cards support power management and cause
pci_enable_wake/pci_set_power_state to return errors.

On pci card that don't support PM, what should be done ?
Don't call pci_enable_wake/pci_set_power_state ?


That sounds right. Or simply ignore errors from enable_wake and
set_power_state?


Ok, I'll try to cook a patch.



PS : after the failed suspend to ram due to airo driver, I tried to unload airo
driver and it hanged. After a reset, I got my ext3 root fs corrupted :(


Corrupted or 'just needed journal replay'?

Really corrupted :
on reboot, there was no journal replay, but boot hanged. After some 
investigation some symbolic links were pointing to garbage (lot's of 
/etc/rcx.d/ ones). After a fsck (partial log attached) and some manual 
fix for symbolic links, the system was operational.



Matthieu
/dev/hdb3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Symlink /etc/rc0.d/K99local (inode #375211) is invalid.
Clear? no

Entry 'K99local' in /etc/rc0.d (375176) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc0.d/S32portmap (inode #375205) is invalid.
Clear? no

Entry 'S32portmap' in /etc/rc0.d (375176) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc1.d/K11cron (inode #375203) is invalid.
Clear? no

Entry 'K11cron' in /etc/rc1.d (375201) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc1.d/K99local (inode #375459) is invalid.
Clear? no

Entry 'K99local' in /etc/rc1.d (375201) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc1.d/K20hddtemp (inode #375206) is invalid.
Clear? no

Entry 'K20hddtemp' in /etc/rc1.d (375201) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc1.d/K20makedev (inode #375208) is invalid.
Clear? no

Entry 'K20makedev' in /etc/rc1.d (375201) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc1.d/K20smartmontools (inode #375209) is invalid.
Clear? no

Entry 'K20smartmontools' in /etc/rc1.d (375201) has an incorrect filetype (was 
7, should be 0).
Fix? no

Symlink /etc/rc1.d/K20ssh (inode #375210) is invalid.
Clear? no

Entry 'K20ssh' in /etc/rc1.d (375201) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc1.d/K89atd (inode #375212) is invalid.
Clear? no

Entry 'K89atd' in /etc/rc1.d (375201) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc1.d/K89klogd (inode #375213) is invalid.
Clear? no

Entry 'K89klogd' in /etc/rc1.d (375201) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc1.d/K90sysklogd (inode #375214) is invalid.
Clear? no

Entry 'K90sysklogd' in /etc/rc1.d (375201) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc2.d/S10sysklogd (inode #375218) is invalid.
Clear? no

Entry 'S10sysklogd' in /etc/rc2.d (375217) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc2.d/S11klogd (inode #375221) is invalid.
Clear? no

Entry 'S11klogd' in /etc/rc2.d (375217) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc2.d/S20hddtemp (inode #375224) is invalid.
Clear? no

Entry 'S20hddtemp' in /etc/rc2.d (375217) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc2.d/S20makedev (inode #375226) is invalid.
Clear? no

Entry 'S20makedev' in /etc/rc2.d (375217) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc2.d/S20smartmontools (inode #375227) is invalid.
Clear? no

Entry 'S20smartmontools' in /etc/rc2.d (375217) has an incorrect filetype (was 
7, should be 0).
Fix? no

Symlink /etc/rc2.d/S20ssh (inode #375228) is invalid.
Clear? no

Entry 'S20ssh' in /etc/rc2.d (375217) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc2.d/S89atd (inode #375229) is invalid.
Clear? no

Entry 'S89atd' in /etc/rc2.d (375217) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc2.d/S89cron (inode #375230) is invalid.
Clear? no

Entry 'S89cron' in /etc/rc2.d (375217) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rc2.d/S99rmnologin (inode #375232) is invalid.
Clear? no

Entry 'S99rmnologin' in /etc/rc2.d (375217) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rc5.d/S30gdm (inode #375231) is invalid.
Clear? no

Entry 'S30gdm' in /etc/rc5.d (375268) has an incorrect filetype (was 7, should 
be 0).
Fix? no

Symlink /etc/rcS.d/S01glibc.sh (inode #375480) is invalid.
Clear? no

Entry 'S01glibc.sh' in /etc/rcS.d (375310) has an incorrect filetype (was 7, 
should be 0).
Fix? no

Symlink /etc/rcS.d/S04mountdevsubfs.sh (inode #375216) is invalid.
Clear? no

Entry 'S04mountdevsubfs.sh' in /etc/rcS.d (375310) has an incorrect filetype 
(was 7, sh

Re: beeping patch for debugging acpi sleep

[Matthieu CASTET]

Hi,

On Mon, 11 Jun 2007 12:00:34 -0700, Andrew Morton wrote:

> On Sat, 9 Jun 2007 15:08:17 +0200
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
> 

> How does the beep get turned off again?
May be it is turn off by the speaker driver.


BTW can't we do something with led ? This way it can be always enabled 
without anoying people


Matthieu

-
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: RE : Building kernel 2.6.21.3 for arm on cygwin

[Matthieu CASTET]

Hi Sam,

Sam Ravnborg wrote:

Hi Matthieu.

Can you please try to tell what your patch actually does.

As for the part added in the MAkefile you pass -lintl for Cygwin -
but I fail to see _why_ -lintl is needed.

If I don't do it, I got [1] or [2].

Matthieu

[1]
scripts/kconfig/conf.o:conf.c:(.text+0x91): undefined reference to 
`_libintl_gettext'
scripts/kconfig/conf.o:conf.c:(.text+0xa5): undefined reference to 
`_libintl_gettext'
scripts/kconfig/conf.o:conf.c:(.text+0xb9): undefined reference to 
`_libintl_gettext'
scripts/kconfig/conf.o:conf.c:(.text+0x7b8): undefined reference to 
`_libintl_gettext'
scripts/kconfig/conf.o:conf.c:(.text+0xf19): undefined reference to 
`_libintl_gettext'
scripts/kconfig/conf.o:conf.c:(.text+0x1026): more undefined references 
to `_libintl_gettext' follow

collect2: ld returned 1 exit status

[2]
scripts/kconfig/mconf.o:mconf.c:(.text+0x923): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0x9c9): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0xa66): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0xa91): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0xab1): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0xadd): more undefined references 
to `_libintl_gettext' follow
scripts/kconfig/mconf.o:mconf.c:(.text+0x11af): undefined reference to 
`_libintl_bindtextdomain'
scripts/kconfig/mconf.o:mconf.c:(.text+0x11bb): undefined reference to 
`_libintl_textdomain'
scripts/kconfig/mconf.o:mconf.c:(.text+0x1207): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0x1414): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0x1467): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0x1482): undefined reference to 
`_libintl_gettext'
scripts/kconfig/mconf.o:mconf.c:(.text+0x14af): undefined reference to 
`_libintl_gettext'
scripts/kconfig/zconf.tab.o:zconf.tab.c:(.text+0x54e6): more undefined 
references to `_libintl_gettext' follow

Info: resolving _stdscr by linking to __imp__stdscr (auto-import)
Info: resolving _COLS by linking to __imp__COLS (auto-import)
Info: resolving _LINES by linking to __imp__LINES (auto-import)
collect2: ld returned 1 exit status
-
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: PROBLEM: system clock slow on Athlon AMD64 since 2.6.21

[Matthieu CASTET]

Hi,

On Sat, 09 Jun 2007 16:53:32 +0200, Mikael Pettersson wrote:

> On Fri, 08 Jun 2007 10:14:03 +0200, Gerard H. Pille wrote:
>> [1.] One line summary of the problem: Since I switched from 2.6.20 to
>> 2.6.21 on my Athlon AMD64 laptop, the system time is slow - about 1' on
>> 15'.
> 
> According to your system description it seems that you have a Targa
> Visionary laptop with a VIA chipset and a Mobile Athlon64. If so, then
> you probably have the same problem I reported some time ago: see
>  and the
> followup messages. The conclusion was that the chipset's ACPI PM timer
> slows down when the CPU is in C2.
Isn't possible to chose something other than ACPI PM timer ?


Matthieu

-
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: RE : Building kernel 2.6.21.3 for arm on cygwin

[Matthieu CASTET]

Hi,

Sam Ravnborg a écrit :

On Mon, Jun 04, 2007 at 11:45:29AM -0700, Tom wrote:

Hi Sam


enclosed is the 'k_smf.patch' which modifies three files to enable the 
kernel 2.6.21.3 to be built under cygwin:

host:  cygwin 1.5.24, hostcc= gcc 3.4.4
cross: arm-linux-uclibcgnueabi-gcc (GCC) 4.1.2
cmd:   make ARCH=arm CROSS_COMPILE=arm-linux- \
   HOST_LOADLIBES="-lcurses -lintl" at91rm9200dk_defconfig

I verified that this does not break building on a linux-host on this config:
host:  FC5, gcc 4.1.1-1
cross: arm-none-linux-gnueabi-gcc 4.1.1
cmd:   make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-


Let me know if I can help any further.

Hi Tom.

Patch looks good. The last bit touching sumversion.c is not
needed in latest kernel - we already include limits.h.


What about something like that for ncurses stuff ?


Matthieu
Index: scripts/kconfig/Makefile
===
RCS file: /soft/cvs/Linux/kernel/linux/scripts/kconfig/Makefile,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- scripts/kconfig/Makefile	5 Mar 2007 13:02:59 -	1.1.1.1
+++ scripts/kconfig/Makefile	6 Mar 2007 10:08:36 -	1.2
@@ -148,6 +148,13 @@
  else echo no ; fi)
 ifeq ($(KBUILD_HAVE_NLS),no)
 HOSTCFLAGS	+= -DKBUILD_NO_NLS
+else
+HOST_OS := $(shell uname -o)
+ifeq ($(HOST_OS),Cygwin)
+HOSTLOADLIBES_conf	= -lintl
+endif
+
+
 endif
 
 # generated files seem to need this to find local include files
Index: scripts/kconfig/lxdialog/check-lxdialog.sh
===
RCS file: /soft/cvs/Linux/kernel/linux/scripts/kconfig/lxdialog/check-lxdialog.sh,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- scripts/kconfig/lxdialog/check-lxdialog.sh	5 Mar 2007 13:02:59 -	1.1.1.1
+++ scripts/kconfig/lxdialog/check-lxdialog.sh	6 Mar 2007 10:08:36 -	1.2
@@ -19,6 +19,11 @@
 		echo '-lcurses'
 		exit
 	fi
+	$cc -print-file-name=libncurses.a | grep -q /
+	if [ $? -eq 0 ]; then
+		echo '-lintl -lncurses'
+		exit
+	fi
 	exit 1
 }
 

Re: [PATCH] RTC: Use fallback IRQ if PNP tables don't provide one

[Matthieu CASTET]

Hi,


On Mon, 28 May 2007 18:24:18 +0100, Matthew Garrett wrote:

> From: Matthew Garrett <[EMAIL PROTECTED]>
> 
> Intel Macs (and possibly other machines) provide a PNP entry for the
> RTC, but provide no IRQ. As a result the rtc-cmos driver doesn't allow
> wakeup alarms. If the RTC is located at the legacy ioport range, assume
> that it's on IRQ 8 unless the tables say otherwise.
I post something via gmane this morning, but it seems it was lost :

Did you check if there aren't multiple configuration for rtc (one with 
irq, and
one without it) ?

What's the ouput of 
$ for i in /sys/bus/pnp/devices/*; do if [ "$(cat $i/id)" = PNP0b00 ]; 
then cat
$i/resources; echo options; cat $i/options; fi; done

Matthieu

-
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: Enabling power states for Core 2 Duo

[Matthieu CASTET]

Hi,
Paa Paa  hotmail.com> writes:


> 
> But are you saying that with most desktop mobos one doesn't usually have the 
> different power states available at all? So basically the only means to 
> conserve power is to scale the frequency?
> 
Even frequency is very limited on core 2 duo. Because of the hight fbs, you can
scale only to 1.60 GHz  or  1.87 GHz for E6300


Matthieu

-
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: [PATCH] ubi: kill homegrown endian macros

[matthieu castet]

Hi,

David Woodhouse wrote:

On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be 
done byte per byte (but it could be the expected behavior if there 
unaligned access).


When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd used __attribute__((packed)) to be
safe, gcc would emit code to handle unaligned loads. But not in the
simple case where the struct has only one member.

Are you suggesting that this has changed since I did my testing?


here a small example I made and try with a sourcery 2006q3-27


/tmp/arm-2006q3/bin/arm-none-linux-gnueabi-gcc -S test.c -O3 -o 
test.s.packed

/tmp/arm-2006q3/bin/arm-none-linux-gnueabi-gcc -S test.c -DNOP -O3 -o test.s

$diff test.s test.s.packed 19,23c19,34
<   @ link register save eliminated.
<   ldrhr2, [r1, #0]
<   ldrhr1, [r0, #2]
<   ldr r0, [r0, #4]
<   @ lr needed for prologue
---
>   stmfd   sp!, {r4, r5, r6, lr}
>   ldrbr2, [r0, #5]@ zero_extendqisi2
>   ldrbr3, [r0, #4]@ zero_extendqisi2
>   mov lr, r1
>   ldrbr4, [r0, #6]@ zero_extendqisi2
>   ldrbr5, [r0, #3]@ zero_extendqisi2
>   ldrbr6, [r1, #1]@ zero_extendqisi2
>   orr r3, r3, r2, asl #8
>   ldrbr1, [r0, #2]@ zero_extendqisi2
>   ldrbip, [r0, #7]@ zero_extendqisi2
>   ldrbr2, [lr, #0]@ zero_extendqisi2
>   orr r3, r3, r4, asl #16
>   orr r0, r3, ip, asl #24
>   orr r1, r1, r5, asl #8
>   orr r2, r2, r6, asl #8
>   ldmfd   sp!, {r4, r5, r6, lr}


Matthieu
#include 
#ifdef NOP
#define jint32_t uint32_t
#define jint16_t uint16_t

#define je16_to_cpu(x) ((x))
#define je32_to_cpu(x) ((x))
#else

typedef struct {
uint32_t v32;
} __attribute__((packed)) jint32_t;

typedef struct {
uint16_t v16;
} __attribute__((packed)) jint16_t;
#define je16_to_cpu(x) ((x).v16)
#define je32_to_cpu(x) ((x).v32)
#endif
struct jffs2_sum_unknown_flash
{
	jint16_t nodetype;  /* node type */
};

struct jffs2_unknown_node
{
/* All start like this */
jint16_t magic;
jint16_t nodetype;
jint32_t totlen; /* So we can skip over nodes we don't grok */
jint32_t hdr_crc;
};


int boo(struct jffs2_unknown_node *node, void *sp)
{
	
	foo(je32_to_cpu(node->totlen), je16_to_cpu(node->nodetype), je16_to_cpu(((struct jffs2_sum_unknown_flash *)sp)->nodetype));
}

Re: [PATCH] ubi: kill homegrown endian macros

[matthieu castet]

David Woodhouse wrote:

On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:

On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:


On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy

When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd used __attribute__((packed)) to be
safe, gcc would emit code to handle unaligned loads. But not in the
simple case where the struct has only one member.

I don't think it is true.

When porting some summary stuff to bootloader, I hit some unaligned 
access problem :

in summary.c:405 there is a
switch (je16_to_cpu(((struct jffs2_sum_unknown_flash *)sp)->nodetype)) {
and
struct jffs2_sum_unknown_flash
{
jint16_t nodetype;  /* node type */
};

note that sp isn't aligned to a 32 bits boundary (it can be anything and 
depend for example of the size of the dirent name).


if gcc doesn't emit code to handle unaligned loads in this case, there 
is unaligned access.


When compiling my code for arm, I use a gcc-4.1.1 with a bug and it 
break. With another compiler (last gcc from codesourcery) it worked 
(because gcc emit load it bit per bit).





Are you suggesting that this has changed since I did my testing?


Which version of gcc did you try ?

Matthieu
-
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: [PATCH] ubi: kill homegrown endian macros

[Matthieu CASTET]

On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:

> On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> <[EMAIL PROTECTED]> wrote:
> 
> umm..  I'd say what you've done in there is an improvement to the
> exiting stuff: getting gcc to check it is better than having to use
> sparse.
> 
> I'd have expected gcc to generate poorer code with your approach but I'm
> showing zero text size changes from Christoph's patch (gcc-4.1 and
> gcc-3.4.5).
> 
>
On which arch did you try ?
X86 where unaligned access are ok ?

On arch that don't support aligned access, packed struct access will be 
done byte per byte (but it could be the expected behavior if there 
unaligned access).

Matthieu

-
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: [PATCH] ubi: kill homegrown endian macros

[Matthieu CASTET]

On Thu, 17 May 2007 16:32:01 +0200, Christoph Hellwig wrote:

> Kill ubis homegrown endianess handling crap and replace it with the
> normal kernel endianess handling.
> 
Hum, you should check about alignment stuff.
Jffs2 use a similar mechanism and the packed struct also take care of 
some unaligned data (present in summary node for example).

Matthieu

-
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: [patch] make pit clocksource continuous

[Matthieu CASTET]

Hi,

On Sun, 13 May 2007 19:36:12 +0200, Thomas Gleixner wrote:

> On Sun, 2007-05-13 at 21:23 +0400, Stas Sergeev wrote:
>> Hello.
>> 
>> Thomas Gleixner wrote:
>> >> Does this mean that on even an older
>> >> boards (without acpi at all) the hrtimers won't work?
>> > Not if PIT is the only clocksource available.
>> So you mean it can work without both the pm_timer and hpet? Sorry for
>> bothering you too much, but I am trying to use the hrtimers in my
>> driver module, so I'd like to know all the corner-cases.
> 
> It does _NOT_ work without pm_timer or hpet for the reasons explained
> before.
there something I don't understand : "pm_timer or hpet" aren't 
clockevent ?

Without acpi there should be still pit and tsc as clocksource ?

Also while talking about clockevent why rtc couldn't be used for that ?


Thanks

Matthieu

-
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/

PATCH : tuner-simple.c add suport for SECAM-BG with FI1216MF

[matthieu castet]

Hi,

this patch allow to use SECAM-BG with the FI1216MF tuner.


Matthieu

allow to use SECAM-BG with the FI1216MF tuner.

The selection is done with the secam=B module argument.
The default behaviour should be the same as before.

Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
Index: linux-2.6.21/drivers/media/video/tuner-simple.c
===
--- linux-2.6.21.orig/drivers/media/video/tuner-simple.c2007-05-05 
14:21:56.0 +0200
+++ linux-2.6.21/drivers/media/video/tuner-simple.c 2007-05-05 
14:33:58.0 +0200
@@ -205,9 +205,13 @@
/* 0x01 -> ??? no change ??? */
/* 0x02 -> PAL BDGHI / SECAM L */
/* 0x04 -> ??? PAL others / SECAM others ??? */
-   cb &= ~0x02;
-   if (t->std & V4L2_STD_SECAM)
-   cb |= 0x02;
+   cb &= ~0x03;
+   if (t->std & V4L2_STD_SECAM_L) //also valid for V4L2_STD_SECAM 
+   cb |= PHILIPS_MF_SET_PAL_L;
+   else if (t->std & V4L2_STD_SECAM_LC) 
+   cb |= PHILIPS_MF_SET_PAL_L2;
+   else /* V4L2_STD_B|V4L2_STD_GH */
+   cb |= PHILIPS_MF_SET_BG;
break;
 
case TUNER_TEMIC_4046FM5:

RFC airo : wpa support

[matthieu castet]

Hi,

I attach a diff against 2.6.21 for adding wpa support for airo driver.
In then end of 2005 I manage to make work wpa but the code was really 
ugly. I manage to find some time to clean it.



To support wpa, a new interface of the firmware should be used. This 
interface is incompatible with the old interface and using both 
interface at the same time make the firmware hang.


Porting OPEN and WEP mode to new interface need some driver rewrite, and 
the old interface should be keep for the older cards (or the cards that 
doesn't have newer firmware).
That's why I didn't do it, and I added a module parameter for choosing 
between the old driver behavior (with no wpa support) or the driver with 
wpa only support.



The wireless extension handlers are a bit ugly, I will be very happy, if 
somebody could help me to clean them.


Any comments are appreciated.


Matthieu


PS : the lastest version of the driver can be found in 
http://svn.gna.org/viewcvs/airo-wpa/branches/kernel/


PS2 : There is some remaining trace in the driver for debug purpose, 
that will be removed in the final version
Index: airo.c
===
--- airo.c	(revision 16)
+++ airo.c	(working copy)
@@ -16,6 +16,7 @@
 Code was also integrated from the Cisco Aironet driver for Linux.
 Support for MPI350 cards was added by Fabrice Bellet
 <[EMAIL PROTECTED]>.
+(C) 2005-2007 Matthieu CASTET <[EMAIL PROTECTED]> for WPA support
 
 ==*/
 
@@ -91,6 +92,12 @@
 #include 
 #endif
 
+/* enable rx mic checking
+ *disable because it takes some time in ISR
+ * XXX crypto doesn't work anymore in ISR on 2.6.21
+ */
+//#define WPA_CHECK_RX_MIC
+
 /* Hack to do some power saving */
 #define POWER_ON_DOWN
 
@@ -223,6 +230,7 @@
 int maxencrypt /* = 0 */; /* The highest rate that the card can encrypt at.
 		   0 means no limit.  For old cards this was 4 */
 
+static int wpa_enabled; /* If set the card is in WPA mode. This is incompatible with WEP or open mode */
 static int auto_wep /* = 0 */; /* If set, it tries to figure out the wep mode */
 static int aux_bap /* = 0 */; /* Checks to see if the aux ports are needed to read
 		the bap, needed on some older cards and buses. */
@@ -250,6 +258,9 @@
 module_param_array(rates, int, NULL, 0);
 module_param_array(ssids, charp, NULL, 0);
 module_param(auto_wep, int, 0);
+module_param(wpa_enabled, int, 0);
+MODULE_PARM_DESC(wpa_enabled, "If non-zero, the driver can use WPA \
+but Open and WEP mode won't be possible");
 MODULE_PARM_DESC(auto_wep, "If non-zero, the driver will keep looping through \
 the authentication options until an association is made.  The value of \
 auto_wep is number of the wep keys to check.  A value of 2 will try using \
@@ -452,6 +463,7 @@
 #define RID_UNKNOWN22  0xFF22
 #define RID_LEAPUSERNAME 0xFF23
 #define RID_LEAPPASSWORD 0xFF24
+#define RID_WPA0xFF25
 #define RID_STATUS 0xFF50
 #define RID_BEACON_HST 0xFF51
 #define RID_BUSY_HST   0xFF52
@@ -506,6 +518,14 @@
 	u8 key[16];
 } WepKeyRid;
 
+typedef struct {
+	u16 len;
+	u16 kindex;
+	u8 mac[ETH_ALEN];
+	u16 klen;
+	u8 key[48];
+} WpaKeyRid;
+
 /* These structures are from the Aironet's PC4500 Developers Manual */
 typedef struct {
 	u16 len;
@@ -525,7 +545,20 @@
 #define MOD_MOK 2
 } ModulationRid;
 
+/* Only present on firmware >= 5.30.17 */
 typedef struct {
+	u16 _reserved5[4];
+	u16 auth_cipher;
+#define AUTH_CIPHER_NONE 1
+#define AUTH_CIPHER_WEP 0xc
+#define AUTH_CIPHER_TKIP 0x210
+	u16 auth_key;
+#define AUTH_KEY_MGMT_NONE 1
+#define AUTH_KEY_MGMT_802_1X 4
+#define AUTH_KEY_MGMT_PSK 8
+} ConfigRidExtra;
+
+typedef struct {
 	u16 len; /* sizeof(ConfigRid) */
 	u16 opmode; /* operating mode */
 #define MODE_STA_IBSS 0
@@ -580,6 +613,7 @@
 #define AUTH_ENCRYPT 0x101
 #define AUTH_SHAREDKEY 0x102
 #define AUTH_ALLOW_UNENCRYPTED 0x200
+#define AUTH_ENCRYPT_WPA 0xc101
 	u16 associationTimeout;
 	u16 specifiedApTimeout;
 	u16 offlineScanInterval;
@@ -643,6 +677,8 @@
 #define MAGIC_STAY_IN_CAM (1<<10)
 	u8 magicControl;
 	u16 autoWake;
+	/* Only present on firmware >= 5.30.17 */
+	ConfigRidExtra extra;
 } ConfigRid;
 
 typedef struct {
@@ -1227,6 +1263,15 @@
 	unsigned int bssListFirst;
 	unsigned int bssListNext;
 	unsigned int bssListRidLen;
+	unsigned int ConfigRidLen;
+	unsigned char wpa_tx_key [8];
+	unsigned char wpa_rx_key [8];
+	unsigned char wpa_rx_key_m [8];
+	unsigned char wpa_rx_key_m_old [8];
+	u8 LLC [10];
+	struct crypto_hash *tfm_michael;
+	int wpa_enabled;
+	int wpa_key_enabled;
 
 	struct list_head network_list;
 	struct list_head network_free_list;
@@ -1723,6 +1768,55 @@
 	digest[3] = val & 0xFF;
 }
 
+static void wpa_compute_mic(struct airo_info *ai ,char *pPacket, u8 *mic, int len, char *key)
+{
+	struct scatterlist sg[3];
+	struct hash_desc desc;
+
+	sg[0].page = virt_to_page(pP

Re: High Resolution Timer DOS

[matthieu castet]

Ingo Molnar wrote:

* Lee Revell <[EMAIL PROTECTED]> wrote:

Well, it is not really a DoS. The rescheduling of the process is 
limited by the scheduler and the available CPU time (depending on 
the number of runnable tasks in the system).
Shouldn't an unprivileged process be rate limited somehow to avoid 
flooding the machine with interrupts?  We restrict nonroot users from 
setting the RTC interrupt rate higher than 64Hz for a similar reason 
(granted, this limit dates back to the 486 days and should probably be 
increased to 1024 Hz).


No. An interrupt in this case is really just 'CPU time used up', and an 
unprivileged process can take up as much CPU time as the scheduler 
allows. So it's _not_ a DoS, and neither is any other unprivileged 
infinit loop (or high-rate context-switching task) a DoS.
Ok, may be DOS was not the correct term, but with the 2.6.21 hrt there 
is a great difference between an infinite loop and the high-rate 
context-switching task (you can try attached programs).
With the first I the system is still responsive, with the latter it 
isn't (new process take lot's of time to get created, other process are 
very slow).
If it is "just 'CPU time used up'", why I see a such difference between 
the 2 cases ?


Maybe the current scheduler failed to handle correctly this case ?


Matthieu
#include 
#include 
#include 

int main()
{
	struct timeval tv;
	while (1)
		gettimeofday(&tv, NULL);
}
int main()
{
	while (1)
		usleep(1);
}

High Resolution Timer DOS

[matthieu castet]

Hi,

some programs need to do some short of busyloop. It was often 
implemented as :


while (1) {
if (can_do_stuff) {
do_stuff();
}
else
//sleep a very short of time
usleep(1);
}

usleep(1) or equivalent where used instead of sched_yield, because of 
some priority issue. IIRC doing sched_yield, make the process appears 
like an interactive process, so it has better priority and get call more 
often.


But now if high res timer are enabled, these programs while cause 
something like a DOS : the context switch per second will be bigger than 
500 000 and the cpu usage will be very high.



I don't know if such problem are already know, but I believe a warning 
about such issues should be in the Kconfig description.



Matthieu
-
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: [GIT PATCH] UIO patches for 2.6.21

[Matthieu CASTET]

Hi,

On Fri, 27 Apr 2007 15:49:57 -0700, Greg KH wrote:

> Here are the updated UIO (Userspace I/O driver framework) patches for
> 2.6.21.
> 

> 
>  Documentation/DocBook/kernel-api.tmpl |4 +
>  Documentation/DocBook/uio-howto.tmpl  |  498 +++
>  drivers/Kconfig   |1 + drivers/Makefile
>   |1 + drivers/uio/Kconfig   |   27 ++
>  drivers/uio/Makefile  |2 + drivers/uio/uio.c   
>   |  702 +
>  drivers/uio/uio_cif.c |  156 
>  include/linux/uio_driver.h|   91 + 9 files changed,
>  1482 insertions(+), 0 deletions(-) create mode 100644
>  Documentation/DocBook/uio-howto.tmpl create mode 100644
>  drivers/uio/Kconfig create mode 100644 drivers/uio/Makefile create mode
>  100644 drivers/uio/uio.c
>  create mode 100644 drivers/uio/uio_cif.c create mode 100644
>  include/linux/uio_driver.h
> 
uio_dummy.c (that should be present according documentation) seems 
missing.

I find the doc not very clear for the devices where there is no 
interrupt : they speak of some kernel timer, but a userspace timer could 
be used (and even the userspace driver could be written without kernel 
support at all).

At the end of the doc there is something about IRQ_HANDLED vs IRQ_NONE.
Last time I check kernel irq code, in both case next irq handler are 
called. The only difference was that if all handler reply IRQ_NONE, the 
kernel gave an error about an unexpected interrupt.

Also why sysfs is used for describing the mapping instead of something 
like an ioctl ?
UIO could be useful in embedded system where sysfs is not always 
desirable.


Matthieu

-
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: [PATCH] Allow kernel to build on Cygwin

[Matthieu CASTET]

Hi,

Deepak Saxena  plexity.net> writes:

> 
> 
> This patch contains a set of small fixes to allow the kernel to build under
> the Cygwin environment, which is unfortunately used by more people than
> one would think in the embedded world. :(
Yes, I did similar patch, and there are needed for everything (busybox, 
glibc, ...)
-D LKC_DIRECT_LINK
> 
> +HOST_OS := $(shell uname -o)
> +ifeq ($(HOST_OS),Cygwin)
> +HOSTLOADLIBES_mconf  = -lintl
> +HOSTLOADLIBES_conf   = -lintl
> +endif
> +
Hum, this test should be done if we detect nls support. See ifeq
($(KBUILD_HAVE_NLS),no) ...



> --- a/scripts/kconfig/lxdialog/check-lxdialog.sh
> +++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
>  -4,6 +4,10  # Check ncurses compatibility
>  # What library to link
>  ldflags()
>  {
> + if [ "`uname -o`" == "Cygwin" ]; then
> + echo '-lintl -lncurses'
> + exit
> + fi
You should test against libncurses.a and not hardcode it for cygwin...

Matthieu



-
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: [RFC] MTD driver for MMC cards

[Matthieu CASTET]

On Sun, 31 Dec 2006 13:32:18 +0100, Pierre Ossman wrote:

> Arnd Bergmann wrote:
 
 
> I'm a complete MTD noob, but what uses does the MTD layer have besides
> JFFS2. If it's none, than this advantage isn't that big of a deal.
> 
AFAIK MTD is for device where erase is need to managed in "software" :
http://www.linux-mtd.infradead.org/faq/general.html


For SD card, doesn't a microcontroller on the card hide this, and make the
sd card acts like a normal block device (no need to erase a block before
writing it)?

-
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: how to create atm interface in linux

[Matthieu CASTET]

Le Tue, 06 Sep 2005 14:43:35 +0100, manomugdha biswas a écrit :

> Hi,
> I want to create an ATM interface on linux. I can
> create ethernet interface using alloc_etherdev() and
> then registering this device. Can I use the same
> function to create atm interface ? Or there is other
> way to do this? Can you please give some light on this
> issue?
> 
look how it is done in net/atm driver

Hint : use alloc_netdev

Matthieu

-
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: Patch for link detection for R8169

[Matthieu CASTET]

Le Tue, 06 Sep 2005 16:32:39 +0200, Miroslaw Mieszczak a écrit :

> There is a patch to driver of RLT8169 network card. This match make 
> possible detection of the link status even if network interface is down.
> This is usefull for laptop users.
> 
> 
> 
> --- r8169.c   2005-09-02 15:34:52.0 +0200
> +++ linux/drivers/net/r8169.c 2005-09-05 21:11:15.0 +0200
> @@ -538,14 +538,27 @@
>  
>  static unsigned int rtl8169_tbi_link_ok(void __iomem *ioaddr)
>  {
> - return RTL_R32(TBICSR) & TBILinkOk;
> + return (RTL_R32(TBICSR) & TBILinkOk) == TBILinkOk ? 1:0;
>  }
>  
>  static unsigned int rtl8169_xmii_link_ok(void __iomem *ioaddr)
>  {
> - return RTL_R8(PHYstatus) & LinkStatus;
> + return (RTL_R8(PHYstatus) & LinkStatus) == LinkStatus ? 1:0;
>  }
>  
(a==b)?1:0 is stupid just use (a==b) ...
And in this case I am sure we care only if it is null or non-null,
so there no need to change that...

-
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: R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1

[matthieu castet]

Giampaolo Tomassoni wrote:

-Messaggio originale-
Da: Francois Romieu [mailto:[EMAIL PROTECTED]
Inviato: domenica 4 settembre 2005 17.33
A: Giampaolo Tomassoni
Cc: linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]
Oggetto: Re: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1

...omissis...

I'd be happily surprized to see more documented ADSL PCI/USB device in the
near future. :o(



OT Question. What about an open adsl device? The linux community had been 
bumped out by the adsl market for at least a couple of years, and nobody knows 
(or tells) why...

That could be a definitive answer. Is there anybody interested in this?


The problem is that lot's of new devices implement part of their dsp 
function in the kernel space instead of in the device.
And as company don't want to publish their dsp algorith and open source 
it, we can't have open source driver for it.


That the case for bewan device (that even include a libm in their 
source) and for pulsar pci device...

-
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/

[PATCH] PNPACPI: clean blacklist

[matthieu castet]

Hi,

this patch clean the blacklist and should be applied after "only parse 
device that have CRS method" patch:

Battery, Button, Fan don't have a CRS and should be removed.
PCI root, PIC, Timer are in pnpbios and are harmless.


Please comment and consider for inclusion.

Thanks,

Matthieu
Index: linux-2.6.13rc/drivers/pnp/pnpacpi/core.c
===
--- linux-2.6.13rc.orig/drivers/pnp/pnpacpi/core.c	2005-08-28 19:26:35.0 +0200
+++ linux-2.6.13rc/drivers/pnp/pnpacpi/core.c	2005-08-28 19:34:30.0 +0200
@@ -27,15 +27,15 @@
 
 static int num = 0;
 
+/* We need only to blacklist device that have already an acpi driver that
+ * can't use pnp layer. We don't need to blacklist device that are directly 
+ * used by the kernel (PIC, Timer, ...), as it is harmless and there were
+ * already present in pnpbios. Finaly only devices that have a CRS method
+ * need to be in this list.
+ */
 static char __initdata excluded_id_list[] =
-	"PNP0C0A," /* Battery */
-	"PNP0C0C,PNP0C0E,PNP0C0D," /* Button */
 	"PNP0C09," /* EC */
-	"PNP0C0B," /* Fan */
-	"PNP0A03," /* PCI root */
 	"PNP0C0F," /* Link device */
-	"PNP," /* PIC */
-	"PNP0100," /* Timer */
 	;
 static inline int is_exclusive_device(struct acpi_device *dev)
 {

[PATCH] PNPACPI: only parse device that have CRS method

[matthieu castet]

Hi,

this patch blacklist device that don't have CRS method as there are 
useless for pnp layer as they don't provide any resource.


Please comment and consider for inclusion.

Thanks,

Matthieu
Index: linux-2.6.13rc/drivers/pnp/pnpacpi/core.c
===
--- linux-2.6.13rc.orig/drivers/pnp/pnpacpi/core.c	2005-08-28 19:24:40.0 +0200
+++ linux-2.6.13rc/drivers/pnp/pnpacpi/core.c	2005-08-28 19:26:35.0 +0200
@@ -131,7 +131,8 @@
 	struct pnp_id *dev_id;
 	struct pnp_dev *dev;
 
-	if (!ispnpidacpi(acpi_device_hid(device)) ||
+	status = acpi_get_handle(device->handle, "_CRS", &temp);
+	if (ACPI_FAILURE(status) || !ispnpidacpi(acpi_device_hid(device)) ||
 		is_exclusive_device(device))
 		return 0;
 

Re: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Hi,

Shaohua Li wrote:

On Wed, 2005-08-03 at 23:16 +0200, matthieu castet wrote:

There are drivers/acpi/motherboard.c that done some stuff already handle 
by pnp/system.c.


Yes, it should be disabled if pnpacpi is enabled. 

But even if pnpacpi is disabled, pnp/system.c sould work with pnpbios.

The only concern is
motherboard.c also request some ACPI resources, which might not declaim
in ACPI motherboard device, but it's completely BIOS dependent. We might
could try remove it at -mm tree to see if it breaks any system later.



Ok,
may be we should split in 2 modules : the one that request some ACPI 
resources and the other that use PNP resource.
PS : I saw in acpi ols paper that you plan once all dupe acpi drivers 
will be removed to register again the pnp device in acpi layer. Do you 
plan to add more check and for example add only device that have a CRS 
in pnp layer ?


For detecting PNP device? it's worthy trying.



I will send a patch for that.

Matthieu
-
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: [PATCH] PNPACPI: fix IRQ and 64-bit address decoding

[matthieu castet]

Bjorn Helgaas wrote:

Maybe the third time's the charm :-)  Added a bugfix
(pcibios_penalize_isa_irq()) and a workaround for HP
HPET firmware description since last time.  The workaround
accepts stuff that is illegal according to the spec,
so speak up if you think this is a problem.  It seems
fairly safe to me.


May be print some warnings if the acpi is broken...


Matthieu
-
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: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Bjorn Helgaas wrote:

On Thursday 04 August 2005 6:38 am, matthieu castet wrote:


Bjorn Helgaas wrote:


On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:


Bjorn Helgaas wrote:


drivers/char/hpet.c
This probably should be converted to PNP.  I'll
look into doing this.


IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
memory adress for hpet correctly. But it would be nice if it works.


You're right, this was broken.  But I've been pushing a PNPACPI
patch to fix this.



Yes but is ACPI_RSTYPE_ADDRESS64 possible on 32 bit machine ?



I can't think of a case where that would make sense, but I don't
actually know the answer.


In this case your patch won't work as res->mem_resource[i].start and 
res->mem_resource[i].end are unsigned long, and 64 bit value won't fit.



True.  But fixing that would be pretty far-reaching (changing struct
resource), so I'm not worried until it is shown to be a problem.

Ok, may be you could add a BUG_ON(sizeof(long)==4) for 
ACPI_RSTYPE_ADDRESS64.


Matthieu

-
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: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Hi,

Bjorn Helgaas wrote:

On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:


Bjorn Helgaas wrote:
>drivers/char/hpet.c
>This probably should be converted to PNP.  I'll
>look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
memory adress for hpet correctly. But it would be nice if it works.



You're right, this was broken.  But I've been pushing a PNPACPI
patch to fix this.



Yes but is ACPI_RSTYPE_ADDRESS64 possible on 32 bit machine ?
In this case your patch won't work as res->mem_resource[i].start and 
res->mem_resource[i].end are unsigned long, and 64 bit value won't fit.


Matthieu
-
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: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Hi,

Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
>

>
>>Did you have plan to remove other
>>legacy acpi drivers?
>
>
> No, I didn't -- which ones are you thinking about?  Looking at
> the callers of acpi_bus_register_driver(), I see:
looking for METHOD_NAME__CRS is more acurate.
>
>arch/ia64/hp/common/sba_iommu.c
>Probably can't be converted because it needs the
>ACPI handle to extract a vendor-specific data
>item from _CRS.
>
>drivers/char/hpet.c
>This probably should be converted to PNP.  I'll
>look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
memory adress for hpet correctly. But it would be nice if it works.


There are drivers/acpi/motherboard.c that done some stuff already handle 
by pnp/system.c.


There was an extention of a floppy driver in order to use acpi in -mm, 
but it seems to have been dropped.


>
> Then of course, there are a bunch of things in drivers/acpi/
> (battery, button, fan, ec, etc).  I expect the reason they are
> in drivers/acpi/ is because they need ACPI-specific functionality,
> so they probably couldn't be converted to PNP.
yes.


Matthieu

PS : I saw in acpi ols paper that you plan once all dupe acpi drivers 
will be removed to register again the pnp device in acpi layer. Do you 
plan to add more check and for example add only device that have a CRS 
in pnp layer ?


PPS : is there any plan to integrate 
http://marc.theaimsgroup.com/?l=linux-kernel&m=111827568001255&w=2 that 
seem to fix some init problem ?

-
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: OOPS: frequent crashes with bttv in 2.6.X series (inc. 2.6.12)

[matthieu castet]

Hi,

Mauro Carvalho Chehab wrote:

Jeremy,

BTTV cards uses massive data transfer via DMA when you are watching TV,
transfering one screen every 1/30 s. Maybe you are suffering from a
trouble on your motherboard or at board physical connection.


I had (have ?) similar problem with a bt878 :
if I use bttv orverlay and do disk IO (a `grep toto /usr' for example), 
there quickly RISC corruption message and my log and also ext3 
corruption (that's why except for recovering epg data, I don't use 
anymore my card).
There were a similar report were someone and mozilla corruption when 
watching tv.



When using gradisplay, I don't saw faillure, but I don't try for a long 
time.


Jeremy do you use overlay or gradisplay ?

Matthieu
-
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: ide-cd and bad sectors

[matthieu castet]

Hi Alan,

Alan Cox wrote:

On Sad, 2005-07-02 at 15:14, matthieu castet wrote:

Also I was wondering if all the sector that ide-cd failed to read are 
bad sector, or if ide-cd failed to put the drive in a consistent state 
for reading the next sector after corrupted one.



ide-cd wrongly errors all the sectors around an error, ide-scsi gets it
right if the IDE firmware does. I sent Bartlomiej patches to fix that
and I believe he accepted them


thanks,

they don't seem to be in his tree : 
http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fbart%2Fide-2.6.git&a=search&s=ide-cd 
:(


Matthieu
-
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: forkbombing Linux distributions

[Matthieu Castet]

> The memory limits aren't good enough either: if you set them low
> enough that memory-forkbombs are unperilous for
> RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> applications.

yes, if you want to run application like openoffice.org you need at
least 200Mo. If you want that your system is usable, you need at least 40 
process per user. So 40*200 = 8Go, and it don't think you have all this 
memory...

I think per user limit could be a solution.

attached a small fork-memory bombing.

Matthieu
int main()
{
	while(1){
		while(fork()){
			malloc(1);
		}
	}
}

Re: bttv : overlay mode and big disk io hang and could corrupt the fs

[matthieu castet]

Hi,
matthieu castet wrote:
Hi,
if I run "xawtv" [1] and then do a "grep -r toto /usr", my system 
quickly freeze. If there isn't any xawv running nothing happen. I don't 
try to use xawtv with grab mode (port 54) because I don't want to loose 
data by crashing again my / fs.

I retry it and I arrived to get some log (see the attach file).
But after rebooting, I had a big surprise, the / ext3 fs was corrupted 
and I need to run fsck by hand 

Matthieu
I have done other tests.
If I use grabdisplay mode the problem doesn't occur.
If using overlay mode with port 54 the problem is present.
I have also try the cvs bttv driver and the problem isn't fixed.
Can someone look at it?
It seem that something is corrupting kernel memory because usb failed & 
ext3 failed...

I attached a new log when the problem appear.
Note that there are similitude with 
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0881.html and 
http://marc.theaimsgroup.com/?t=11053154392&r=1&w=2

Matthieu

[1]
$xawtv -hwscan
This is xawtv-3.94, running on Linux/i686 (2.6.10)
looking for available devices
port 53-53  [ -xvport 53 ]
type : Xvideo, video overlay
name : video4linux
port 54-54
type : Xvideo, image scaler
name : NV Video Overlay
port 55-86
type : Xvideo, image scaler
name : NV Video Blitter
/dev/video0: OK [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Pinnacle PCTV Stud
flags: overlay capture tuner
Feb 12 12:08:33 localhost kernel: Linux video capture interface: v1.00
Feb 12 12:08:33 localhost kernel: bttv: driver version 0.9.15 loaded
Feb 12 12:08:33 localhost kernel: bttv: snapshot date 2005-02-10
Feb 12 12:08:33 localhost kernel: bttv: using 8 buffers with 2080k (520 pages) 
each for capture
Feb 12 12:08:33 localhost kernel: bttv: Bt8xx card found (0).
Feb 12 12:08:33 localhost kernel: ACPI: PCI interrupt :00:0a.0[A] -> GSI 17 
(level, low) -> IRQ 17
Feb 12 12:08:33 localhost kernel: bttv0: Bt878 (rev 17) at :00:0a.0, irq: 
17, latency: 32, mmio: 0xddcfe000
Feb 12 12:08:33 localhost kernel: bttv0: detected: Pinnacle PCTV [card=39], PCI 
subsystem ID is 11bd:0012
Feb 12 12:08:33 localhost kernel: bttv0: using: Pinnacle PCTV Studio/Rave 
[card=39,insmod option]
Feb 12 12:08:33 localhost kernel: bttv0: gpio: en=, out= 
in=00ff27ff [init]
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no
Feb 12 12:08:33 localhost kernel: bttv0: using tuner=3
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9887 @ 0x86... 
not found
Feb 12 12:08:34 localhost kernel: tuner: chip found at addr 0xc0 i2c-bus bt878 
#0 [sw]
Feb 12 12:08:34 localhost kernel: tuner: type set to 3 (Philips (SECAM+PAL_BG) 
(FI1216MF, FM1216MF, FR1216MF))
Feb 12 12:08:34 localhost kernel: bttv0: registered device video0
Feb 12 12:08:34 localhost kernel: bttv0: registered device vbi0
Feb 12 12:08:34 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
Feb 12 12:09:14 localhost kernel: tuner: tv freq set to 208.00
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:49 localhost kernel: bttv0: OCERR @ 3328b01c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_u

bttv : overlay mode and big disk io hang and could corrupt the fs

[matthieu castet]

Hi,
if I run "xawtv" [1] and then do a "grep -r toto /usr", my system 
quickly freeze. If there isn't any xawv running nothing happen. I don't 
try to use xawtv with grab mode (port 54) because I don't want to loose 
data by crashing again my / fs.

I retry it and I arrived to get some log (see the attach file).
But after rebooting, I had a big surprise, the / ext3 fs was corrupted 
and I need to run fsck by hand 

Matthieu

[1]
$xawtv -hwscan
This is xawtv-3.94, running on Linux/i686 (2.6.10)
looking for available devices
port 53-53  [ -xvport 53 ]
type : Xvideo, video overlay
name : video4linux
port 54-54
type : Xvideo, image scaler
name : NV Video Overlay
port 55-86
type : Xvideo, image scaler
name : NV Video Blitter
/dev/video0: OK [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Pinnacle PCTV Stud
flags: overlay capture tuner
$cat /proc/interrupts
   CPU0
  0: 654027IO-APIC-edge  timer
  1:   2679IO-APIC-edge  i8042
  7:  0IO-APIC-edge  parport0
  9:  0   IO-APIC-level  acpi
 12:  23644IO-APIC-edge  i8042
 14:  88469IO-APIC-edge  ide0
 15:  2IO-APIC-edge  ide1
 17:  5   IO-APIC-level  eth0, bttv0, Bt87x audio
 18: 48   IO-APIC-level  ide2, ide3
 19:  0   IO-APIC-level  EMU10K1
 21:  97526   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:  0   IO-APIC-level  VIA8233
NMI:  0
LOC: 661965
ERR:  0
MIS:  0
Feb  9 01:20:32 localhost kernel: ehci_hcd :00:10.3: fatal error
Feb  9 01:20:32 localhost kernel: ehci_hcd :00:10.3: HC died; cleaning up
Feb  9 01:20:32 localhost kernel: bttv0: OCERR @ 3635001c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (0)
Feb  9 01:20:32 localhost last message repeated 11 times
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (63)
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (0)
Feb  9 01:20:32 localhost kernel: bttv0: OCERR @ 3635001c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
n

Re: [bug] pnp_register_card_driver/pnp_unregister_card_driver

[matthieu castet]

Hi,
Adam Belay wrote:
On Mon, Feb 07, 2005 at 08:33:47PM +0100, matthieu castet wrote:
Hi,
pnp_register_driver could fail and return <0 result, in this case the 
driver shouldn't be pnp_unregister_driver.

But if you look in pnp_register_card_driver, the result isn't checked. 
And it is always pnp_unregister_driver in pnp_unregister_card_driver.

I know that pnp_register_card_driver shouldn't fail in normal condition, 
but who know...

Matthieu

Yeah, you're right.  I'm probably going to do something like this.
If you do something like this there will be some broken driver to 
correct. See [1] for isa alsa driver that assume that the result is >=0.

Matthieu
[1]
$grep -rI pnp_register_card_driver /usr/src/linux/sound/isa/
/usr/src/linux/sound/isa/cs423x/cs4236.c:   cards += 
pnp_register_card_driver(&cs423x_pnpc_driver);
/usr/src/linux/sound/isa/gus/interwave.c:   i = 
pnp_register_card_driver(&interwave_pnpc_driver);
/usr/src/linux/sound/isa/sb/es968.c:int cards = 
pnp_register_card_driver(&es968_pnpc_driver);
/usr/src/linux/sound/isa/sb/sb16.c: i = 
pnp_register_card_driver(&sb16_pnpc_driver);
/usr/src/linux/sound/isa/als100.c:  cards += 
pnp_register_card_driver(&als100_pnpc_driver);
/usr/src/linux/sound/isa/sscape.c:  ret = 
pnp_register_card_driver(&sscape_pnpc_driver);
/usr/src/linux/sound/isa/opti9xx/opti92x-ad1848.c:  cards = 
pnp_register_card_driver(&opti9xx_pnpc_driver);
/usr/src/linux/sound/isa/ad1816a/ad1816a.c: cards += 
pnp_register_card_driver(&ad1816a_pnpc_driver);
/usr/src/linux/sound/isa/wavefront/wavefront.c: cards += 
pnp_register_card_driver(&wavefront_pnpc_driver);
/usr/src/linux/sound/isa/dt019x.c:  cards += 
pnp_register_card_driver(&dt019x_pnpc_driver);
/usr/src/linux/sound/isa/es18xx.c:  i = 
pnp_register_card_driver(&es18xx_pnpc_driver);
/usr/src/linux/sound/isa/azt2320.c: cards += 
pnp_register_card_driver(&azt2320_pnpc_driver);
/usr/src/linux/sound/isa/opl3sa2.c: cards += 
pnp_register_card_driver(&opl3sa2_pnpc_driver);
/usr/src/linux/sound/isa/cmi8330.c: cards += 
pnp_register_card_driver(&cmi8330_pnpc_driver);
-
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] pnp_register_card_driver/pnp_unregister_card_driver

[matthieu castet]

Hi,
pnp_register_driver could fail and return <0 result, in this case the 
driver shouldn't be pnp_unregister_driver.

But if you look in pnp_register_card_driver, the result isn't checked. 
And it is always pnp_unregister_driver in pnp_unregister_card_driver.

I know that pnp_register_card_driver shouldn't fail in normal condition, 
but who know...

Matthieu
-
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: [PATCH] PNP support for i8042 driver

[matthieu castet]

Hi,
Vojtech Pavlik wrote:
On Fri, Feb 04, 2005 at 06:37:29PM +0100, matthieu castet wrote:
Hi,
Vojtech Pavlik wrote:
On Sat, Nov 13, 2004 at 02:23:53PM +0100, matthieu castet wrote:

Hi,
this patch add PNP support for the i8042 driver in 2.6.10-rc1-mm5. Acpi 
is try before the pnp driver so if you don't disable ACPI or apply 
others pnpacpi patches, it won't change anything.

Please review it and apply if possible

Ok, my thoughts on this:
It's OK to keep the device allocated to this driver via the PnP
  subsystem, and not bother with releasing the code via
__initcall.
I agree that if there is a way to enumerate the device, (like
PnP, ACPI or OpenFirmware), we should use that instead of
probing and using a platform device for the controller.
I think that we should drop the ACPI support from i8042, in
favor of pnpacpi, because PnP is more generic and if the
keyboard device was listed in PnPBIOS instead of ACPI, it'll
still work.
Any news about this ?
 
Sort of fell off my radar, can you resend?

attached 2 versions : the one that kill acpi detection and the one with
acpi but a complex init.
Matthieu
PS : I resend it, because, it seem it have failed for Vojtech Pavlik.
Index: drivers/input/serio/i8042-x86ia64io.h
===
RCS file: /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/input/serio/i8042-x86ia64io.h,v
retrieving revision 1.2
diff -u -u -r1.2 i8042-x86ia64io.h
--- drivers/input/serio/i8042-x86ia64io.h	4 Jan 2005 08:06:19 -	1.2
+++ drivers/input/serio/i8042-x86ia64io.h	4 Feb 2005 22:37:12 -
@@ -88,183 +88,113 @@
 };
 #endif
 
-#ifdef CONFIG_ACPI
-#include 
-#include 
-
-struct i8042_acpi_resources {
-	unsigned int port1;
-	unsigned int port2;
-	unsigned int irq;
-};
+#ifdef CONFIG_PNP
+#include 
 
-static int i8042_acpi_kbd_registered;
-static int i8042_acpi_aux_registered;
+static int i8042_pnp_kbd_registered;
+static int i8042_pnp_aux_registered;
 
-static acpi_status i8042_acpi_parse_resource(struct acpi_resource *res, void *data)
-{
-	struct i8042_acpi_resources *i8042_res = data;
-	struct acpi_resource_io *io;
-	struct acpi_resource_fixed_io *fixed_io;
-	struct acpi_resource_irq *irq;
-	struct acpi_resource_ext_irq *ext_irq;
-
-	switch (res->id) {
-		case ACPI_RSTYPE_IO:
-			io = &res->data.io;
-			if (io->range_length) {
-if (!i8042_res->port1)
-	i8042_res->port1 = io->min_base_address;
-else
-	i8042_res->port2 = io->min_base_address;
-			}
-			break;
-
-		case ACPI_RSTYPE_FIXED_IO:
-			fixed_io = &res->data.fixed_io;
-			if (fixed_io->range_length) {
-if (!i8042_res->port1)
-	i8042_res->port1 = fixed_io->base_address;
-else
-	i8042_res->port2 = fixed_io->base_address;
-			}
-			break;
-
-		case ACPI_RSTYPE_IRQ:
-			irq = &res->data.irq;
-			if (irq->number_of_interrupts > 0)
-i8042_res->irq =
-	acpi_register_gsi(irq->interrupts[0],
-			  irq->edge_level,
-			  irq->active_high_low);
-			break;
-
-		case ACPI_RSTYPE_EXT_IRQ:
-			ext_irq = &res->data.extended_irq;
-			if (ext_irq->number_of_interrupts > 0)
-i8042_res->irq =
-	acpi_register_gsi(ext_irq->interrupts[0],
-			  ext_irq->edge_level,
-			  ext_irq->active_high_low);
-			break;
-	}
-	return AE_OK;
-}
 
-static int i8042_acpi_kbd_add(struct acpi_device *device)
+static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id *did)
 {
-	struct i8042_acpi_resources kbd_res;
-	acpi_status status;
-
-	memset(&kbd_res, 0, sizeof(kbd_res));
-	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- i8042_acpi_parse_resource, &kbd_res);
-	if (ACPI_FAILURE(status))
-		return -ENODEV;
-
-	if (kbd_res.port1)
-		i8042_data_reg = kbd_res.port1;
+	if (pnp_port_valid(dev, 0) && pnp_port_len(dev, 0) == 1)
+		i8042_data_reg = pnp_port_start(dev,0);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no data port; default is 0x%x\n",
-			acpi_device_bid(device), i8042_data_reg);
+		printk(KERN_WARNING "PNP: [%s] has no data port; default is 0x%x\n",
+			pnp_dev_name(dev), i8042_data_reg);
 
-	if (kbd_res.port2)
-		i8042_command_reg = kbd_res.port2;
+	if (pnp_port_valid(dev, 1) && pnp_port_len(dev, 1) == 1)
+		i8042_command_reg = pnp_port_start(dev,1);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no command port; default is 0x%x\n",
-			acpi_device_bid(device), i8042_command_reg);
+		printk(KERN_WARNING "PNP: [%s] has no command port; default is 0x%x\n",
+			pnp_dev_name(dev), i8042_command_reg);
 
-	if (kbd_res.irq)
-		i8042_kbd_irq = kbd_res.irq;
+	if (pnp_irq_valid(dev,0))
+		i8042_kbd_irq = pnp_irq(dev,0);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no IRQ; default is %d\n",
-			acpi_device_bid(device), i8042_kbd_irq);
+	

Re: [PATCH] PNPACPI parser fix

[matthieu castet]

Hi,
matthieu castet wrote:
Hi,
This patch is very old (11/2004), but never get merged even if acked by 
Shaohua Li.
As you can see in the bugzilla report 
(http://bugzilla.kernel.org/show_bug.cgi?id=3912), it solve parsing 
issue in the pnpacpi core : the pnpacpi parser supposed that are no
resource after EndDependentFn.

Please apply this patch.
Thanks.
Matthieu CASTET
oops, the attachement was wrong.
Here is the patch.
Regards,
Matthieu
--- linux-2.6.9/drivers/pnp/pnpacpi/rsparser.c.old	2004-11-12 22:55:10.0 +0100
+++ linux-2.6.9/drivers/pnp/pnpacpi/rsparser.c	2004-11-20 10:44:36.0 +0100
@@ -443,6 +443,7 @@
 
 struct acpipnp_parse_option_s {
 	struct pnp_option *option;
+	struct pnp_option *option_independent;
 	struct pnp_dev *dev;
 };
 
@@ -506,7 +507,15 @@
 			parse_data->option = option;	
 			break;
 		case ACPI_RSTYPE_END_DPF:
-			return AE_CTRL_TERMINATE;
+			/*only one EndDependentFn is allowed*/
+			if (!parse_data->option_independent) {
+pnp_warn("PnPACPI: more than one EndDependentFn");
+return AE_ERROR;
+			}
+			parse_data->option = parse_data->option_independent;
+			parse_data->option_independent = NULL;
+			break;
 		default:
 			pnp_warn("PnPACPI:Option type: %d not handle", res->id);
 			return AE_ERROR;
@@ -524,6 +533,7 @@
 	parse_data.option = pnp_register_option_independent(dev);
 	if (!parse_data.option)
 		return AE_ERROR;
+	parse_data.option_independent = parse_data.option;
 	parse_data.dev = dev;
 	status = acpi_walk_resources(handle, METHOD_NAME__PRS, 
 		pnpacpi_option_resource, &parse_data);

Re: [patch] ns558 bug

[matthieu castet]

Hi,
Andrew Morton wrote:
[EMAIL PROTECTED] (Adam Belay) wrote:
On Fri, Feb 04, 2005 at 09:00:54PM +0100, matthieu castet wrote:
> Hi,
> 
> this patch is based on http://bugzilla.kernel.org/show_bug.cgi?id=2962 
> patch from adam belay.
> 
> It solve a oops when pnp_register_driver(&ns558_pnp_driver) failed.
> 
> Please apply this patch.
> 
> Matthieu

I remember writing a version of this patch a while ago.  The current behavior
is broken because it shouldn't be considered a failure if the driver doesn't
find any devices.
Why ?
If isa detection failed, the modules could not find any new isa devices.
If the pnp detection find no device, the module is load.
If it is the kernel modules behaviour, lot's of modules are broken...
If you want that, why not simply alway "return 0" in the __init like it 
is done in the bugzilla patch ?

Matthieu
-
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: [PATCH] PNP support for i8042 driver

[matthieu castet]

Hi,
Vojtech Pavlik wrote:
On Fri, Feb 04, 2005 at 06:37:29PM +0100, matthieu castet wrote:
Hi,
Vojtech Pavlik wrote:
On Sat, Nov 13, 2004 at 02:23:53PM +0100, matthieu castet wrote:

Hi,
this patch add PNP support for the i8042 driver in 2.6.10-rc1-mm5. Acpi 
is try before the pnp driver so if you don't disable ACPI or apply 
others pnpacpi patches, it won't change anything.

Please review it and apply if possible

Ok, my thoughts on this:
It's OK to keep the device allocated to this driver via the PnP
  subsystem, and not bother with releasing the code via
__initcall.
I agree that if there is a way to enumerate the device, (like
PnP, ACPI or OpenFirmware), we should use that instead of
probing and using a platform device for the controller.
I think that we should drop the ACPI support from i8042, in
favor of pnpacpi, because PnP is more generic and if the
keyboard device was listed in PnPBIOS instead of ACPI, it'll
still work.
Any news about this ?
 
Sort of fell off my radar, can you resend?

attached 2 versions : the one that kill acpi detection and the one with 
acpi but a complex init.

Matthieu
Index: drivers/input/serio/i8042-x86ia64io.h
===
RCS file: /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/input/serio/i8042-x86ia64io.h,v
retrieving revision 1.2
diff -u -u -r1.2 i8042-x86ia64io.h
--- drivers/input/serio/i8042-x86ia64io.h	4 Jan 2005 08:06:19 -	1.2
+++ drivers/input/serio/i8042-x86ia64io.h	4 Feb 2005 22:37:12 -
@@ -88,183 +88,113 @@
 };
 #endif
 
-#ifdef CONFIG_ACPI
-#include 
-#include 
-
-struct i8042_acpi_resources {
-	unsigned int port1;
-	unsigned int port2;
-	unsigned int irq;
-};
+#ifdef CONFIG_PNP
+#include 
 
-static int i8042_acpi_kbd_registered;
-static int i8042_acpi_aux_registered;
+static int i8042_pnp_kbd_registered;
+static int i8042_pnp_aux_registered;
 
-static acpi_status i8042_acpi_parse_resource(struct acpi_resource *res, void *data)
-{
-	struct i8042_acpi_resources *i8042_res = data;
-	struct acpi_resource_io *io;
-	struct acpi_resource_fixed_io *fixed_io;
-	struct acpi_resource_irq *irq;
-	struct acpi_resource_ext_irq *ext_irq;
-
-	switch (res->id) {
-		case ACPI_RSTYPE_IO:
-			io = &res->data.io;
-			if (io->range_length) {
-if (!i8042_res->port1)
-	i8042_res->port1 = io->min_base_address;
-else
-	i8042_res->port2 = io->min_base_address;
-			}
-			break;
-
-		case ACPI_RSTYPE_FIXED_IO:
-			fixed_io = &res->data.fixed_io;
-			if (fixed_io->range_length) {
-if (!i8042_res->port1)
-	i8042_res->port1 = fixed_io->base_address;
-else
-	i8042_res->port2 = fixed_io->base_address;
-			}
-			break;
-
-		case ACPI_RSTYPE_IRQ:
-			irq = &res->data.irq;
-			if (irq->number_of_interrupts > 0)
-i8042_res->irq =
-	acpi_register_gsi(irq->interrupts[0],
-			  irq->edge_level,
-			  irq->active_high_low);
-			break;
-
-		case ACPI_RSTYPE_EXT_IRQ:
-			ext_irq = &res->data.extended_irq;
-			if (ext_irq->number_of_interrupts > 0)
-i8042_res->irq =
-	acpi_register_gsi(ext_irq->interrupts[0],
-			  ext_irq->edge_level,
-			  ext_irq->active_high_low);
-			break;
-	}
-	return AE_OK;
-}
 
-static int i8042_acpi_kbd_add(struct acpi_device *device)
+static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id *did)
 {
-	struct i8042_acpi_resources kbd_res;
-	acpi_status status;
-
-	memset(&kbd_res, 0, sizeof(kbd_res));
-	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- i8042_acpi_parse_resource, &kbd_res);
-	if (ACPI_FAILURE(status))
-		return -ENODEV;
-
-	if (kbd_res.port1)
-		i8042_data_reg = kbd_res.port1;
+	if (pnp_port_valid(dev, 0) && pnp_port_len(dev, 0) == 1)
+		i8042_data_reg = pnp_port_start(dev,0);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no data port; default is 0x%x\n",
-			acpi_device_bid(device), i8042_data_reg);
+		printk(KERN_WARNING "PNP: [%s] has no data port; default is 0x%x\n",
+			pnp_dev_name(dev), i8042_data_reg);
 
-	if (kbd_res.port2)
-		i8042_command_reg = kbd_res.port2;
+	if (pnp_port_valid(dev, 1) && pnp_port_len(dev, 1) == 1)
+		i8042_command_reg = pnp_port_start(dev,1);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no command port; default is 0x%x\n",
-			acpi_device_bid(device), i8042_command_reg);
+		printk(KERN_WARNING "PNP: [%s] has no command port; default is 0x%x\n",
+			pnp_dev_name(dev), i8042_command_reg);
 
-	if (kbd_res.irq)
-		i8042_kbd_irq = kbd_res.irq;
+	if (pnp_irq_valid(dev,0))
+		i8042_kbd_irq = pnp_irq(dev,0);
 	else
-		printk(KERN_WARNING "ACPI: [%s] has no IRQ; default is %d\n",
-			acpi_device_bid(device), i8042_kbd_irq);
+		printk(KERN_WARNING "PNP: [%s] has no IRQ; default

[patch] ns558 bug

[matthieu castet]

Hi,
this patch is based on http://bugzilla.kernel.org/show_bug.cgi?id=2962 
patch from adam belay.

It solve a oops when pnp_register_driver(&ns558_pnp_driver) failed.
Please apply this patch.
Matthieu
Index: drivers/input/gameport/ns558.c
===
RCS file: /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/input/gameport/ns558.c,v
retrieving revision 1.15
diff -u -u -r1.15 ns558.c
--- drivers/input/gameport/ns558.c	16 Sep 2004 14:04:04 -	1.15
+++ drivers/input/gameport/ns558.c	4 Feb 2005 19:53:20 -
@@ -261,6 +261,8 @@
 
 #endif
 
+static int registered = 0;
+
 int __init ns558_init(void)
 {
 	int i = 0;
@@ -272,8 +274,10 @@
 	while (ns558_isa_portlist[i])
 		ns558_isa_probe(ns558_isa_portlist[i++]);
 
-	pnp_register_driver(&ns558_pnp_driver);
-	return list_empty(&ns558_list) ? -ENODEV : 0;
+	if (pnp_register_driver(&ns558_pnp_driver) >= 0) 
+		registered = 1;
+
+	return (list_empty(&ns558_list) && !registered) ? -ENODEV : 0;
 }
 
 void __exit ns558_exit(void)
@@ -297,7 +301,8 @@
 break;
 		}
 	}
-	pnp_unregister_driver(&ns558_pnp_driver);
+	if (registered)
+		pnp_unregister_driver(&ns558_pnp_driver);
 }
 
 module_init(ns558_init);

Re: [PATCH] PNP support for i8042 driver

[matthieu castet]

Hi,
Vojtech Pavlik wrote:
On Sat, Nov 13, 2004 at 02:23:53PM +0100, matthieu castet wrote:
Hi,
this patch add PNP support for the i8042 driver in 2.6.10-rc1-mm5. Acpi 
is try before the pnp driver so if you don't disable ACPI or apply 
others pnpacpi patches, it won't change anything.

Please review it and apply if possible

Ok, my thoughts on this:
It's OK to keep the device allocated to this driver via the PnP
subsystem, and not bother with releasing the code via
__initcall.
I agree that if there is a way to enumerate the device, (like
PnP, ACPI or OpenFirmware), we should use that instead of
probing and using a platform device for the controller.
I think that we should drop the ACPI support from i8042, in
favor of pnpacpi, because PnP is more generic and if the
keyboard device was listed in PnPBIOS instead of ACPI, it'll
still work.
Any news about this ?
Matthieu CASTET
-
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/

[PATCH] PNPACPI : don't use device not present

[matthieu castet]

Hi,
this patch avoid the pnpacpi layer reconized not present device.
There is still issue [1] with the ACPI code that need to fix in order 
everything work correctly...

Matthieu CASTET
[1] http://bugzilla.kernel.org/show_bug.cgi?id=3358
--- linux-2.6.9/drivers/pnp/pnpacpi/core.c	2004-11-22 20:35:58.0 +0100
+++ linux-2.6.9/drivers/pnp/pnpacpi/core.c	2004-11-26 14:46:54.0 +0100
@@ -124,6 +124,10 @@
 	struct pnp_dev *dev;
 
 	pnp_dbg("ACPI device : hid %s", acpi_device_hid(device));
+
+	if(!device->status.present)
+		return -ENODEV;
+
 	dev =  pnpacpi_kmalloc(sizeof(struct pnp_dev), GFP_KERNEL);
 	if (!dev) {
 		pnp_err("Out of memory");