Re: linux-next: first tree

[Robin Getz]

On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
> On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> >
> > Could you please add Blackfin tree to the linux-next
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
> > for-linus
> 
> Added, thanks.
> 
> > And do you have the blackfin cross-compile toolchain?
> 
> No, I don't at the moment.

You can grab (i386 rpms and tar ball) that should work from:

http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView_id=375

You will need:
 - toolchain blackfin-toolchain-08r1-8.i386.rpm
 - c library (either one of):
- blackfin-toolchain-uclibc-default-08r1-8.i386.rpm
- blackfin-toolchain-uclibc-full-08r1-8.i386.rpm

Other arch's & packages should appear shortly.

-Robin
--
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: linux-next: first tree

[Robin Getz]

On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
 On Fri, 15 Feb 2008 16:33:50 +0800 Bryan Wu [EMAIL PROTECTED] wrote:
 
  Could you please add Blackfin tree to the linux-next
  
   git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
  for-linus
 
 Added, thanks.
 
  And do you have the blackfin cross-compile toolchain?
 
 No, I don't at the moment.

You can grab (i386 rpms and tar ball) that should work from:

http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseViewrelease_id=375

You will need:
 - toolchain blackfin-toolchain-08r1-8.i386.rpm
 - c library (either one of):
- blackfin-toolchain-uclibc-default-08r1-8.i386.rpm
- blackfin-toolchain-uclibc-full-08r1-8.i386.rpm

Other arch's  packages should appear shortly.

-Robin
--
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: blackfin compile error

[Robin Getz]

On Wed 6 Feb 2008 14:37, Andrew Morton pondered:
> On Wed, 6 Feb 2008 14:12:50 -0500
> Robin Getz <[EMAIL PROTECTED]> wrote:
> 
> > On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
> > > 
> > > On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
> > > > Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
> > > > 
> > > > <--  snip  -->
> > > > 
> > > > ...
> > > >   CC  mm/vmscan.o
> > > > In file included from 
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In 
> > > > function 'is_swap_pte':
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
> > > > error: implicit declaration of function 'pte_none'
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
> > > > error: implicit declaration of function 'pte_present'
> > > > make[2]: *** [mm/vmscan.o] Error 1
> > > 
> > > This suggests that no one's tried to compile -mm on Blackfin since
> > > before September, I think.
> > 
> > Or any other nommu arch's either, since looking at the include files,
> > FRV (when configured as noMMU) and m68knommu does not include it either...
> 
> sh is the only nommu arch which I test-compile for.
> 
> The world would be a better place if arch maintainers (or their helpers)
> were to build and test -mm once a month or so.

OK - now that we have that fixed (Mike/Bryan will do this on the mm tree and
at least fix up compile issues as soon as we notice) - how do we want to fix
this specific issue?

Add the missing entries into include/asm-x/pgtable.h or wrap the callers
in ifdefs?

-Robin

-Robin
--
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: Gadget driver repository?

[Robin Getz]

On Tue 5 Feb 2008 14:56, Robin Getz pondered:
> I was wondering where (or if) there were any non-mainlined gadget
> drivers that 
> were kept anywhere?
> 
> According to (2005)
> http://www.linux-usb.org/gadget/
> 
> >  Other controller and gadget drivers are in development, but are
> >  unreleased or not published here. Examples that have seen some 
> >  degree of light include:
> >
> > * HID driver (userspace, with gadgetfs),
> > * "MTP" (Media Transfer Protocol, PTP++) driver (userspace, 
> >with gadgetfs), * two different printer class drivers (used
> >in various products),
> > * audio class driver (very experimental). 
> > * video class driver (very experimental).
> 
> I'm actually looking for the gadget side of HID and Audio and anyone has
> any pointers?

OK - so that got nothing.


Is anyone interested in helping develop them, so a reference open source 
implementation exists?
--
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: Gadget driver repository?

[Robin Getz]

On Tue 5 Feb 2008 14:56, Robin Getz pondered:
 I was wondering where (or if) there were any non-mainlined gadget
 drivers that 
 were kept anywhere?
 
 According to (2005)
 http://www.linux-usb.org/gadget/
 
   Other controller and gadget drivers are in development, but are
   unreleased or not published here. Examples that have seen some 
   degree of light include:
 
  * HID driver (userspace, with gadgetfs),
  * MTP (Media Transfer Protocol, PTP++) driver (userspace, 
 with gadgetfs), * two different printer class drivers (used
 in various products),
  * audio class driver (very experimental). 
  * video class driver (very experimental).
 
 I'm actually looking for the gadget side of HID and Audio and anyone has
 any pointers?

OK - so that got nothing.


Is anyone interested in helping develop them, so a reference open source 
implementation exists?
--
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: blackfin compile error

[Robin Getz]

On Wed 6 Feb 2008 14:37, Andrew Morton pondered:
 On Wed, 6 Feb 2008 14:12:50 -0500
 Robin Getz [EMAIL PROTECTED] wrote:
 
  On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
   
   On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:

--  snip  --

...
  CC  mm/vmscan.o
In file included from 
/home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In 
function 'is_swap_pte':
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
error: implicit declaration of function 'pte_none'
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
error: implicit declaration of function 'pte_present'
make[2]: *** [mm/vmscan.o] Error 1
   
   This suggests that no one's tried to compile -mm on Blackfin since
   before September, I think.
  
  Or any other nommu arch's either, since looking at the include files,
  FRV (when configured as noMMU) and m68knommu does not include it either...
 
 sh is the only nommu arch which I test-compile for.
 
 The world would be a better place if arch maintainers (or their helpers)
 were to build and test -mm once a month or so.

OK - now that we have that fixed (Mike/Bryan will do this on the mm tree and
at least fix up compile issues as soon as we notice) - how do we want to fix
this specific issue?

Add the missing entries into include/asm-x/pgtable.h or wrap the callers
in ifdefs?

-Robin

-Robin
--
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: blackfin compile error

[Robin Getz]

On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
> 
> On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
> > Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
> > 
> > <--  snip  -->
> > 
> > ...
> >   CC  mm/vmscan.o
> > In file included from 
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In 
> > function 'is_swap_pte':
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
> > error: implicit declaration of function 'pte_none'
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
> > error: implicit declaration of function 'pte_present'
> > make[2]: *** [mm/vmscan.o] Error 1
> 
> This suggests that no one's tried to compile -mm on Blackfin since
> before September, I think.

Or any other nommu arch's either, since looking at the include files, FRV
(when configured as noMMU) and m68knommu does not include it either...

> Is there somewhere more appropriate to move it? I can't find one.
> Failing that, we can wrap it in CONFIG_MMU, I suppose.

Or just add to the the following:

./include/asm-blackfin
./include/asm-frv/ (only when configured as !MMU)
./include/asm-h8300
./include/asm-m68knommu
./include/asm-v850

Others seem to have it in include/asm-x/pgtable.h as #define, inline 
function, or extern.

> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> 
> diff -r 50a6e531a9f2 include/linux/swapops.h
> --- a/include/linux/swapops.h Mon Feb 04 20:23:02 2008 -0600
> +++ b/include/linux/swapops.h Wed Feb 06 10:21:32 2008 -0600
> @@ -42,11 +42,13 @@
>   return entry.val & SWP_OFFSET_MASK(entry);
>  }
>  
> +#ifdef CONFIG_MMU
>  /* check whether a pte points to a swap entry */
>  static inline int is_swap_pte(pte_t pte)
>  {
>   return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
>  }
> +#endif
>  
>  /*
>   * Convert the arch-dependent pte representation of a swp_entry_t into
> an
> 
--
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: blackfin compile error

[Robin Getz]

On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
 
 On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
  Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
  
  --  snip  --
  
  ...
CC  mm/vmscan.o
  In file included from 
  /home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
  /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In 
  function 'is_swap_pte':
  /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
  error: implicit declaration of function 'pte_none'
  /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: 
  error: implicit declaration of function 'pte_present'
  make[2]: *** [mm/vmscan.o] Error 1
 
 This suggests that no one's tried to compile -mm on Blackfin since
 before September, I think.

Or any other nommu arch's either, since looking at the include files, FRV
(when configured as noMMU) and m68knommu does not include it either...

 Is there somewhere more appropriate to move it? I can't find one.
 Failing that, we can wrap it in CONFIG_MMU, I suppose.

Or just add to the the following:

./include/asm-blackfin
./include/asm-frv/ (only when configured as !MMU)
./include/asm-h8300
./include/asm-m68knommu
./include/asm-v850

Others seem to have it in include/asm-x/pgtable.h as #define, inline 
function, or extern.

 Signed-off-by: Matt Mackall [EMAIL PROTECTED]
 
 diff -r 50a6e531a9f2 include/linux/swapops.h
 --- a/include/linux/swapops.h Mon Feb 04 20:23:02 2008 -0600
 +++ b/include/linux/swapops.h Wed Feb 06 10:21:32 2008 -0600
 @@ -42,11 +42,13 @@
   return entry.val  SWP_OFFSET_MASK(entry);
  }
  
 +#ifdef CONFIG_MMU
  /* check whether a pte points to a swap entry */
  static inline int is_swap_pte(pte_t pte)
  {
   return !pte_none(pte)  !pte_present(pte)  !pte_file(pte);
  }
 +#endif
  
  /*
   * Convert the arch-dependent pte representation of a swp_entry_t into
 an
 
--
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: managing kallsyms_addresses

[Robin Getz]

On Thu 31 Jan 2008 12:27, Paulo Marques pondered:
> Robin Getz wrote:
> > When the kernel needs to find out what symbol is at a specific address, it 
> > uses kallsyms_lookup() This seems to work pretty well - almost.
> > 
> > The problem is today, we don't to remove the symbols from the init section 
> > when the init section is freed. There is invalid data in
> > kallsyms_addresses. 
> > [...]
> > There would be two solutions:
> >  - when freeing the init section, remove all the init labels from the 
> > kallsyms_addresses, and resort/pack it.
> 
> This should be doable, but to be worth it, we would need to use 
> different structures for the init symbols, that would be stored in 
> __initdata.
> 
> Then, ideally we would have separate functions in the __init section to 
> look up symbols in those structures that would only be called until we 
> released the init sections.
> 
> On the plus side, this would avoid the "repacking" the kallsyms 
> structures to remove the init labels.

I think this would be a good long term thing, but would require restructuring 
of all the kallsyms scripts, as well as everything in the kernel...

> >  - if the init section is unloaded, have is_kernel_inittext always 
> >  return 0. 
> 
> This is by far the simplest solution. I even STR a patch floating around 
> to do this, by I can't seem to locate it now... :(

I can put something together if Rusty agrees this is the way to go.

> > I assume that similar things need to be handled for module init too, but I 
> > have not run into that yet.
> 
> It seems that at least the last solution should be easy enough to 
> implement there.
> 
> > Thoughts?
> 
> I think that the simplest solution (the second one) is probably the best 
> for now.
> 
> One thing that did cross my mind though, is stuff like lockdep.

Hmmm - I would need to defer to Ingo to understand the dependencies in lockdep 
and init labels/addresses in kallsyms_addresses.

> If we run a locking sequence that is called from init code, and later a 
> different locking sequence is used when we already freed init data, how 
> can the debug information show the names of the functions that generated 
> the previous locking sequence?

Maybe the lockdep needs to keep track of the label, not the address.

> It seems that the only "correct" approach would be to store a "before 
> freeing init sections" flag together with the function pointer, and then 
> have a kallsyms interface that could receive this flag to know where to 
> look.
> 
> In that case, the first solution can not be used at all (because we need 
> to keep the init symbols anyway) and the second solution could be simply 
> implemented by having a default value for the flag that is the "current 
> state" for that flag...

That seems a little cumbersome to me...

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

managing kallsyms_addresses

[Robin Getz]

When the kernel needs to find out what symbol is at a specific address, it 
uses kallsyms_lookup() This seems to work pretty well - almost.

The problem is today, we don't to remove the symbols from the init section 
when the init section is freed. There is invalid data in kallsyms_addresses.

The problem I have been experiencing - If you have a module get loaded into a 
location which was init, then kallsyms_lookup()  can return init labels, 
rather than the module labels. (since it looks up kernel labels before module 
labels).

What happens is if there is a OOPS in the module, the labels from the OOPS can 
point to init code (which doesn't exist), which confuses the heck out of 
users and developers... 

There would be two solutions:
 - when freeing the init section, remove all the init labels from the 
kallsyms_addresses, and resort/pack it.
 - if the init section is unloaded, have is_kernel_inittext always return 0.

I assume that similar things need to be handled for module init too, but I 
have not run into that yet.

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

managing kallsyms_addresses

[Robin Getz]

When the kernel needs to find out what symbol is at a specific address, it 
uses kallsyms_lookup() This seems to work pretty well - almost.

The problem is today, we don't to remove the symbols from the init section 
when the init section is freed. There is invalid data in kallsyms_addresses.

The problem I have been experiencing - If you have a module get loaded into a 
location which was init, then kallsyms_lookup()  can return init labels, 
rather than the module labels. (since it looks up kernel labels before module 
labels).

What happens is if there is a OOPS in the module, the labels from the OOPS can 
point to init code (which doesn't exist), which confuses the heck out of 
users and developers... 

There would be two solutions:
 - when freeing the init section, remove all the init labels from the 
kallsyms_addresses, and resort/pack it.
 - if the init section is unloaded, have is_kernel_inittext always return 0.

I assume that similar things need to be handled for module init too, but I 
have not run into that yet.

Thoughts?
--
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: managing kallsyms_addresses

[Robin Getz]

On Thu 31 Jan 2008 12:27, Paulo Marques pondered:
 Robin Getz wrote:
  When the kernel needs to find out what symbol is at a specific address, it 
  uses kallsyms_lookup() This seems to work pretty well - almost.
  
  The problem is today, we don't to remove the symbols from the init section 
  when the init section is freed. There is invalid data in
  kallsyms_addresses. 
  [...]
  There would be two solutions:
   - when freeing the init section, remove all the init labels from the 
  kallsyms_addresses, and resort/pack it.
 
 This should be doable, but to be worth it, we would need to use 
 different structures for the init symbols, that would be stored in 
 __initdata.
 
 Then, ideally we would have separate functions in the __init section to 
 look up symbols in those structures that would only be called until we 
 released the init sections.
 
 On the plus side, this would avoid the repacking the kallsyms 
 structures to remove the init labels.

I think this would be a good long term thing, but would require restructuring 
of all the kallsyms scripts, as well as everything in the kernel...

   - if the init section is unloaded, have is_kernel_inittext always 
   return 0. 
 
 This is by far the simplest solution. I even STR a patch floating around 
 to do this, by I can't seem to locate it now... :(

I can put something together if Rusty agrees this is the way to go.

  I assume that similar things need to be handled for module init too, but I 
  have not run into that yet.
 
 It seems that at least the last solution should be easy enough to 
 implement there.
 
  Thoughts?
 
 I think that the simplest solution (the second one) is probably the best 
 for now.
 
 One thing that did cross my mind though, is stuff like lockdep.

Hmmm - I would need to defer to Ingo to understand the dependencies in lockdep 
and init labels/addresses in kallsyms_addresses.

 If we run a locking sequence that is called from init code, and later a 
 different locking sequence is used when we already freed init data, how 
 can the debug information show the names of the functions that generated 
 the previous locking sequence?

Maybe the lockdep needs to keep track of the label, not the address.

 It seems that the only correct approach would be to store a before 
 freeing init sections flag together with the function pointer, and then 
 have a kallsyms interface that could receive this flag to know where to 
 look.
 
 In that case, the first solution can not be used at all (because we need 
 to keep the init symbols anyway) and the second solution could be simply 
 implemented by having a default value for the flag that is the current 
 state for that flag...

That seems a little cumbersome to me...

-Robin
--
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 1/1] [Blackfin] char driver for Blackfin on-chip OTP memory

[Robin Getz]

On Wed 30 Jan 2008 06:00, Jiri Slaby pondered:
> On 01/30/2008 11:36 AM, Bryan Wu wrote:
> > From: Mike Frysinger <[EMAIL PROTECTED]>
> > 
> > initial char driver for otp memory
> > (only read supported atm ... needs real examples/docs for write support)
> > 
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>

> > +   bfin_otp_class = class_create(THIS_MODULE, "otp");
> > +   device_create(bfin_otp_class, NULL, bfin_otp_dev_node, "otp");
> 
> Anyway, wouldn't be easier/better to use misc.c functionality here 
> (misc_register() et al.)?

OTP (one time programmable) memory are not registers, they are small blocks 
(8k bytes) of non violate on chip memory, for storing things that you don't 
want other people to look at via a PCB level probe. (like keys), or things 
that are just helpful - like MAC addresses.

-Robin
--
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 1/1] [Blackfin] char driver for Blackfin on-chip OTP memory

[Robin Getz]

On Wed 30 Jan 2008 06:00, Jiri Slaby pondered:
 On 01/30/2008 11:36 AM, Bryan Wu wrote:
  From: Mike Frysinger [EMAIL PROTECTED]
  
  initial char driver for otp memory
  (only read supported atm ... needs real examples/docs for write support)
  
  Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
  Signed-off-by: Bryan Wu [EMAIL PROTECTED]

  +   bfin_otp_class = class_create(THIS_MODULE, otp);
  +   device_create(bfin_otp_class, NULL, bfin_otp_dev_node, otp);
 
 Anyway, wouldn't be easier/better to use misc.c functionality here 
 (misc_register() et al.)?

OTP (one time programmable) memory are not registers, they are small blocks 
(8k bytes) of non violate on chip memory, for storing things that you don't 
want other people to look at via a PCB level probe. (like keys), or things 
that are just helpful - like MAC addresses.

-Robin
--
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: Fix Blackfin HARDWARE_PM support

[Robin Getz]

On Tue 15 Jan 2008 12:42, Mathieu Desnoyers pondered:
> This patch restores the blackfin Hardware Performance Monitor Profiling
> support that was killed by
> commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
> 
> Since there seems to be no good reason to behave differently from other
> architectures, it now automatically selects the hardware performance
> counters whenever the profiling is activated.
> 
> mach-common/irqpanic.c: pm_overflow
> calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt
> that setting HARDWARE_PM as "m" will work at all, since the
> pm_overflow_handler should be in the core kernel image because it is
> called by irqpanic.c. 
> 
> Therefore, I change HARDWARE_PM from a tristate to a bool.
> 
> The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE.
> Since part of the HARDWARE_PM support files sits in this directory, it makes
> sense to also depend on OPROFILE, not only PROFILING. Since OPROFILE already
> depends on PROFILING, it is correct to only depend on OPROFILE only.
> 
> Thanks to Adrian Bunk for finding this bug and providing an initial
> patch.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Linus Torvalds <[EMAIL PROTECTED]>
> CC: Adrian Bunk <[EMAIL PROTECTED]>
> CC: Randy Dunlap <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: Robin Getz <[EMAIL PROTECTED]>

Acked-by: Robin Getz <[EMAIL PROTECTED]>

> ---
>  arch/blackfin/Kconfig |4 
>  1 file changed, 4 insertions(+)
> 
> Index: linux-2.6-lttng/arch/blackfin/Kconfig
> ===
> --- linux-2.6-lttng.orig/arch/blackfin/Kconfig2007-12-29
> 11:00:05.0 -0500
> +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-12-29
> 11:25:39.0 -0500
> @@ -65,6 +65,10 @@ config GENERIC_CALIBRATE_DELAY
>   bool
>   default y
>  
> +config HARDWARE_PM
> + def_bool y
> + depends on OPROFILE
> +
>  source "init/Kconfig"
>  source "kernel/Kconfig.preempt"
>  
> 
> 
--
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: Fix Blackfin HARDWARE_PM support

[Robin Getz]

On Tue 15 Jan 2008 12:42, Mathieu Desnoyers pondered:
 This patch restores the blackfin Hardware Performance Monitor Profiling
 support that was killed by
 commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
 
 Since there seems to be no good reason to behave differently from other
 architectures, it now automatically selects the hardware performance
 counters whenever the profiling is activated.
 
 mach-common/irqpanic.c: pm_overflow
 calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt
 that setting HARDWARE_PM as m will work at all, since the
 pm_overflow_handler should be in the core kernel image because it is
 called by irqpanic.c. 
 
 Therefore, I change HARDWARE_PM from a tristate to a bool.
 
 The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE.
 Since part of the HARDWARE_PM support files sits in this directory, it makes
 sense to also depend on OPROFILE, not only PROFILING. Since OPROFILE already
 depends on PROFILING, it is correct to only depend on OPROFILE only.
 
 Thanks to Adrian Bunk for finding this bug and providing an initial
 patch.
 
 Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
 CC: Linus Torvalds [EMAIL PROTECTED]
 CC: Adrian Bunk [EMAIL PROTECTED]
 CC: Randy Dunlap [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED]
 CC: Robin Getz [EMAIL PROTECTED]

Acked-by: Robin Getz [EMAIL PROTECTED]

 ---
  arch/blackfin/Kconfig |4 
  1 file changed, 4 insertions(+)
 
 Index: linux-2.6-lttng/arch/blackfin/Kconfig
 ===
 --- linux-2.6-lttng.orig/arch/blackfin/Kconfig2007-12-29
 11:00:05.0 -0500
 +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-12-29
 11:25:39.0 -0500
 @@ -65,6 +65,10 @@ config GENERIC_CALIBRATE_DELAY
   bool
   default y
  
 +config HARDWARE_PM
 + def_bool y
 + depends on OPROFILE
 +
  source init/Kconfig
  source kernel/Kconfig.preempt
  
 
 
--
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] split MMC_CAP_4_BIT_DATA

[Robin Getz]

On Fri 11 Jan 2008 12:52, Robin Getz pondered:
> On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
> > On Fri, 11 Jan 2008 04:08:53 -0500
> > "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> > 
> > > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > > > So it's far more probable that you've misdiagnosed your error than
> > this being the actual problem.
> > > 
> > > the guys who design the silicon are telling us it doesnt work.  our
> > > tests show it not working.  i'm not sure what else you want here.
> > > 
> > 
> > More information. You have not provided any speculation as to why it
> > doesn't work, or what you've done to figure it out.
> 
> I have been trying to get the detailed information from the hardware
> (silicon designer) guy about why he believes support for 4-bit MMC is
> not there, but I have not heard back yet.
> 
> As soon as I hear from them - and either understand why 4-bit MMC doesn't 
> work, or if the Blackfin docs are incorrect (either is OK outcome) - I will 
> let you know.

According to the HW folks - it is exactly as Pierre indicated - in theory it 
should work, 4-bit MMC requires usage of different set of commands as 
compared to 4-bit SD, so it should be just software - although no one has 
tested it yet.

So I guess this is back on Bryan/Cliff to make work

Thanks for pushing back.

-Robin
--
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] split MMC_CAP_4_BIT_DATA

[Robin Getz]

On Fri 11 Jan 2008 12:52, Robin Getz pondered:
 On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
  On Fri, 11 Jan 2008 04:08:53 -0500
  Mike Frysinger [EMAIL PROTECTED] wrote:
  
   On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
So it's far more probable that you've misdiagnosed your error than
  this being the actual problem.
   
   the guys who design the silicon are telling us it doesnt work.  our
   tests show it not working.  i'm not sure what else you want here.
   
  
  More information. You have not provided any speculation as to why it
  doesn't work, or what you've done to figure it out.
 
 I have been trying to get the detailed information from the hardware
 (silicon designer) guy about why he believes support for 4-bit MMC is
 not there, but I have not heard back yet.
 
 As soon as I hear from them - and either understand why 4-bit MMC doesn't 
 work, or if the Blackfin docs are incorrect (either is OK outcome) - I will 
 let you know.

According to the HW folks - it is exactly as Pierre indicated - in theory it 
should work, 4-bit MMC requires usage of different set of commands as 
compared to 4-bit SD, so it should be just software - although no one has 
tested it yet.

So I guess this is back on Bryan/Cliff to make work

Thanks for pushing back.

-Robin
--
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] split MMC_CAP_4_BIT_DATA

[Robin Getz]

On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
> On Fri, 11 Jan 2008 04:08:53 -0500
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> 
> > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > > So it's far more probable that you've misdiagnosed your error than
> this being the actual problem.
> > 
> > the guys who design the silicon are telling us it doesnt work.  our
> > tests show it not working.  i'm not sure what else you want here.
> > 
> 
> More information. You have not provided any speculation as to why it
> doesn't work, or what you've done to figure it out.

I have been trying to get the detailed information from the hardware (silicon 
designer) guy about why he believes support for 4-bit MMC is not there, but I 
have not heard back yet.

As soon as I hear from them - and either understand why 4-bit MMC doesn't 
work, or if the Blackfin docs are incorrect (either is OK outcome) - I will 
let you know.

Thanks
-Robin
--
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] split MMC_CAP_4_BIT_DATA

[Robin Getz]

On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
 On Fri, 11 Jan 2008 04:08:53 -0500
 Mike Frysinger [EMAIL PROTECTED] wrote:
 
  On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
   So it's far more probable that you've misdiagnosed your error than
 this being the actual problem.
  
  the guys who design the silicon are telling us it doesnt work.  our
  tests show it not working.  i'm not sure what else you want here.
  
 
 More information. You have not provided any speculation as to why it
 doesn't work, or what you've done to figure it out.

I have been trying to get the detailed information from the hardware (silicon 
designer) guy about why he believes support for 4-bit MMC is not there, but I 
have not heard back yet.

As soon as I hear from them - and either understand why 4-bit MMC doesn't 
work, or if the Blackfin docs are incorrect (either is OK outcome) - I will 
let you know.

Thanks
-Robin
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Thu 3 Jan 2008 12:04, Richard D pondered:
> Does all USB Host controller hardware have the ability to disable PING?

I think they do. (or at least should)...

http://www.intel.com/technology/usb/download/ehci-r10.pdf
==
4.11 Ping Control (page 88)

USB 2.0 defines an addition to the protocol for high-speed devices called 
Ping. Ping is required for all USB 2.0 High-speed bulk and control endpoints. 
Ping is not allowed for a split-transaction stream. This extension to the 
protocol eliminates the bad side-effects of Naking OUT endpoints. The Status 
field has a Ping State bit, which the host controller uses to determine the 
next actual PID it will use in the next transaction to the endpoint (see 
Table 3-16).

Table 4–12 illustrates the state transition table for the host controller's 
responsibility for maintaining the PING protocol. 

Refer to Chapter 8 in the USB Specification Revision 2.0 for detailed 
description on the Ping protocol.

===

I think the musb is just missing the PING/OUT State table, as described in 
table 4-12.

I think this is controlled in the ehci driver with:

host/ehci.h:#define QTD_STS_PING(1 << 0)/* issue PING? */

-Robin
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Thu 3 Jan 2008 12:04, Richard D pondered:
 Does all USB Host controller hardware have the ability to disable PING?

I think they do. (or at least should)...

http://www.intel.com/technology/usb/download/ehci-r10.pdf
==
4.11 Ping Control (page 88)

USB 2.0 defines an addition to the protocol for high-speed devices called 
Ping. Ping is required for all USB 2.0 High-speed bulk and control endpoints. 
Ping is not allowed for a split-transaction stream. This extension to the 
protocol eliminates the bad side-effects of Naking OUT endpoints. The Status 
field has a Ping State bit, which the host controller uses to determine the 
next actual PID it will use in the next transaction to the endpoint (see 
Table 3-16).

Table 4–12 illustrates the state transition table for the host controller's 
responsibility for maintaining the PING protocol. 

Refer to Chapter 8 in the USB Specification Revision 2.0 for detailed 
description on the Ping protocol.

===

I think the musb is just missing the PING/OUT State table, as described in 
table 4-12.

I think this is controlled in the ehci driver with:

host/ehci.h:#define QTD_STS_PING(1  0)/* issue PING? */

-Robin
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 22:43, David Brownell pondered:
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's pretty minimal, but won't be used...
>
> Also, as you point out, it's no longer OTG specific, so
> renaming the option would improve clarity.   Maybe to
> something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
> No big deal, at least now.

Are these two things something that you want me to have a stab at, or since 
you are more familiar with it - you want to do it.

Thanks
-Robin
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 13:47, David Brownell pondered:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[EMAIL PROTECTED]>
> > 
> > Allow embedded developers to turn support for USB Hubs off even if
> > they have a full root hub. This saves the overhead (RAM and Flash size).
> 
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.

Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB && 
USB_GADGET).

This just enables cutting more code out, with out having to have USB_GADGET & 
USB_OTG enabled. When I checked - that is where most of the savings came 
from.

-Robin
--
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] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

From: Robin Getz <[EMAIL PROTECTED]>

Allow embedded developers to turn support for USB Hubs off even if they have a 
full root hub. This saves the overhead (RAM and Flash size).

Allow embedded developers the capabilities of the "otg_whitelist.h" - a 
product whitelist, so USB peripherals not listed there will be rejected 
during enumeration. This is the desired operation for many embedded products.

Signed-off-by: Robin Getz <[EMAIL PROTECTED]>

---

 drivers/usb/core/Kconfig |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)


Index: linux-2.6.x/drivers/usb/core/Kconfig
===
--- linux-2.6.x/drivers/usb/core/Kconfig(revision 4074)
+++ linux-2.6.x/drivers/usb/core/Kconfig(working copy)
@@ -95,8 +95,9 @@
 
 config USB_OTG_WHITELIST
bool "Rely on OTG Targeted Peripherals List"
-   depends on USB_OTG
-   default y
+   depends on USB_OTG || EMBEDDED
+   default y if USB_OTG
+   default n if EMBEDDED
help
  If you say Y here, the "otg_whitelist.h" file will be used as a
  product whitelist, so USB peripherals not listed there will be
@@ -111,7 +112,7 @@
 
 config USB_OTG_BLACKLIST_HUB
bool "Disable external hubs"
-   depends on USB_OTG
+   depends on USB_OTG || EMBEDDED
help
  If you say Y here, then Linux will refuse to enumerate
  external hubs.  OTG hosts are allowed to reduce hardware
--
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] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

From: Robin Getz [EMAIL PROTECTED]

Allow embedded developers to turn support for USB Hubs off even if they have a 
full root hub. This saves the overhead (RAM and Flash size).

Allow embedded developers the capabilities of the otg_whitelist.h - a 
product whitelist, so USB peripherals not listed there will be rejected 
during enumeration. This is the desired operation for many embedded products.

Signed-off-by: Robin Getz [EMAIL PROTECTED]

---

 drivers/usb/core/Kconfig |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)


Index: linux-2.6.x/drivers/usb/core/Kconfig
===
--- linux-2.6.x/drivers/usb/core/Kconfig(revision 4074)
+++ linux-2.6.x/drivers/usb/core/Kconfig(working copy)
@@ -95,8 +95,9 @@
 
 config USB_OTG_WHITELIST
bool Rely on OTG Targeted Peripherals List
-   depends on USB_OTG
-   default y
+   depends on USB_OTG || EMBEDDED
+   default y if USB_OTG
+   default n if EMBEDDED
help
  If you say Y here, the otg_whitelist.h file will be used as a
  product whitelist, so USB peripherals not listed there will be
@@ -111,7 +112,7 @@
 
 config USB_OTG_BLACKLIST_HUB
bool Disable external hubs
-   depends on USB_OTG
+   depends on USB_OTG || EMBEDDED
help
  If you say Y here, then Linux will refuse to enumerate
  external hubs.  OTG hosts are allowed to reduce hardware
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 13:47, David Brownell pondered:
 On Wednesday 02 January 2008, Robin Getz wrote:
  From: Robin Getz [EMAIL PROTECTED]
  
  Allow embedded developers to turn support for USB Hubs off even if
  they have a full root hub. This saves the overhead (RAM and Flash size).
 
 ISTR that it won't save very much code though ... the Linux USB
 stack structures all its enumeration logic around hubs.

Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB  
USB_GADGET).

This just enables cutting more code out, with out having to have USB_GADGET  
USB_OTG enabled. When I checked - that is where most of the savings came 
from.

-Robin
--
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: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 22:43, David Brownell pondered:
 This patch might be improved slightly -- in ways that, as I
 understand things, could save some RAM on Blackfin! -- by
 having the BLACKLIST_HUB option get rid of the transaction
 translator support (changing C code not just Kconfig).
 It's pretty minimal, but won't be used...

 Also, as you point out, it's no longer OTG specific, so
 renaming the option would improve clarity.   Maybe to
 something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
 No big deal, at least now.

Are these two things something that you want me to have a stab at, or since 
you are more familiar with it - you want to do it.

Thanks
-Robin
--
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: improve remapping of vmalloc regions

[Robin Getz]

Nick:

In Apr 2006, you sent around some patches 

> vm_insert_page and remap_pfn_range loops are really clever, bit
> probably asking a bit too much of most drivers. I was able to get
> rid of most of them without too much trouble.

http://lkml.org/lkml/2006/4/20/196

It doesn't seem like those made it into mainline - was there a reason why? (I 
looked around and didn't see anything).

Thanks
-Robin
--
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: improve remapping of vmalloc regions

[Robin Getz]

Nick:

In Apr 2006, you sent around some patches 

 vm_insert_page and remap_pfn_range loops are really clever, bit
 probably asking a bit too much of most drivers. I was able to get
 rid of most of them without too much trouble.

http://lkml.org/lkml/2006/4/20/196

It doesn't seem like those made it into mainline - was there a reason why? (I 
looked around and didn't see anything).

Thanks
-Robin
--
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: [2.6.24 patch] restore blackfin HARDWARE_PM support

[Robin Getz]

On Sat 29 Dec 2007 01:23, Mathieu Desnoyers pondered:
> Ok, and do we really need to make HARDWARE_PM a tristate ? I see that
> part of it must be compiled into the kernel in core .S files. Does it
> really make sense for it to be a module ?

I don't think so.

> Also, op_model_bf533.c sits in the arch/blackfin/oprofile directory,
> (built if HARDWARE_PM is y or m) but depends on PROFILING, not OPROFILE.
> Is HARDWARE_PM useful at all without OPROFILE ?

There was an out of tree patch that was floating around that gave people a sys 
or proc interface to the hardware registers - since oprofile doesn't work 
that well on a bash-less system.

I don't think I will have time to look at the patch over the weekend, but will 
do after Jan 1.

-Robin
--
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: [2.6.24 patch] restore blackfin HARDWARE_PM support

[Robin Getz]

On Sat 29 Dec 2007 01:23, Mathieu Desnoyers pondered:
 Ok, and do we really need to make HARDWARE_PM a tristate ? I see that
 part of it must be compiled into the kernel in core .S files. Does it
 really make sense for it to be a module ?

I don't think so.

 Also, op_model_bf533.c sits in the arch/blackfin/oprofile directory,
 (built if HARDWARE_PM is y or m) but depends on PROFILING, not OPROFILE.
 Is HARDWARE_PM useful at all without OPROFILE ?

There was an out of tree patch that was floating around that gave people a sys 
or proc interface to the hardware registers - since oprofile doesn't work 
that well on a bash-less system.

I don't think I will have time to look at the patch over the weekend, but will 
do after Jan 1.

-Robin
--
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: [2.6.24 patch] restore blackfin HARDWARE_PM support

[Robin Getz]

On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote:
> > > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > > This patch restores the blackfin Hardware Performance Monitor Profiling 
> > > > support that was killed by
> > > > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
> > > > 
> > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> > > > 
> > > 
> > > Yep, this one too must be put back, but kernel/Kconfig.instrumentation
> > > seems like the wrong spot for a blackfin-specific config option (and
> > > this will break the instrumentation menu removal patches in -mm).
> > > 
> > > Can we put this in arch/blackfin/Kconfig instead ?
> > 
> > No, this is a user visible option that belongs into the same menu as
> > "Profling support".
> > 
> 
> Actually, I wonder why these options exist at all rather than being on
> by default when profiling is enabled. There is no such thing as
> "activating the performance monitor profiling" on other architectures.
> What is so special about blackfin that makes it need it ?

This is probably more historical, and you are correct - it should just be part 
of profiling.


> > > > ---
> > > > 
> > > >  kernel/Kconfig.instrumentation |9 +
> > > >  1 file changed, 9 insertions(+)
> > > > 
> > > > 942996f33f81726c5edb012d61ecdad70c55884d 
> > > > diff --git a/kernel/Kconfig.instrumentation 
> > > > b/kernel/Kconfig.instrumentation
> > > > index 97c76ca..e023671 100644
> > > > --- a/kernel/Kconfig.instrumentation
> > > > +++ b/kernel/Kconfig.instrumentation
> > > > @@ -44,2 +44,11 @@ config OPROFILE_MPCORE
> > > >  
> > > > +config HARDWARE_PM
> > > > +   tristate "Hardware Performance Monitor Profiling"
> > > > +   depends on BLACKFIN && PROFILING
> > > > +   help
> > > > + take use of hardware performance monitor to profiling the 
> > > > kernel
> > > > + and application.
> > > > +
> > > > + If unsure, say N.
> > > > +
> > > >  config KPROBES
> > > > 
> > > 
> > > Mathieu Desnoyers
> > 
> > cu
> > Adrian
> > 
> > -- 
> > 
> >"Is there not promise of rain?" Ling Tan asked suddenly out
> > of the darkness. There had been need of rain for many days.
> >"Only a promise," Lao Er said.
> >Pearl S. Buck - Dragon Seed
> > 
> 
--
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: [2.6.24 patch] restore blackfin HARDWARE_PM support

[Robin Getz]

On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered:
 * Adrian Bunk ([EMAIL PROTECTED]) wrote:
  On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote:
   * Adrian Bunk ([EMAIL PROTECTED]) wrote:
This patch restores the blackfin Hardware Performance Monitor Profiling 
support that was killed by
commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

   
   Yep, this one too must be put back, but kernel/Kconfig.instrumentation
   seems like the wrong spot for a blackfin-specific config option (and
   this will break the instrumentation menu removal patches in -mm).
   
   Can we put this in arch/blackfin/Kconfig instead ?
  
  No, this is a user visible option that belongs into the same menu as
  Profling support.
  
 
 Actually, I wonder why these options exist at all rather than being on
 by default when profiling is enabled. There is no such thing as
 activating the performance monitor profiling on other architectures.
 What is so special about blackfin that makes it need it ?

This is probably more historical, and you are correct - it should just be part 
of profiling.


---

 kernel/Kconfig.instrumentation |9 +
 1 file changed, 9 insertions(+)

942996f33f81726c5edb012d61ecdad70c55884d 
diff --git a/kernel/Kconfig.instrumentation 
b/kernel/Kconfig.instrumentation
index 97c76ca..e023671 100644
--- a/kernel/Kconfig.instrumentation
+++ b/kernel/Kconfig.instrumentation
@@ -44,2 +44,11 @@ config OPROFILE_MPCORE
 
+config HARDWARE_PM
+   tristate Hardware Performance Monitor Profiling
+   depends on BLACKFIN  PROFILING
+   help
+ take use of hardware performance monitor to profiling the 
kernel
+ and application.
+
+ If unsure, say N.
+
 config KPROBES

   
   Mathieu Desnoyers
  
  cu
  Adrian
  
  -- 
  
 Is there not promise of rain? Ling Tan asked suddenly out
  of the darkness. There had been need of rain for many days.
 Only a promise, Lao Er said.
 Pearl S. Buck - Dragon Seed
  
 
--
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 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
> On Nov 24, 2007 2:43 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
> > > It could be a runtime if() but we don't currently have the is_mach() all
> > > set up properly today.
> > >
> > > This is because on most systems that Blackfin ships on - memory is the
> > > dominate cost of the system, and end users don't want to take the either
> > > the storage (flash) hit of having code they don't use, or the run time
> > > (DRAM) overhead. They are fine with compiling 2 kernels for two
> > > platforms if it means things are cheaper. :)
> > >
> > > That being said, we still need to go back, and add things properly - and
> > > just let gcc optimise things away if it is not used - c code is more
> > > maintainable than all the ifdefs we have today.
> > >
> > > This is the goal - it will just take a little bit to get there.
> >
> > For now I suspect you could at least define machine_is_bf52x() and
> > machine_is_bf54x() which are hard-coded to either zero or one according
> > to the configuration, and at least you wouldn't need to add ifdefs to
> > drivers.
> >
> 
> We got some plan to do this, but maybe cpu_is_bf52x() and
> cpu_is_bf54x() are better.

Which was one of the reasons I think we were waiting/confused. There doesn't 
seem to be any consistancy between:

cpu_is_

which I assume refers to specific processor/chipset/SoC implementation?
cpu_is_ixp42x
cpu_is_ixp43x
cpu_is_ixp46x

mach_is_

which I assume refers to a specific platform:

mach_is_dreamcast
mach_is_hp6xx
mach_is_r7780mp
mach_is_r7780rp

machine_is_

which I assume refers to a specific platform:

machine_is_jornada56x
machine_is_jornada720
machine_is_nokia770

So, we should use cpu_is_ as Bryan suggested?

-Robin
-
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 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
 On Nov 24, 2007 2:43 PM, David Woodhouse [EMAIL PROTECTED] wrote:
 
  On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
   It could be a runtime if() but we don't currently have the is_mach() all
   set up properly today.
  
   This is because on most systems that Blackfin ships on - memory is the
   dominate cost of the system, and end users don't want to take the either
   the storage (flash) hit of having code they don't use, or the run time
   (DRAM) overhead. They are fine with compiling 2 kernels for two
   platforms if it means things are cheaper. :)
  
   That being said, we still need to go back, and add things properly - and
   just let gcc optimise things away if it is not used - c code is more
   maintainable than all the ifdefs we have today.
  
   This is the goal - it will just take a little bit to get there.
 
  For now I suspect you could at least define machine_is_bf52x() and
  machine_is_bf54x() which are hard-coded to either zero or one according
  to the configuration, and at least you wouldn't need to add ifdefs to
  drivers.
 
 
 We got some plan to do this, but maybe cpu_is_bf52x() and
 cpu_is_bf54x() are better.

Which was one of the reasons I think we were waiting/confused. There doesn't 
seem to be any consistancy between:

cpu_is_

which I assume refers to specific processor/chipset/SoC implementation?
cpu_is_ixp42x
cpu_is_ixp43x
cpu_is_ixp46x

mach_is_

which I assume refers to a specific platform:

mach_is_dreamcast
mach_is_hp6xx
mach_is_r7780mp
mach_is_r7780rp

machine_is_

which I assume refers to a specific platform:

machine_is_jornada56x
machine_is_jornada720
machine_is_nokia770

So, we should use cpu_is_ as Bryan suggested?

-Robin
-
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 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
> On Fri, 23 Nov 2007 22:25:29 +0800
> "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> 
> > On Nov 23, 2007 6:19 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> > > >
> > > > +#ifdef CONFIG_BF54x
> > > > /* Setup DMAC1 channel mux for NFC which shared with SDH
> > > > */ val = bfin_read_DMAC1_PERIMUX();
> > > > val &= 0xFFFE;
> > > > bfin_write_DMAC1_PERIMUX(val);
> > > > SSYNC();
> > > > -
> > > > +#endif
> > >
> > > You can't build a multiplatform kernel which runs on BF52x and
> > > BF54x?
> > 
> > There are some hardware difference between BF52x and BF54x. We have
> > to do this.
> > 
> 
> well does it need to be an #ifdef, or can it be a runtime if() ?

It could be a runtime if() but we don't currently have the is_mach() all set 
up properly today.

This is because on most systems that Blackfin ships on - memory is the 
dominate cost of the system, and end users don't want to take the either the 
storage (flash) hit of having code they don't use, or the run time (DRAM) 
overhead. They are fine with compiling 2 kernels for two platforms if it 
means things are cheaper. :)

That being said, we still need to go back, and add things properly - and just 
let gcc optimise things away if it is not used - c code is more maintainable 
than all the ifdefs we have today.

This is the goal - it will just take a little bit to get there.

-Robin
-
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 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
 On Fri, 23 Nov 2007 22:25:29 +0800
 Bryan Wu [EMAIL PROTECTED] wrote:
 
  On Nov 23, 2007 6:19 PM, David Woodhouse [EMAIL PROTECTED] wrote:
  
   On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
   
+#ifdef CONFIG_BF54x
/* Setup DMAC1 channel mux for NFC which shared with SDH
*/ val = bfin_read_DMAC1_PERIMUX();
val = 0xFFFE;
bfin_write_DMAC1_PERIMUX(val);
SSYNC();
-
+#endif
  
   You can't build a multiplatform kernel which runs on BF52x and
   BF54x?
  
  There are some hardware difference between BF52x and BF54x. We have
  to do this.
  
 
 well does it need to be an #ifdef, or can it be a runtime if() ?

It could be a runtime if() but we don't currently have the is_mach() all set 
up properly today.

This is because on most systems that Blackfin ships on - memory is the 
dominate cost of the system, and end users don't want to take the either the 
storage (flash) hit of having code they don't use, or the run time (DRAM) 
overhead. They are fine with compiling 2 kernels for two platforms if it 
means things are cheaper. :)

That being said, we still need to go back, and add things properly - and just 
let gcc optimise things away if it is not used - c code is more maintainable 
than all the ifdefs we have today.

This is the goal - it will just take a little bit to get there.

-Robin
-
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] remove support for un-needed _extratext section

[Robin Getz]

On Mon 29 Oct 2007 18:22, Andrew Morton pondered:

> I hit numerous rejects here.  I am not sure which kernel you patched but
> I suspect it was not an up-to-date one.

Sorry about that - I will do so in the future. Thanks for reviewing and fixing 
up.

> > --- kernel/kallsyms.c   (revision 3780)
> > +++ kernel/kallsyms.c   (working copy)
> 
> Please prepare patches in `patch -p1' form.  This should have been
> 
> --- foo/kernel/kallsyms.c (revision 3780)
> +++ bar/kernel/kallsyms.c (working copy)

Sorry twice.

> >  */
> > if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
> > "_etext")) ||
> > -   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> > "_einittext")) ||
> > -   (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
> > "_eextratext")))
> > +   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> > "_einittext")))
> > return 0;
> > }
> 
> I don't understand why this hunk is changing _einittext handling, and I
> suspect this was a mistake, so I left that bit out.

I didn't think I did change the _einittext handling - just removed
_eextratext, and removed the trailing ||, and closed the parentheses for 
the if statement.

-  (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")) ||
+  (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")))

I think this is the same as what you have here - isn't it?

> - if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
> "_etext")) ||
> - (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> "_einittext")) ||
> - (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
> "_eextratext")))
> + if ((s->addr == _etext &&
> + strcmp((char*)s->sym + offset, "_etext")) ||
> + (s->addr == _einittext &&
> + strcmp((char*)s->sym + offset, "_einittext")))
>   return 0;

?
-
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] remove support for un-needed _extratext section

[Robin Getz]

On Mon 29 Oct 2007 18:22, Andrew Morton pondered:

 I hit numerous rejects here.  I am not sure which kernel you patched but
 I suspect it was not an up-to-date one.

Sorry about that - I will do so in the future. Thanks for reviewing and fixing 
up.

  --- kernel/kallsyms.c   (revision 3780)
  +++ kernel/kallsyms.c   (working copy)
 
 Please prepare patches in `patch -p1' form.  This should have been
 
 --- foo/kernel/kallsyms.c (revision 3780)
 +++ bar/kernel/kallsyms.c (working copy)

Sorry twice.

   */
  if ((s-addr == _etext  strcmp((char*)s-sym + offset, 
  _etext)) ||
  -   (s-addr == _einittext  strcmp((char*)s-sym + offset, 
  _einittext)) ||
  -   (s-addr == _eextratext  strcmp((char*)s-sym + offset, 
  _eextratext)))
  +   (s-addr == _einittext  strcmp((char*)s-sym + offset, 
  _einittext)))
  return 0;
  }
 
 I don't understand why this hunk is changing _einittext handling, and I
 suspect this was a mistake, so I left that bit out.

I didn't think I did change the _einittext handling - just removed
_eextratext, and removed the trailing ||, and closed the parentheses for 
the if statement.

-  (s-addr == _einittext  strcmp((char*)s-sym + offset, _einittext)) ||
+  (s-addr == _einittext  strcmp((char*)s-sym + offset, _einittext)))

I think this is the same as what you have here - isn't it?

 - if ((s-addr == _etext  strcmp((char*)s-sym + offset, 
 _etext)) ||
 - (s-addr == _einittext  strcmp((char*)s-sym + offset, 
 _einittext)) ||
 - (s-addr == _eextratext  strcmp((char*)s-sym + offset, 
 _eextratext)))
 + if ((s-addr == _etext 
 + strcmp((char*)s-sym + offset, _etext)) ||
 + (s-addr == _einittext 
 + strcmp((char*)s-sym + offset, _einittext)))
   return 0;

?
-
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] remove support for un-needed _extratext section

[Robin Getz]

From: Robin Getz <[EMAIL PROTECTED]>

when passing a zero address to kallsyms_lookup(), the kernel thought it was a
valid kernel address, even if it is not. This is because is_ksym_addr() called 
is_kernel_extratext() and checked against labels that don't exist on many 
archs (which default as zero). Since PPC was the only kernel which defines 
_extra_text, (in 2005), and no longer needs it, this patch removes _extra_text
support.

 arch/ppc/kernel/vmlinux.lds.S  |5 -
 include/asm-generic/sections.h |2 --
 kernel/kallsyms.c  |   11 +--
 scripts/kallsyms.c |   12 +++-
 4 files changed, 4 insertions(+), 26 deletions(-)

Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
cc: David Woodhouse <[EMAIL PROTECTED]>
cc: Jon Loeliger <[EMAIL PROTECTED]>
cc: Paul Mackerras <[EMAIL PROTECTED]>



For some history (provided by Jon):
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019734.html
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019736.html
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019751.html

Index: kernel/kallsyms.c
===
--- kernel/kallsyms.c   (revision 3780)
+++ kernel/kallsyms.c   (working copy)
@@ -48,14 +48,6 @@
return 0;
 }
 
-static inline int is_kernel_extratext(unsigned long addr)
-{
-   if (addr >= (unsigned long)_sextratext
-   && addr <= (unsigned long)_eextratext)
-   return 1;
-   return 0;
-}
-
 static inline int is_kernel_text(unsigned long addr)
 {
if ((addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)
@@ -79,8 +71,7 @@
if (all_var)
return is_kernel(addr);
 
-   return is_kernel_text(addr) || is_kernel_inittext(addr) ||
-   is_kernel_extratext(addr);
+   return is_kernel_text(addr) || is_kernel_inittext(addr);
 }
 
 /* expand a compressed symbol data into the resulting uncompressed string,
Index: include/asm-generic/sections.h
===
--- include/asm-generic/sections.h  (revision 3780)
+++ include/asm-generic/sections.h  (working copy)
@@ -8,8 +8,6 @@
 extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
-extern char _sextratext[] __attribute__((weak));
-extern char _eextratext[] __attribute__((weak));
 extern char _end[];
 extern char __per_cpu_start[], __per_cpu_end[];
 extern char __kprobes_text_start[], __kprobes_text_end[];
Index: scripts/kallsyms.c
===
--- scripts/kallsyms.c  (revision 3780)
+++ scripts/kallsyms.c  (working copy)
@@ -45,7 +45,7 @@
 
 static struct sym_entry *table;
 static unsigned int table_size, table_cnt;
-static unsigned long long _text, _stext, _etext, _sinittext, _einittext, 
_sextratext, _eextratext;
+static unsigned long long _text, _stext, _etext, _sinittext, _einittext;
 static unsigned long long _stext_l1, _etext_l1;
 static int all_symbols = 0;
 static char symbol_prefix_char = '\0';
@@ -104,10 +104,6 @@
_sinittext = s->addr;
else if (strcmp(sym, "_einittext") == 0)
_einittext = s->addr;
-   else if (strcmp(sym, "_sextratext") == 0)
-   _sextratext = s->addr;
-   else if (strcmp(sym, "_eextratext") == 0)
-   _eextratext = s->addr;
else if (strcmp(sym, "_stext_l1" ) == 0)
_stext_l1 = s->addr;
else if (strcmp(sym, "_etext_l1" ) == 0)
@@ -175,18 +171,16 @@
if (!all_symbols) {
if ((s->addr < _stext || s->addr > _etext)
&& (s->addr < _sinittext || s->addr > _einittext)
-   && (s->addr < _sextratext || s->addr > _eextratext)
&& (s->addr < _stext_l1 || s->addr > _etext_l1))
return 0;
/* Corner case.  Discard any symbols with the same value as
-* _etext _einittext or _eextratext; they can move between pass
+* _etext; they can move between pass
 * 1 and 2 when the kallsyms data are added.  If these symbols
 * move then they may get dropped in pass 2, which breaks the
 * kallsyms rules.
 */
if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
"_etext")) ||
-   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
"_einittext")) ||
-   (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
"_eextratext")))
+   (s->addr == _einittext && strcmp((ch

Re: history of extratext sections?

[Robin Getz]

On Wed 24 Oct 2007 08:36, Robin Getz pondered:
> Paul:
> 
> I noticed that when passing a zero address to kallsyms_lookup(), the
> kernel thought it was a valid kernel address, even if it was not for the
> specific architecture it was running on.
> 
> This was because is_kernel_extratext() was checking against labels that
> don't exist on many archs. Since PPC is the only kernel which defines
> _extra_text, (which doesn't seem to be used anymore?) there are three options:
>  - make the check dependant on PPC
>  - make the check dependant on extratext being populated
>  - remove _extra_text support from:
> linux-2.6.x/arch/ppc/kernel/vmlinux.lds.S
> linux-2.6.x/include/asm-generic/sections.h
> linux-2.6.x/kernel/kallsyms.c
> linux-2.6.x/scripts/kallsyms.c
> 
> Since I don't know the history on that label I thought I would ask
> (since PPC seem to be the only arch using it) before I sent a patch.

OK, it looks like:

David Woodhouse added this functionality 5 May 2005:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=075d6eb16d273dab7b7b4b83fcee8bce4ee387ed

and then Jon Loeliger removed everything in this section 17 Sep 2005
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6c45ab992e4299c869fb26427944a8f8ea177024

David/Jon:

Is this section still used on PPC, or can the entire support for extratext be 
removed?

Thanks
-
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: history of extratext sections?

[Robin Getz]

On Wed 24 Oct 2007 08:36, Robin Getz pondered:
 Paul:
 
 I noticed that when passing a zero address to kallsyms_lookup(), the
 kernel thought it was a valid kernel address, even if it was not for the
 specific architecture it was running on.
 
 This was because is_kernel_extratext() was checking against labels that
 don't exist on many archs. Since PPC is the only kernel which defines
 _extra_text, (which doesn't seem to be used anymore?) there are three options:
  - make the check dependant on PPC
  - make the check dependant on extratext being populated
  - remove _extra_text support from:
 linux-2.6.x/arch/ppc/kernel/vmlinux.lds.S
 linux-2.6.x/include/asm-generic/sections.h
 linux-2.6.x/kernel/kallsyms.c
 linux-2.6.x/scripts/kallsyms.c
 
 Since I don't know the history on that label I thought I would ask
 (since PPC seem to be the only arch using it) before I sent a patch.

OK, it looks like:

David Woodhouse added this functionality 5 May 2005:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=075d6eb16d273dab7b7b4b83fcee8bce4ee387ed

and then Jon Loeliger removed everything in this section 17 Sep 2005
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6c45ab992e4299c869fb26427944a8f8ea177024

David/Jon:

Is this section still used on PPC, or can the entire support for extratext be 
removed?

Thanks
-
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] remove support for un-needed _extratext section

[Robin Getz]

From: Robin Getz [EMAIL PROTECTED]

when passing a zero address to kallsyms_lookup(), the kernel thought it was a
valid kernel address, even if it is not. This is because is_ksym_addr() called 
is_kernel_extratext() and checked against labels that don't exist on many 
archs (which default as zero). Since PPC was the only kernel which defines 
_extra_text, (in 2005), and no longer needs it, this patch removes _extra_text
support.

 arch/ppc/kernel/vmlinux.lds.S  |5 -
 include/asm-generic/sections.h |2 --
 kernel/kallsyms.c  |   11 +--
 scripts/kallsyms.c |   12 +++-
 4 files changed, 4 insertions(+), 26 deletions(-)

Signed-off-by: Robin Getz [EMAIL PROTECTED]
cc: David Woodhouse [EMAIL PROTECTED]
cc: Jon Loeliger [EMAIL PROTECTED]
cc: Paul Mackerras [EMAIL PROTECTED]



For some history (provided by Jon):
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019734.html
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019736.html
 http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019751.html

Index: kernel/kallsyms.c
===
--- kernel/kallsyms.c   (revision 3780)
+++ kernel/kallsyms.c   (working copy)
@@ -48,14 +48,6 @@
return 0;
 }
 
-static inline int is_kernel_extratext(unsigned long addr)
-{
-   if (addr = (unsigned long)_sextratext
-addr = (unsigned long)_eextratext)
-   return 1;
-   return 0;
-}
-
 static inline int is_kernel_text(unsigned long addr)
 {
if ((addr = (unsigned long)_stext  addr = (unsigned long)_etext)
@@ -79,8 +71,7 @@
if (all_var)
return is_kernel(addr);
 
-   return is_kernel_text(addr) || is_kernel_inittext(addr) ||
-   is_kernel_extratext(addr);
+   return is_kernel_text(addr) || is_kernel_inittext(addr);
 }
 
 /* expand a compressed symbol data into the resulting uncompressed string,
Index: include/asm-generic/sections.h
===
--- include/asm-generic/sections.h  (revision 3780)
+++ include/asm-generic/sections.h  (working copy)
@@ -8,8 +8,6 @@
 extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
-extern char _sextratext[] __attribute__((weak));
-extern char _eextratext[] __attribute__((weak));
 extern char _end[];
 extern char __per_cpu_start[], __per_cpu_end[];
 extern char __kprobes_text_start[], __kprobes_text_end[];
Index: scripts/kallsyms.c
===
--- scripts/kallsyms.c  (revision 3780)
+++ scripts/kallsyms.c  (working copy)
@@ -45,7 +45,7 @@
 
 static struct sym_entry *table;
 static unsigned int table_size, table_cnt;
-static unsigned long long _text, _stext, _etext, _sinittext, _einittext, 
_sextratext, _eextratext;
+static unsigned long long _text, _stext, _etext, _sinittext, _einittext;
 static unsigned long long _stext_l1, _etext_l1;
 static int all_symbols = 0;
 static char symbol_prefix_char = '\0';
@@ -104,10 +104,6 @@
_sinittext = s-addr;
else if (strcmp(sym, _einittext) == 0)
_einittext = s-addr;
-   else if (strcmp(sym, _sextratext) == 0)
-   _sextratext = s-addr;
-   else if (strcmp(sym, _eextratext) == 0)
-   _eextratext = s-addr;
else if (strcmp(sym, _stext_l1 ) == 0)
_stext_l1 = s-addr;
else if (strcmp(sym, _etext_l1 ) == 0)
@@ -175,18 +171,16 @@
if (!all_symbols) {
if ((s-addr  _stext || s-addr  _etext)
 (s-addr  _sinittext || s-addr  _einittext)
-(s-addr  _sextratext || s-addr  _eextratext)
 (s-addr  _stext_l1 || s-addr  _etext_l1))
return 0;
/* Corner case.  Discard any symbols with the same value as
-* _etext _einittext or _eextratext; they can move between pass
+* _etext; they can move between pass
 * 1 and 2 when the kallsyms data are added.  If these symbols
 * move then they may get dropped in pass 2, which breaks the
 * kallsyms rules.
 */
if ((s-addr == _etext  strcmp((char*)s-sym + offset, 
_etext)) ||
-   (s-addr == _einittext  strcmp((char*)s-sym + offset, 
_einittext)) ||
-   (s-addr == _eextratext  strcmp((char*)s-sym + offset, 
_eextratext)))
+   (s-addr == _einittext  strcmp((char*)s-sym + offset, 
_einittext)))
return 0;
}
 
Index: arch/ppc/kernel/vmlinux.lds.S
===
--- arch/ppc/kernel/vmlinux.lds.S   (revision 3780)
+++ arch/ppc/kernel/vmlinux.lds.S   (working copy)
@@ -144,11 +144,6 @@
 
   . = ALIGN(4096);
   __init_end

history of extratext sections?

[Robin Getz]

Paul:

I noticed that when passing a zero address to kallsyms_lookup(), the kernel 
thought it was a valid kernel address, even if it was not for the specific 
architecture I was running things on.

This was because is_kernel_extratext() was checking against labels that don't 
exist on many archs. Since PPC is the only kernel which defines _extra_text, 
(which doesn't seem to be used anymore?) there are three options:
 - make the check dependant on PPC
 - make the check dependant on extratext being populated
 - remove _extra_text support from:
linux-2.6.x/arch/ppc/kernel/vmlinux.lds.S
linux-2.6.x/include/asm-generic/sections.h
linux-2.6.x/kernel/kallsyms.c
linux-2.6.x/scripts/kallsyms.c

Since I don't know the history on that label I thought I would ask (since you 
seem to be the only arch using it) before I sent a patch.

-Robin

Because #1 & #2 are trivial, here is what I was thinking:

 - make the check dependant on PPC
===
--- linux-2.6.x/kernel/kallsyms.c   (revision 3760)
+++ linux-2.6.x/kernel/kallsyms.c   (working copy)
@@ -51,7 +51,8 @@
 static inline int is_kernel_extratext(unsigned long addr)
 {
+ #ifdef CONFIG_PPC
if (addr >= (unsigned long)_sextratext
&& addr <= (unsigned long)_eextratext)
return 1;
+ #endif
return 0;
 }

OR 

 - make the check dependant on extratext being populated
===
--- linux-2.6.x/kernel/kallsyms.c   (revision 3760)
+++ linux-2.6.x/kernel/kallsyms.c   (working copy)
@@ -51,7 +51,8 @@
 static inline int is_kernel_extratext(unsigned long addr)
 {
if (addr >= (unsigned long)_sextratext
-   && addr <= (unsigned long)_eextratext)
+   && addr <= (unsigned long)_eextratext
+   && _sextratext && _eextratext)
return 1;
return 0;
 }
-
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/

history of extratext sections?

[Robin Getz]

Paul:

I noticed that when passing a zero address to kallsyms_lookup(), the kernel 
thought it was a valid kernel address, even if it was not for the specific 
architecture I was running things on.

This was because is_kernel_extratext() was checking against labels that don't 
exist on many archs. Since PPC is the only kernel which defines _extra_text, 
(which doesn't seem to be used anymore?) there are three options:
 - make the check dependant on PPC
 - make the check dependant on extratext being populated
 - remove _extra_text support from:
linux-2.6.x/arch/ppc/kernel/vmlinux.lds.S
linux-2.6.x/include/asm-generic/sections.h
linux-2.6.x/kernel/kallsyms.c
linux-2.6.x/scripts/kallsyms.c

Since I don't know the history on that label I thought I would ask (since you 
seem to be the only arch using it) before I sent a patch.

-Robin

Because #1  #2 are trivial, here is what I was thinking:

 - make the check dependant on PPC
===
--- linux-2.6.x/kernel/kallsyms.c   (revision 3760)
+++ linux-2.6.x/kernel/kallsyms.c   (working copy)
@@ -51,7 +51,8 @@
 static inline int is_kernel_extratext(unsigned long addr)
 {
+ #ifdef CONFIG_PPC
if (addr = (unsigned long)_sextratext
 addr = (unsigned long)_eextratext)
return 1;
+ #endif
return 0;
 }

OR 

 - make the check dependant on extratext being populated
===
--- linux-2.6.x/kernel/kallsyms.c   (revision 3760)
+++ linux-2.6.x/kernel/kallsyms.c   (working copy)
@@ -51,7 +51,8 @@
 static inline int is_kernel_extratext(unsigned long addr)
 {
if (addr = (unsigned long)_sextratext
-addr = (unsigned long)_eextratext)
+addr = (unsigned long)_eextratext
+_sextratext  _eextratext)
return 1;
return 0;
 }
-
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 try #4] Input/Joystick Driver: add support AD7142 joystick driver

[Robin Getz]

On Wed 17 Oct 2007 10:07, Jean Delvare pondered:
> Hi Bryan,
> 
> On Wed, 17 Oct 2007 15:12:00 +0800, Bryan Wu wrote:
> > Subject: [PATCH try #4] Input/Joystick Driver: add support AD7142
> joystick driver
> > +#define AD7142_I2C_ADDR0x2C
> 
> Not worth a define IMHO, as you use it only once and the context is
> completely clear.

> > +static int ad7142_probe(struct i2c_adapter *adap, int addr, int kind)
> > +{
> > +   struct ad7142_data *data;
> > +   struct i2c_client *client;
> > +   struct input_dev *input_dev;
> > +   int rc;
> > +
> > +   data = kzalloc(sizeof(struct ad7142_data), GFP_KERNEL);
> > +   if (!data)
> > +   return -ENOMEM;
> > +
> > +   client = >client;
> > +
> > +   strlcpy(client->name, AD7142_DRV_NAME, I2C_NAME_SIZE);
> > +   client->addr = addr;
> > +   client->adapter = adap;
> > +   client->driver = _driver;
> > +
> 
> This is unsafe: you're not doing any kind of detection here. 

I assume that in order to do things "right", all possible addresses should be 
probed (for this part, that is 0x2C, 0x2D, 0x2E, 0x2F)?

And it should read a device ID (register 0x17 == 0xE62n (where n==rev number))

How many values/registers do you need to read before you say "this is the 
one"? rather than a temp sensor with a similar value somewhere. Is there a 
table anywhere that maps this out?

It is pretty difficult just to probe on reset values, since that disallows 
warm resets. This part - like most other I2C parts, has no external reset, 
only software reset.

> The risk is mitigated by the fact
> that your driver is currently built for Blackfin only, but this might
> change in the future. 

The hope is that others can use it - it shouldn't be specific to Blackfin.

> This is a very good reason to switch to a 
> new-style i2c 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/

Re: [PATCH try #4] Input/Joystick Driver: add support AD7142 joystick driver

[Robin Getz]

On Wed 17 Oct 2007 10:07, Jean Delvare pondered:
 Hi Bryan,
 
 On Wed, 17 Oct 2007 15:12:00 +0800, Bryan Wu wrote:
  Subject: [PATCH try #4] Input/Joystick Driver: add support AD7142
 joystick driver
  +#define AD7142_I2C_ADDR0x2C
 
 Not worth a define IMHO, as you use it only once and the context is
 completely clear.

  +static int ad7142_probe(struct i2c_adapter *adap, int addr, int kind)
  +{
  +   struct ad7142_data *data;
  +   struct i2c_client *client;
  +   struct input_dev *input_dev;
  +   int rc;
  +
  +   data = kzalloc(sizeof(struct ad7142_data), GFP_KERNEL);
  +   if (!data)
  +   return -ENOMEM;
  +
  +   client = data-client;
  +
  +   strlcpy(client-name, AD7142_DRV_NAME, I2C_NAME_SIZE);
  +   client-addr = addr;
  +   client-adapter = adap;
  +   client-driver = ad7142_driver;
  +
 
 This is unsafe: you're not doing any kind of detection here. 

I assume that in order to do things right, all possible addresses should be 
probed (for this part, that is 0x2C, 0x2D, 0x2E, 0x2F)?

And it should read a device ID (register 0x17 == 0xE62n (where n==rev number))

How many values/registers do you need to read before you say this is the 
one? rather than a temp sensor with a similar value somewhere. Is there a 
table anywhere that maps this out?

It is pretty difficult just to probe on reset values, since that disallows 
warm resets. This part - like most other I2C parts, has no external reset, 
only software reset.

 The risk is mitigated by the fact
 that your driver is currently built for Blackfin only, but this might
 change in the future. 

The hope is that others can use it - it shouldn't be specific to Blackfin.

 This is a very good reason to switch to a 
 new-style i2c 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/

Re: [PATCH 3/3] Blackfin serial driver: this driver enable SPORTs on Blackfin emulate UART

[Robin Getz]

On Mon 15 Oct 2007 16:33, Andrew Morton pondered:
> 
> > Subject: [PATCH 3/3] Blackfin serial driver: this driver enable SPORTs
> on Blackfin emulate UART
> 
> That's a bit hard to parse.
> 

Blackfin's have a synchronous Serial Peripheral pORT (SPORT). 

Unlike SPI, UART, I2C, or CAN interfaces which are designed for specific 
industry standard compatible communication only, the SPORT support a variety 
(software programmable) serial data communication protocols:
 - A-law or µ-law companding according to G.711 specification
 - Multichannel or Time-Division-Multiplexed (TDM) modes
 - Stereo Audio I2S Mode
 - TDM Modes for Multi-Channel audio codecs
 - H.100 Telephony standard support
 - others, but if anyone really cares, they need to read the chip specs...

Bryan's patch takes the SPORT, and makes a standard UART out of it 
(exposing /dev/ttySS0) for those people who don't have enough hardware UARTs 
in their system.

Is it a SPORT driver that emulates a UART, or a UART driver on the SPORT? I 
think it is the latter...

Maybe:

[PATCH 3/3] Blackfin serial driver: enables a UART interface for the SPORT


Which still doesn't make any sense, until you know what a SPORT is :)

-Robin
-
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 3/3] Blackfin serial driver: this driver enable SPORTs on Blackfin emulate UART

[Robin Getz]

On Mon 15 Oct 2007 16:33, Andrew Morton pondered:
 
  Subject: [PATCH 3/3] Blackfin serial driver: this driver enable SPORTs
 on Blackfin emulate UART
 
 That's a bit hard to parse.
 

Blackfin's have a synchronous Serial Peripheral pORT (SPORT). 

Unlike SPI, UART, I2C, or CAN interfaces which are designed for specific 
industry standard compatible communication only, the SPORT support a variety 
(software programmable) serial data communication protocols:
 - A-law or µ-law companding according to G.711 specification
 - Multichannel or Time-Division-Multiplexed (TDM) modes
 - Stereo Audio I2S Mode
 - TDM Modes for Multi-Channel audio codecs
 - H.100 Telephony standard support
 - others, but if anyone really cares, they need to read the chip specs...

Bryan's patch takes the SPORT, and makes a standard UART out of it 
(exposing /dev/ttySS0) for those people who don't have enough hardware UARTs 
in their system.

Is it a SPORT driver that emulates a UART, or a UART driver on the SPORT? I 
think it is the latter...

Maybe:

[PATCH 3/3] Blackfin serial driver: enables a UART interface for the SPORT


Which still doesn't make any sense, until you know what a SPORT is :)

-Robin
-
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] Replace __attribute_pure__ with __pure

[Robin Getz]

On Fri 5 Oct 2007 09:13, Ralf Baechle pondered:
> And btw why does Analog list half their employees in the MAINTAINERS
> entry?
> Seems a little over the top ...

Yeah, the original submission got a little carried away...

We can cut that down to just Bryan and the mailing list I think.

-Robin
-
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] Replace __attribute_pure__ with __pure

[Robin Getz]

On Fri 5 Oct 2007 09:13, Ralf Baechle pondered:
 And btw why does Analog list half their employees in the MAINTAINERS
 entry?
 Seems a little over the top ...

Yeah, the original submission got a little carried away...

We can cut that down to just Bryan and the mailing list I think.

-Robin
-
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: Blackfin Ethernet MAC driver compile error

[Robin Getz]

On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
> The Blackfin Ethernet MAC driver does not compile. It seems the driver is
> missing some pinmux defines.
> 
>   CC  drivers/net/bfin_mac.o
> drivers/net/bfin_mac.c: In function 'setup_pin_mux':
> drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared (first use in
> this function)
> drivers/net/bfin_mac.c:275: error: (Each undeclared identifier is
> reported only once
> drivers/net/bfin_mac.c:275: error: for each function it appears in.)

Unfortunately, Bryan is out for the week, so he can't update things..

The updates to include/asm-blackfin/mach-bf537/portmux.h seem to have been 
missing from Bryan's git tree, and therefore were not pushed to Linus's tree.

Sigh. - Sorry about that.

When Bryan gets back, he will update things, but for now, this might work. (I 
don't know if there are any other interdependencies).


--- portmux.h   2007-10-02 11:18:34.0 -0400
+++ ./linux-2.6.x/include/asm-blackfin/mach-bf537/portmux.h 2007-08-18 
19:37:22.0 -0400
@@ -99,11 +99,44 @@
 #define P_SPORT0_DRPRI (P_DEFINED | P_IDENT(PORT_PJ8) | P_FUNCT(0))
 #define P_SPORT0_TSCLK (P_DEFINED | P_IDENT(PORT_PJ9) | P_FUNCT(0))
 #define P_SPORT0_TFS   (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(0))
-#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
+#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(0))
 #define P_CAN0_RX  (P_DEFINED | P_IDENT(PORT_PJ4) | P_FUNCT(1))
 #define P_CAN0_TX  (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(1))
 #define P_SPI0_SSEL3   (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(1))
 #define P_SPI0_SSEL2   (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
 #define P_SPI0_SSEL7   (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(2))
 
-#endif /* _MACH_PORTMUX_H_ */
+#define P_MII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxD2, \
+   P_MII0_ETxD3, \
+   P_MII0_ETxEN, \
+   P_MII0_TxCLK, \
+   P_MII0_PHYINT, \
+   P_MII0_COL, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxD2, \
+   P_MII0_ERxD3, \
+   P_MII0_ERxDV, \
+   P_MII0_ERxCLK, \
+   P_MII0_ERxER, \
+   P_MII0_CRS, \
+   P_MDC, \
+   P_MDIO, 0}
+
+
+#define P_RMII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxEN, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxER, \
+   P_RMII0_REF_CLK, \
+   P_RMII0_MDINT, \
+   P_RMII0_CRS_DV, \
+   P_MDC, \
+   P_MDIO, 0}
+#endif /* _MACH_PORTMUX_H_ */

> drivers/net/bfin_mac.c:279: error: implicit declaration of function
> 'peripheral_request_list'
> drivers/net/bfin_mac.c:285: error: implicit declaration of function
> 'peripheral_free_list'

Arg.

This was in an arch/blackfin/kernel/bfin_gpio.c update that hasn't seem to 
made it either.

In the future - we will make sure driver submissions are done in the correct 
order - so the proper infrastructure is in the tree before the driver is 
submitted. - Sorry.



Index: arch/blackfin/kernel/bfin_gpio.c
===
--- arch/blackfin/kernel/bfin_gpio.c(revision 3403)
+++ arch/blackfin/kernel/bfin_gpio.c(revision 3404)
@@ -84,6 +84,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef BF533_FAMILY
@@ -115,8 +116,12 @@
 };
 #endif
 
-static unsigned short reserved_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_gpio_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_peri_map[gpio_bank(MAX_BLACKFIN_GPIOS + 16)];
+char *str_ident = NULL;
 
+#define RESOURCE_LABEL_SIZE 16
+
 #ifdef CONFIG_PM
 static unsigned short wakeup_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
 static unsigned char wakeup_flags_map[MAX_BLACKFIN_GPIOS];
@@ -143,13 +148,39 @@
return 0;
 }
 
+static void set_label(unsigned short ident, const char *label)
+{
+
+   if (label && str_ident) {
+   strncpy(str_ident + ident * RESOURCE_LABEL_SIZE, label,
+RESOURCE_LABEL_SIZE);
+   str_ident[ident * RESOURCE_LABEL_SIZE +
+RESOURCE_LABEL_SIZE - 1] = 0;
+   }
+}
+
+static char *get_label(unsigned short ident)
+{
+   if (!str_ident)
+   return "UNKNOWN";
+
+   return (str_ident[ident * RESOURCE_LABEL_SIZE] ?
+   (str_ident + ident * RESOURCE_LABEL_SIZE) : "UNKNOWN");
+}
+
+static int cmp_label(unsigned short ident, const char *label)
+{
+   if (label && str_ident)
+   return strncmp(str_ident + ident * RESOURCE_LABEL_SIZE,
+label, strlen(label));
+   else
+   return -EINVAL;
+}
+
 #ifdef BF537_FAMILY
 static void port_setup(unsigned short gpio, unsigned short usage)
 {
if (usage == GPIO_USAGE) {
-   if (*port_fer[gpio_bank(gpio)] & gpio_bit(gpio))
-   printk(KERN_WARNING "bfin-gpio: Possible Conflict with 

Re: Blackfin Ethernet MAC driver compile error

[Robin Getz]

On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
 The Blackfin Ethernet MAC driver does not compile. It seems the driver is
 missing some pinmux defines.
 
   CC  drivers/net/bfin_mac.o
 drivers/net/bfin_mac.c: In function 'setup_pin_mux':
 drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared (first use in
 this function)
 drivers/net/bfin_mac.c:275: error: (Each undeclared identifier is
 reported only once
 drivers/net/bfin_mac.c:275: error: for each function it appears in.)

Unfortunately, Bryan is out for the week, so he can't update things..

The updates to include/asm-blackfin/mach-bf537/portmux.h seem to have been 
missing from Bryan's git tree, and therefore were not pushed to Linus's tree.

Sigh. - Sorry about that.

When Bryan gets back, he will update things, but for now, this might work. (I 
don't know if there are any other interdependencies).


--- portmux.h   2007-10-02 11:18:34.0 -0400
+++ ./linux-2.6.x/include/asm-blackfin/mach-bf537/portmux.h 2007-08-18 
19:37:22.0 -0400
@@ -99,11 +99,44 @@
 #define P_SPORT0_DRPRI (P_DEFINED | P_IDENT(PORT_PJ8) | P_FUNCT(0))
 #define P_SPORT0_TSCLK (P_DEFINED | P_IDENT(PORT_PJ9) | P_FUNCT(0))
 #define P_SPORT0_TFS   (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(0))
-#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
+#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(0))
 #define P_CAN0_RX  (P_DEFINED | P_IDENT(PORT_PJ4) | P_FUNCT(1))
 #define P_CAN0_TX  (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(1))
 #define P_SPI0_SSEL3   (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(1))
 #define P_SPI0_SSEL2   (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
 #define P_SPI0_SSEL7   (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(2))
 
-#endif /* _MACH_PORTMUX_H_ */
+#define P_MII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxD2, \
+   P_MII0_ETxD3, \
+   P_MII0_ETxEN, \
+   P_MII0_TxCLK, \
+   P_MII0_PHYINT, \
+   P_MII0_COL, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxD2, \
+   P_MII0_ERxD3, \
+   P_MII0_ERxDV, \
+   P_MII0_ERxCLK, \
+   P_MII0_ERxER, \
+   P_MII0_CRS, \
+   P_MDC, \
+   P_MDIO, 0}
+
+
+#define P_RMII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxEN, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxER, \
+   P_RMII0_REF_CLK, \
+   P_RMII0_MDINT, \
+   P_RMII0_CRS_DV, \
+   P_MDC, \
+   P_MDIO, 0}
+#endif /* _MACH_PORTMUX_H_ */

 drivers/net/bfin_mac.c:279: error: implicit declaration of function
 'peripheral_request_list'
 drivers/net/bfin_mac.c:285: error: implicit declaration of function
 'peripheral_free_list'

Arg.

This was in an arch/blackfin/kernel/bfin_gpio.c update that hasn't seem to 
made it either.

In the future - we will make sure driver submissions are done in the correct 
order - so the proper infrastructure is in the tree before the driver is 
submitted. - Sorry.



Index: arch/blackfin/kernel/bfin_gpio.c
===
--- arch/blackfin/kernel/bfin_gpio.c(revision 3403)
+++ arch/blackfin/kernel/bfin_gpio.c(revision 3404)
@@ -84,6 +84,7 @@
 #include linux/err.h
 #include asm/blackfin.h
 #include asm/gpio.h
+#include asm/portmux.h
 #include linux/irq.h
 
 #ifdef BF533_FAMILY
@@ -115,8 +116,12 @@
 };
 #endif
 
-static unsigned short reserved_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_gpio_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_peri_map[gpio_bank(MAX_BLACKFIN_GPIOS + 16)];
+char *str_ident = NULL;
 
+#define RESOURCE_LABEL_SIZE 16
+
 #ifdef CONFIG_PM
 static unsigned short wakeup_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
 static unsigned char wakeup_flags_map[MAX_BLACKFIN_GPIOS];
@@ -143,13 +148,39 @@
return 0;
 }
 
+static void set_label(unsigned short ident, const char *label)
+{
+
+   if (label  str_ident) {
+   strncpy(str_ident + ident * RESOURCE_LABEL_SIZE, label,
+RESOURCE_LABEL_SIZE);
+   str_ident[ident * RESOURCE_LABEL_SIZE +
+RESOURCE_LABEL_SIZE - 1] = 0;
+   }
+}
+
+static char *get_label(unsigned short ident)
+{
+   if (!str_ident)
+   return UNKNOWN;
+
+   return (str_ident[ident * RESOURCE_LABEL_SIZE] ?
+   (str_ident + ident * RESOURCE_LABEL_SIZE) : UNKNOWN);
+}
+
+static int cmp_label(unsigned short ident, const char *label)
+{
+   if (label  str_ident)
+   return strncmp(str_ident + ident * RESOURCE_LABEL_SIZE,
+label, strlen(label));
+   else
+   return -EINVAL;
+}
+
 #ifdef BF537_FAMILY
 static void port_setup(unsigned short gpio, unsigned short usage)
 {
if (usage == GPIO_USAGE) {
-   if (*port_fer[gpio_bank(gpio)]  gpio_bit(gpio))
-   printk(KERN_WARNING 

Re: Out of memory management in embedded systems

[Robin Getz]

On Mon 1 Oct 2007 12:27, [EMAIL PROTECTED] pondered:
> overcommit by default is optimistic that if the program requesting the 
> memory actually tries to use it there will be enough (both the fork-exec
> situation and the copy-on-write memory of real forks mean that the
> system ends up useing much less memory then is theoretically allocated).
> 
> switching it to be pessimistic (overcommit 2 IIRC) means that the OOM 
> handler will never kick in, but it means that programs will be told that
> there isn't any memory when there really is enough for the program to 
> work.

I have set it to 2, and still get the OOM if I malloc too much... I never get 
a null back from malloc, no matter what I try.

-Robin
-
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: Out of memory management in embedded systems

[Robin Getz]

On Mon 1 Oct 2007 12:27, [EMAIL PROTECTED] pondered:
 overcommit by default is optimistic that if the program requesting the 
 memory actually tries to use it there will be enough (both the fork-exec
 situation and the copy-on-write memory of real forks mean that the
 system ends up useing much less memory then is theoretically allocated).
 
 switching it to be pessimistic (overcommit 2 IIRC) means that the OOM 
 handler will never kick in, but it means that programs will be told that
 there isn't any memory when there really is enough for the program to 
 work.

I have set it to 2, and still get the OOM if I malloc too much... I never get 
a null back from malloc, no matter what I try.

-Robin
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Thu 20 Sep 2007 11:03, David McCullough pondered:
> I would say that (a) is definately not the case.  I am sure the BF guys
> will say they have been banging us on the head with changes for a long
> time and getting no where as we considered the changes to severe or out
> of line.

I don't think we have been "banging heads" with you (unless that is your 
feeling?) - how about "working together, but diverting to satisfy different 
needs" :)

I think that we have had more issues in the uClinux-dist (userspace and build 
environment), but for kernel code, we have moved from some non-standard 
(stupid) things we were doing early on to what we have today - which is as 
common/standard with other archs as we can be.

Although this is slightly off topic - on the uClinux distribution side - most 
of our changes are based on requirements/desires from being able to support 
fdpic elf and flat formats, and to attempt to make things easier for end 
users/us to use/maintain. Where we do make changes - we always send the patch 
upstream and have the conversation with you (not everyone else does this), 
and some/most times rework things so they are more acceptable to you. We 
don't always come to an agreement - but we always have the discussion, and 
are willing to move if we can make things better that still meets both our 
needs/desires.

> This particular patch was trivial in comparison to others I've seen,

That is what we thought.

> it fixed all the existing arches (not something that is always done) and
> seemed a reasonable start to finally get the BF guys up and running.
> Still, happy to make it better of course ;-)

As always - we are more than happy to explore/review alternative patches if 
people want to write/sumbit them.

-Robin
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Wed 19 Sep 2007 23:54, Paul Mundt pondered:
> On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote:
> > On 9/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> > > On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
> > > > Jivin Robin Getz lays it down ...
> > > > > On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > > > > > This just adds minimum support for the Blackfin relocations,
> > > > > > since we don't have enough space in each reloc. The idea
> > > > > > is to store a value with one relocation so that subsequent 
> > > > > > ones can  access it.
> > > > >
> > > > > Adding the other appropriate maintainers. for h8, m32r, sh and
> > > > > v850. 
> > > >
> > > > Looks fine to me,  obviously impacts the existing arches very
> > > > little.  Can't see why it shouldn't get included,
> > >
> > > I find it a bit disconcerting that blackfin already depends on this
> > > in-tree without there being any earlier discussion on making these
> > > changes.
> > 
> > not really ... this patch was posted before but was lost in the
> > shuffle ... and i'm not quite sure what you mean by "depends on" ...
> > if you want to use the FLAT file format on a Blackfin processor, then
> > this patch is needed, but that isnt the only file format that works on
> > the Blackfin port as we also have FDPIC ELF
> > 
> What I mean by "depends on" is that for what you are attempting to
> patch, your architecture has an in-tree dependency on something that hasn't
> been discussed.

"not been discussed" because it was sent to lkml -
http://lkml.org/lkml/2006/9/22/60
- and it got missed/left on the floor during the arch/blackfin inclusion 
(which was huge), not because of any deliberate malicious intent on our part 
to mislead or try to get this in now by doing an end around as you are 
implying.

Our mistake for not poking everyone/resending things sooner/before 
arch/blackfin was included. Bryan will try to make sure that doesn't happen 
again (right Bryan?) - like he is now, by poking/resending things, and making 
sure that the appropriate maintainers (like you, if we are changing things 
you maintain) are included. (which is what I think the problem was).

If we can focus on the technical merits of things, rather than how we got 
here - which I agree sucks - was our mistake - we are sorry - we will try to 
make sure that it doesn't happen again - I think it would be time/effort 
better spent.

-Robin

BTW - does anyone know Miles Bader's current email address? There isn't one 
listed in MAINTAINERS - and he is still listed for the NEC V850?
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Wed 19 Sep 2007 23:54, Paul Mundt pondered:
 On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote:
  On 9/19/07, Paul Mundt [EMAIL PROTECTED] wrote:
   On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
Jivin Robin Getz lays it down ...
 On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
  This just adds minimum support for the Blackfin relocations,
  since we don't have enough space in each reloc. The idea
  is to store a value with one relocation so that subsequent 
  ones can  access it.

 Adding the other appropriate maintainers. for h8, m32r, sh and
 v850. 
   
Looks fine to me,  obviously impacts the existing arches very
little.  Can't see why it shouldn't get included,
  
   I find it a bit disconcerting that blackfin already depends on this
   in-tree without there being any earlier discussion on making these
   changes.
  
  not really ... this patch was posted before but was lost in the
  shuffle ... and i'm not quite sure what you mean by depends on ...
  if you want to use the FLAT file format on a Blackfin processor, then
  this patch is needed, but that isnt the only file format that works on
  the Blackfin port as we also have FDPIC ELF
  
 What I mean by depends on is that for what you are attempting to
 patch, your architecture has an in-tree dependency on something that hasn't
 been discussed.

not been discussed because it was sent to lkml -
http://lkml.org/lkml/2006/9/22/60
- and it got missed/left on the floor during the arch/blackfin inclusion 
(which was huge), not because of any deliberate malicious intent on our part 
to mislead or try to get this in now by doing an end around as you are 
implying.

Our mistake for not poking everyone/resending things sooner/before 
arch/blackfin was included. Bryan will try to make sure that doesn't happen 
again (right Bryan?) - like he is now, by poking/resending things, and making 
sure that the appropriate maintainers (like you, if we are changing things 
you maintain) are included. (which is what I think the problem was).

If we can focus on the technical merits of things, rather than how we got 
here - which I agree sucks - was our mistake - we are sorry - we will try to 
make sure that it doesn't happen again - I think it would be time/effort 
better spent.

-Robin

BTW - does anyone know Miles Bader's current email address? There isn't one 
listed in MAINTAINERS - and he is still listed for the NEC V850?
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Thu 20 Sep 2007 11:03, David McCullough pondered:
 I would say that (a) is definately not the case.  I am sure the BF guys
 will say they have been banging us on the head with changes for a long
 time and getting no where as we considered the changes to severe or out
 of line.

I don't think we have been banging heads with you (unless that is your 
feeling?) - how about working together, but diverting to satisfy different 
needs :)

I think that we have had more issues in the uClinux-dist (userspace and build 
environment), but for kernel code, we have moved from some non-standard 
(stupid) things we were doing early on to what we have today - which is as 
common/standard with other archs as we can be.

Although this is slightly off topic - on the uClinux distribution side - most 
of our changes are based on requirements/desires from being able to support 
fdpic elf and flat formats, and to attempt to make things easier for end 
users/us to use/maintain. Where we do make changes - we always send the patch 
upstream and have the conversation with you (not everyone else does this), 
and some/most times rework things so they are more acceptable to you. We 
don't always come to an agreement - but we always have the discussion, and 
are willing to move if we can make things better that still meets both our 
needs/desires.

 This particular patch was trivial in comparison to others I've seen,

That is what we thought.

 it fixed all the existing arches (not something that is always done) and
 seemed a reasonable start to finally get the BF guys up and running.
 Still, happy to make it better of course ;-)

As always - we are more than happy to explore/review alternative patches if 
people want to write/sumbit them.

-Robin
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Wed 19 Sep 2007 21:55, David McCullough pondered:
> Jivin Robin Getz lays it down ...
> > On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > > From: Bernd Schmidt <[EMAIL PROTECTED]>
> > > 
> > > This just adds minimum support for the Blackfin relocations,
> > > since we don't have enough space in each reloc. The idea
> > > is to store a value with one relocation so that subsequent ones can
> > > access it.
> > > 
> > > Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]>
> > > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> > > Cc: David McCullough <[EMAIL PROTECTED]>
> > > Cc: Greg Ungerer <[EMAIL PROTECTED]>
> > 
> > Adding the other appropriate maintainers. for h8, m32r, sh and v850.
> 
> Looks fine to me,  obviously impacts the existing arches very little.
> Can't see why it shouldn't get included,

Is that Australian for Acked-by:? :)

-Robin
-
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] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> From: Bernd Schmidt <[EMAIL PROTECTED]>
> 
> This just adds minimum support for the Blackfin relocations,
> since we don't have enough space in each reloc. The idea
> is to store a value with one relocation so that subsequent ones can
> access it.
> 
> Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]>
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> Cc: David McCullough <[EMAIL PROTECTED]>
> Cc: Greg Ungerer <[EMAIL PROTECTED]>

Adding the other appropriate maintainers. for h8, m32r, sh and v850.

> ---
>  fs/binfmt_flat.c |5 -
>  include/asm-h8300/flat.h |3 ++-
>  include/asm-m32r/flat.h  |3 ++-
>  include/asm-m68knommu/flat.h |3 ++-
>  include/asm-sh/flat.h|3 ++-
>  include/asm-v850/flat.h  |4 +++-
>  6 files changed, 15 insertions(+), 6 deletions(-)
> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> index 7b0265d..13b58f8 100644
> --- a/fs/binfmt_flat.c
> +++ b/fs/binfmt_flat.c
> @@ -742,6 +742,7 @@ static int load_flat_file(struct linux_binprm * bprm,
>* __start to address 4 so that is okay).
>*/
>   if (rev > OLD_FLAT_VERSION) {
> + unsigned long persistent = 0;
>   for (i=0; i < relocs; i++) {
>   unsigned long addr, relval;
>  
> @@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
>  relocated (of course, the address has to be
>  relocated first).  */
>   relval = ntohl(reloc[i]);
> + if (flat_set_persistent (relval, ))
> + continue;
>   addr = flat_get_relocate_addr(relval);
>   rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
>   if (rp == (unsigned long *)RELOC_FAILED) {
> @@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
>   }
>  
>   /* Get the pointer's value.  */
> - addr = flat_get_addr_from_rp(rp, relval, flags);
> + addr = flat_get_addr_from_rp(rp, relval, flags, 
> );
>   if (addr != 0) {
>   /*
>* Do the relocation.  PIC relocs in the data 
> section are
> diff --git a/include/asm-h8300/flat.h b/include/asm-h8300/flat.h
> index c20eee7..2a87350 100644
> --- a/include/asm-h8300/flat.h
> +++ b/include/asm-h8300/flat.h
> @@ -9,6 +9,7 @@
>  #define  flat_argvp_envp_on_stack()  1
>  #define  flat_old_ram_flag(flags)1
>  #define  flat_reloc_valid(reloc, size)   ((reloc) <= (size))
> +#define  flat_set_persistent(relval, p)  0
>  
>  /*
>   * on the H8 a couple of the relocations have an instruction in the
> @@ -18,7 +19,7 @@
>   */
>  
>  #define  flat_get_relocate_addr(rel) (rel)
> -#define flat_get_addr_from_rp(rp, relval, flags) \
> +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
>  (get_unaligned(rp) & ((flags & FLAT_FLAG_GOTPIC) ? 0x: 
> 0x00ff))
>  #define flat_put_addr_at_rp(rp, addr, rel) \
>   put_unaligned (((*(char *)(rp)) << 24) | ((addr) & 0x00ff), rp)
> diff --git a/include/asm-m32r/flat.h b/include/asm-m32r/flat.h
> index 1b285f6..d851cf0 100644
> --- a/include/asm-m32r/flat.h
> +++ b/include/asm-m32r/flat.h
> @@ -15,9 +15,10 @@
>  #define  flat_stack_align(sp)(*sp += (*sp & 3 ? (4 - (*sp & 
> 3)): 0))
>  #define  flat_argvp_envp_on_stack()  0
>  #define  flat_old_ram_flag(flags)(flags)
> +#define  flat_set_persistent(relval, p)  0
>  #define  flat_reloc_valid(reloc, size)   \
>   (((reloc) - textlen_for_m32r_lo16_data) <= (size))
> -#define flat_get_addr_from_rp(rp, relval, flags) \
> +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
>   m32r_flat_get_addr_from_rp(rp, relval, (text_len) )
>  
>  #define flat_put_addr_at_rp(rp, addr, relval) \
> diff --git a/include/asm-m68knommu/flat.h b/include/asm-m68knommu/flat.h
> index 2d836ed..814b517 100644
> --- a/include/asm-m68knommu/flat.h
> +++ b/include/asm-m68knommu/flat.h
> @@ -9,8 +9,9 @@
>  #define  flat_argvp_envp_on_stack()  1
>  #define  flat_old_ram_flag(flags)(flags)
>  #define  flat_reloc_valid(reloc, size)   ((reloc) <= (size))
> -#define  flat_get_addr_from_rp(rp, relval, flags)  get_unaligned(rp)
> +#define  flat_get_addr_from_rp(rp, relval, flags, p) get_unaligned(rp)
>  #define  flat_put_addr_at_rp(rp, val, relval) put_unaligned(val,rp)
>  #define  flat_get_relocate_addr(rel) (rel)
> +#define  flat_set_persistent(relval, p)  0
>  
>  #endif /* __M68KNOMMU_FLAT_H__ */
> diff --git a/include/asm-sh/flat.h b/include/asm-sh/flat.h
> index 0d5cc04..dc4f595 100644
> --- 

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
 From: Bernd Schmidt [EMAIL PROTECTED]
 
 This just adds minimum support for the Blackfin relocations,
 since we don't have enough space in each reloc. The idea
 is to store a value with one relocation so that subsequent ones can
 access it.
 
 Signed-off-by: Bernd Schmidt [EMAIL PROTECTED]
 Signed-off-by: Bryan Wu [EMAIL PROTECTED]
 Cc: David McCullough [EMAIL PROTECTED]
 Cc: Greg Ungerer [EMAIL PROTECTED]

Adding the other appropriate maintainers. for h8, m32r, sh and v850.

 ---
  fs/binfmt_flat.c |5 -
  include/asm-h8300/flat.h |3 ++-
  include/asm-m32r/flat.h  |3 ++-
  include/asm-m68knommu/flat.h |3 ++-
  include/asm-sh/flat.h|3 ++-
  include/asm-v850/flat.h  |4 +++-
  6 files changed, 15 insertions(+), 6 deletions(-)
 diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
 index 7b0265d..13b58f8 100644
 --- a/fs/binfmt_flat.c
 +++ b/fs/binfmt_flat.c
 @@ -742,6 +742,7 @@ static int load_flat_file(struct linux_binprm * bprm,
* __start to address 4 so that is okay).
*/
   if (rev  OLD_FLAT_VERSION) {
 + unsigned long persistent = 0;
   for (i=0; i  relocs; i++) {
   unsigned long addr, relval;
  
 @@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
  relocated (of course, the address has to be
  relocated first).  */
   relval = ntohl(reloc[i]);
 + if (flat_set_persistent (relval, persistent))
 + continue;
   addr = flat_get_relocate_addr(relval);
   rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
   if (rp == (unsigned long *)RELOC_FAILED) {
 @@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
   }
  
   /* Get the pointer's value.  */
 - addr = flat_get_addr_from_rp(rp, relval, flags);
 + addr = flat_get_addr_from_rp(rp, relval, flags, 
 persistent);
   if (addr != 0) {
   /*
* Do the relocation.  PIC relocs in the data 
 section are
 diff --git a/include/asm-h8300/flat.h b/include/asm-h8300/flat.h
 index c20eee7..2a87350 100644
 --- a/include/asm-h8300/flat.h
 +++ b/include/asm-h8300/flat.h
 @@ -9,6 +9,7 @@
  #define  flat_argvp_envp_on_stack()  1
  #define  flat_old_ram_flag(flags)1
  #define  flat_reloc_valid(reloc, size)   ((reloc) = (size))
 +#define  flat_set_persistent(relval, p)  0
  
  /*
   * on the H8 a couple of the relocations have an instruction in the
 @@ -18,7 +19,7 @@
   */
  
  #define  flat_get_relocate_addr(rel) (rel)
 -#define flat_get_addr_from_rp(rp, relval, flags) \
 +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
  (get_unaligned(rp)  ((flags  FLAT_FLAG_GOTPIC) ? 0x: 
 0x00ff))
  #define flat_put_addr_at_rp(rp, addr, rel) \
   put_unaligned (((*(char *)(rp))  24) | ((addr)  0x00ff), rp)
 diff --git a/include/asm-m32r/flat.h b/include/asm-m32r/flat.h
 index 1b285f6..d851cf0 100644
 --- a/include/asm-m32r/flat.h
 +++ b/include/asm-m32r/flat.h
 @@ -15,9 +15,10 @@
  #define  flat_stack_align(sp)(*sp += (*sp  3 ? (4 - (*sp  
 3)): 0))
  #define  flat_argvp_envp_on_stack()  0
  #define  flat_old_ram_flag(flags)(flags)
 +#define  flat_set_persistent(relval, p)  0
  #define  flat_reloc_valid(reloc, size)   \
   (((reloc) - textlen_for_m32r_lo16_data) = (size))
 -#define flat_get_addr_from_rp(rp, relval, flags) \
 +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
   m32r_flat_get_addr_from_rp(rp, relval, (text_len) )
  
  #define flat_put_addr_at_rp(rp, addr, relval) \
 diff --git a/include/asm-m68knommu/flat.h b/include/asm-m68knommu/flat.h
 index 2d836ed..814b517 100644
 --- a/include/asm-m68knommu/flat.h
 +++ b/include/asm-m68knommu/flat.h
 @@ -9,8 +9,9 @@
  #define  flat_argvp_envp_on_stack()  1
  #define  flat_old_ram_flag(flags)(flags)
  #define  flat_reloc_valid(reloc, size)   ((reloc) = (size))
 -#define  flat_get_addr_from_rp(rp, relval, flags)  get_unaligned(rp)
 +#define  flat_get_addr_from_rp(rp, relval, flags, p) get_unaligned(rp)
  #define  flat_put_addr_at_rp(rp, val, relval) put_unaligned(val,rp)
  #define  flat_get_relocate_addr(rel) (rel)
 +#define  flat_set_persistent(relval, p)  0
  
  #endif /* __M68KNOMMU_FLAT_H__ */
 diff --git a/include/asm-sh/flat.h b/include/asm-sh/flat.h
 index 0d5cc04..dc4f595 100644
 --- a/include/asm-sh/flat.h
 +++ b/include/asm-sh/flat.h
 @@ -16,8 +16,9 @@
  #define  

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

[Robin Getz]

On Wed 19 Sep 2007 21:55, David McCullough pondered:
 Jivin Robin Getz lays it down ...
  On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
   From: Bernd Schmidt [EMAIL PROTECTED]
   
   This just adds minimum support for the Blackfin relocations,
   since we don't have enough space in each reloc. The idea
   is to store a value with one relocation so that subsequent ones can
   access it.
   
   Signed-off-by: Bernd Schmidt [EMAIL PROTECTED]
   Signed-off-by: Bryan Wu [EMAIL PROTECTED]
   Cc: David McCullough [EMAIL PROTECTED]
   Cc: Greg Ungerer [EMAIL PROTECTED]
  
  Adding the other appropriate maintainers. for h8, m32r, sh and v850.
 
 Looks fine to me,  obviously impacts the existing arches very little.
 Can't see why it shouldn't get included,

Is that Australian for Acked-by:? :)

-Robin
-
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 3/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver

[Robin Getz]

On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
> 
>  - add MDIO functions and register mdio bus
>  - add phy abstraction layer (PAL) functions and use PAL API
>  - test on STAMP537 board

Today, the Kconfig for the Blackfin just includes:

> config BFIN_MAC
> tristate "Blackfin 536/537 on-chip mac support"
> depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H)
> select CRC32
> select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
> help
>   This is the driver for blackfin on-chip mac device. Say Y if you
> want it compiled into the kernel. This driver is also available as a module
> ( = code which can be inserted in and removed from the running kernel
> whenever you want). The module will be called bfin_mac.

Since you are adding requirement for the PHYLIB with this patch, should there
be a select for that?

-Robin
-
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 3/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver

[Robin Getz]

On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
 
  - add MDIO functions and register mdio bus
  - add phy abstraction layer (PAL) functions and use PAL API
  - test on STAMP537 board

Today, the Kconfig for the Blackfin just includes:

 config BFIN_MAC
 tristate Blackfin 536/537 on-chip mac support
 depends on NET_ETHERNET  (BF537 || BF536)  (!BF537_PORT_H)
 select CRC32
 select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
 help
   This is the driver for blackfin on-chip mac device. Say Y if you
 want it compiled into the kernel. This driver is also available as a module
 ( = code which can be inserted in and removed from the running kernel
 whenever you want). The module will be called bfin_mac.

Since you are adding requirement for the PHYLIB with this patch, should there
be a select for that?

-Robin
-
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] update CFI URI n mtd kconfig

[Robin Getz]

On Thu 13 Sep 2007 14:28, Josh Boyer pondered:
> On 9/12/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > Since AMD shunted its flash memory division, the URI in the mtd Kconfig is 
> > now
> > broken, so the attached patch points people to Wikipedia.
> >
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > ---
> > diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
> > index 479d32b..980117a 100644
> > --- a/drivers/mtd/chips/Kconfig
> > +++ b/drivers/mtd/chips/Kconfig
> > @@ -11,8 +11,8 @@ config MTD_CFI
> >   AMD and other flash manufactures that provides a universal method

Even on the Intel page, it gives "Intel, AMD, Sharp, and Fujitsu" credit - why
limit Sharp, and Fujitsu to "others"? (I would just take out everyone's name).

> >   for probing the capabilities of flash devices. If you wish to
> >   support any device that is CFI-compliant, you need to enable this
> > - option. Visit 
> > - for more information on CFI.
> > + option. For more information on CFI, visit:
> > + 
> 
> Erm, I'd rather not point to wikipedia.  Can you change it to point to:
> 
> http://www.intel.com/design/flash/swb/cfi.htm

Why not from the place that you can get the standard? http://jedec.org/

or http://www.jedec.org/download/search/jesd68-01.pdf 

There isn't any point to pick one vendor - unless you work there, own
stock, or one provides outstanding support (free hardware) for driver 
development. :)

-Robin
-
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] update CFI URI n mtd kconfig

[Robin Getz]

On Thu 13 Sep 2007 14:28, Josh Boyer pondered:
 On 9/12/07, Mike Frysinger [EMAIL PROTECTED] wrote:
  Since AMD shunted its flash memory division, the URI in the mtd Kconfig is 
  now
  broken, so the attached patch points people to Wikipedia.
 
  Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
  ---
  diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
  index 479d32b..980117a 100644
  --- a/drivers/mtd/chips/Kconfig
  +++ b/drivers/mtd/chips/Kconfig
  @@ -11,8 +11,8 @@ config MTD_CFI
AMD and other flash manufactures that provides a universal method

Even on the Intel page, it gives Intel, AMD, Sharp, and Fujitsu credit - why
limit Sharp, and Fujitsu to others? (I would just take out everyone's name).

for probing the capabilities of flash devices. If you wish to
support any device that is CFI-compliant, you need to enable this
  - option. Visit http://www.amd.com/products/nvd/overview/cfi.html
  - for more information on CFI.
  + option. For more information on CFI, visit:
  + http://wikipedia.org/wiki/Common_Flash_Memory_Interface
 
 Erm, I'd rather not point to wikipedia.  Can you change it to point to:
 
 http://www.intel.com/design/flash/swb/cfi.htm

Why not from the place that you can get the standard? http://jedec.org/

or http://www.jedec.org/download/search/jesd68-01.pdf 

There isn't any point to pick one vendor - unless you work there, own
stock, or one provides outstanding support (free hardware) for driver 
development. :)

-Robin
-
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: the Linux kernel, testsuites, and maybe *you*

[Robin Getz]

On Sat 1 Sep 2007 18:08, Andi Kleen pondered:
> "Mike Frysinger" <[EMAIL PROTECTED]> writes:
> 
> > is there any sort of standard for testing and integration into
> > mainline ?  
> 
> Everybody does their own.

That kind of stinks - and seems to be a potential duplication of effort all 
over the place.

> > in the Blackfin world, we've been developing little
> > external kernel modules and adding them to our own testsuite, but
> > often times these things are not Blackfin specific.  case in point,
> > we're integrating a string testsuite to make sure all of the fun str*
> > and mem* functions are sane and operate as they expected, but rather
> > than having just Blackfin benefit here, i'd like to see this pushed
> > upstream ...
> 
> I would like to see this too. I wrote a couple of unit tests
> during x86-64 development too and they would be handy
> to have in a central place.
> 
> The SUSE kernel also has a crasher module that exercises the
> allocators and is pretty useful to stress code in general.
> 
> Disadvantage is that test code tends to be hackish and ugly
> and very specialized and will probably not pass standard review
> procedures.

Then this makes perfect sense to actually have it in the proper places, and 
have it go through the standard review process. I have run into problems 
recently, where ugly hackish tests seem never really catch actual faults. 
(Since they were written by the same person who wrote the driver - Design a 
fault in, code the fault, test the fault is there).

With many eyes - and all that stuff - hopefully we would catch things.

> Also the rt people seem to have pushed a couple of tests in already, 
> but I always hated it that they're in the standard directories.
> RCU also has, in fact they added a "eat all my CPU in tests"
> CONFIG option. Just making that dependent on a CONFIG_UNIT_TESTS
> would be a good change in itself. And then there are the slab
> failure inducers of course.

Putting them close to the standard directories might be OK - keeping the tests 
close to the thing that is being tested may help with maintainers keeping an 
eye on things that might be missed otherwise.

Maybe these types of tests should go into a separate directory - power on self 
tests (post) directories in the respective places? ./kernel/post 
and ./drivers//post?

So Mike's proposed string tests would go into ./lib/post/strings.c

When things pass - you get a single indication (all tests for unit X passed) 
or a pass for each test?

-Robin
-
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: the Linux kernel, testsuites, and maybe *you*

[Robin Getz]

On Sat 1 Sep 2007 18:08, Andi Kleen pondered:
 Mike Frysinger [EMAIL PROTECTED] writes:
 
  is there any sort of standard for testing and integration into
  mainline ?  
 
 Everybody does their own.

That kind of stinks - and seems to be a potential duplication of effort all 
over the place.

  in the Blackfin world, we've been developing little
  external kernel modules and adding them to our own testsuite, but
  often times these things are not Blackfin specific.  case in point,
  we're integrating a string testsuite to make sure all of the fun str*
  and mem* functions are sane and operate as they expected, but rather
  than having just Blackfin benefit here, i'd like to see this pushed
  upstream ...
 
 I would like to see this too. I wrote a couple of unit tests
 during x86-64 development too and they would be handy
 to have in a central place.
 
 The SUSE kernel also has a crasher module that exercises the
 allocators and is pretty useful to stress code in general.
 
 Disadvantage is that test code tends to be hackish and ugly
 and very specialized and will probably not pass standard review
 procedures.

Then this makes perfect sense to actually have it in the proper places, and 
have it go through the standard review process. I have run into problems 
recently, where ugly hackish tests seem never really catch actual faults. 
(Since they were written by the same person who wrote the driver - Design a 
fault in, code the fault, test the fault is there).

With many eyes - and all that stuff - hopefully we would catch things.

 Also the rt people seem to have pushed a couple of tests in already, 
 but I always hated it that they're in the standard directories.
 RCU also has, in fact they added a eat all my CPU in tests
 CONFIG option. Just making that dependent on a CONFIG_UNIT_TESTS
 would be a good change in itself. And then there are the slab
 failure inducers of course.

Putting them close to the standard directories might be OK - keeping the tests 
close to the thing that is being tested may help with maintainers keeping an 
eye on things that might be missed otherwise.

Maybe these types of tests should go into a separate directory - power on self 
tests (post) directories in the respective places? ./kernel/post 
and ./drivers//post?

So Mike's proposed string tests would go into ./lib/post/strings.c

When things pass - you get a single indication (all tests for unit X passed) 
or a pass for each test?

-Robin
-
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: the Linux kernel, testsuites, and maybe *you*

[Robin Getz]

On Fri 31 Aug 2007 17:22, Mike Frysinger pondered:
> is there any sort of standard for testing and integration into
> mainline ?  in the Blackfin world, we've been developing little
> external kernel modules and adding them to our own testsuite, but
> often times these things are not Blackfin specific.  case in point,
> we're integrating a string testsuite to make sure all of the fun str*
> and mem* functions are sane and operate as they expected, but rather
> than having just Blackfin benefit here, i'd like to see this pushed
> upstream ...

I know there have been some discussions at past OLS about some testing that 
Martin was working on.

http://www.linuxsymposium.org/2006/view_abstract.php?content_key=13

But I think this was more functional tests, less unit tests that what you are 
talking/asking about.

http://test.kernel.org/functional/index.html

Also - If I remember - most of the existing tests were for a self hosted 
environment - and might not be well suited to embedded (like Blackfin) which 
requires cross compile, and pretty thin runtime environment (uClibc + 
busybox's msh as shell).

Martin?

-Robin
-
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: the Linux kernel, testsuites, and maybe *you*

[Robin Getz]

On Fri 31 Aug 2007 17:22, Mike Frysinger pondered:
 is there any sort of standard for testing and integration into
 mainline ?  in the Blackfin world, we've been developing little
 external kernel modules and adding them to our own testsuite, but
 often times these things are not Blackfin specific.  case in point,
 we're integrating a string testsuite to make sure all of the fun str*
 and mem* functions are sane and operate as they expected, but rather
 than having just Blackfin benefit here, i'd like to see this pushed
 upstream ...

I know there have been some discussions at past OLS about some testing that 
Martin was working on.

http://www.linuxsymposium.org/2006/view_abstract.php?content_key=13

But I think this was more functional tests, less unit tests that what you are 
talking/asking about.

http://test.kernel.org/functional/index.html

Also - If I remember - most of the existing tests were for a self hosted 
environment - and might not be well suited to embedded (like Blackfin) which 
requires cross compile, and pretty thin runtime environment (uClibc + 
busybox's msh as shell).

Martin?

-Robin
-
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 1/1] fix - ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz <[EMAIL PROTECTED]>

Gerd Hoffmann pointed out that my patch from yesterday can lead 
to a null pointer dereference if the kernel is booted with no
console, and no earlyprintk defined. This fixes that issue.

 printk.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Signed-off-by: Robin Getz <[EMAIL PROTECTED]>

---

Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c 
+++ linux-2.6.x/kernel/printk.c
@@ -1106,10 +1106,12 @@
 
 static int __init disable_boot_consoles(void)
 {
-   if (console_drivers->flags & CON_BOOT) {
-   printk(KERN_INFO "turn off boot console %s%d\n",
-   console_drivers->name, console_drivers->index);
-   return unregister_console(console_drivers);
+   if (console_drivers != NULL) {
+   if (console_drivers->flags & CON_BOOT) {
+   printk(KERN_INFO "turn off boot console %s%d\n",
+   console_drivers->name, console_drivers->index);
+   return unregister_console(console_drivers);
+   }
}
return 0;
 }
-
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 1/1] fix - ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz [EMAIL PROTECTED]

Gerd Hoffmann pointed out that my patch from yesterday can lead 
to a null pointer dereference if the kernel is booted with no
console, and no earlyprintk defined. This fixes that issue.

 printk.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Signed-off-by: Robin Getz [EMAIL PROTECTED]

---

Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c 
+++ linux-2.6.x/kernel/printk.c
@@ -1106,10 +1106,12 @@
 
 static int __init disable_boot_consoles(void)
 {
-   if (console_drivers-flags  CON_BOOT) {
-   printk(KERN_INFO turn off boot console %s%d\n,
-   console_drivers-name, console_drivers-index);
-   return unregister_console(console_drivers);
+   if (console_drivers != NULL) {
+   if (console_drivers-flags  CON_BOOT) {
+   printk(KERN_INFO turn off boot console %s%d\n,
+   console_drivers-name, console_drivers-index);
+   return unregister_console(console_drivers);
+   }
}
return 0;
 }
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

Try #4... (sorry)
 
From: Robin Getz <[EMAIL PROTECTED]>
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
CC: Gerd Hoffmann <[EMAIL PROTECTED]>
CC: Paul Mundt <[EMAIL PROTECTED]>
CC: Mike Frysinger <[EMAIL PROTECTED]>
---

 kernel/printk.c |   11 +++
 1 file changed, 11 insertions(+)

Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c (revision 3583)
+++ linux-2.6.x/kernel/printk.c (working copy)
@@ -1104,6 +1104,17 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   if (console_drivers->flags & CON_BOOT) {
+   printk(KERN_INFO "turn off boot console %s%d\n",
+   console_drivers->name, console_drivers->index);
+   return unregister_console(console_drivers);
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

Try #3...

From: Robin Getz <[EMAIL PROTECTED]>
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
CC: Gerd Hoffmann <[EMAIL PROTECTED]>
CC: Paul Mundt <[EMAIL PROTECTED]>
CC: Mike Frysinger <[EMAIL PROTECTED]>
---
 printk.c |   13 +
 1 file changed, 13 insertions(+)


Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c
+++ linux-2.6.x/kernel/printk.c
@@ -1104,6 +1104,19 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   printk(KERN_INFO "here\n");
+
+   if (console_drivers->flags & CON_BOOT) {
+   printk(KERN_INFO "turn off boot console %s%d\n",
+   console_drivers->name, console_drivers->index);
+   return unregister_console(console_drivers);
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

Try #3...

From: Robin Getz [EMAIL PROTECTED]
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz [EMAIL PROTECTED]
CC: Gerd Hoffmann [EMAIL PROTECTED]
CC: Paul Mundt [EMAIL PROTECTED]
CC: Mike Frysinger [EMAIL PROTECTED]
---
 printk.c |   13 +
 1 file changed, 13 insertions(+)


Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c
+++ linux-2.6.x/kernel/printk.c
@@ -1104,6 +1104,19 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   printk(KERN_INFO here\n);
+
+   if (console_drivers-flags  CON_BOOT) {
+   printk(KERN_INFO turn off boot console %s%d\n,
+   console_drivers-name, console_drivers-index);
+   return unregister_console(console_drivers);
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

Try #4... (sorry)
 
From: Robin Getz [EMAIL PROTECTED]
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz [EMAIL PROTECTED]
CC: Gerd Hoffmann [EMAIL PROTECTED]
CC: Paul Mundt [EMAIL PROTECTED]
CC: Mike Frysinger [EMAIL PROTECTED]
---

 kernel/printk.c |   11 +++
 1 file changed, 11 insertions(+)

Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c (revision 3583)
+++ linux-2.6.x/kernel/printk.c (working copy)
@@ -1104,6 +1104,17 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   if (console_drivers-flags  CON_BOOT) {
+   printk(KERN_INFO turn off boot console %s%d\n,
+   console_drivers-name, console_drivers-index);
+   return unregister_console(console_drivers);
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz <[EMAIL PROTECTED]>
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
 
---

linux-2.6.x-old/kernel/printk.c |   15 +++
1 file changed, 15 insertions(+)

Index: linux-2.6.x-old/kernel/printk.c
===
--- linux-2.6.x-old/kernel/printk.c (revision 3583)
+++ linux-2.6.x-old/kernel/printk.c (working copy)
@@ -1104,6 +1104,21 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con->next) {
+   if (con->flags & CON_BOOT) {
+   printk(KERN_INFO "Turn off boot console %s%d\n",
+   con->name, con->index);
+   unregister_console(con);
+   }
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz <[EMAIL PROTECTED]>

This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511

This ensures that a bootconsole is unregistered if it is not replaced. 
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.

Signed-off-by: Robin Getz <[EMAIL PROTECTED]>

---
 linux-2.6.x/kernel/printk.c |   14 ++
 1 file changed, 14 insertions(+)


Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c
+++ linux-2.6.x/kernel/printk.c
@@ -1104,6 +1104,20 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con->next) {
+   if (con->flags & CON_BOOT) {
+   printk(KERN_INFO "Turn off boot console %s%d\n",
+   con->name, con->index);
+   unregister_console(con);
+   }
+   }
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 02/12] Blackfin arch: Add label to call new GPIO API

[Robin Getz]

On Sun 19 Aug 2007 17:54, David Brownell pondered:
> On Saturday 18 August 2007, Robin Getz wrote:
> 
> > I don't see how early/late makes the problem easier/worse to debug. No
> > matter when you do it - the driver refuses to install (or at least
> > should). 
> 
> If you arrange to *reliably* detect the pinmux/setup problems by
> the time the system starts ""init" (early), that means one large
> class of hard-to-sort problems never needs runtime troubleshooting.

Sure it does - it just needs to do it in the bootloader, not the kernel. You 
haven't eliminated the problem - or made it any easier to debug - it is just 
moved somewhere else. Again - this is not bad. We decided/are attempting to 
do it in the kernel. Normally what we find is there are more kernel people on 
a project than bootloader (whether this makes this easier - or not - is still 
TDB :)

> Think of it this way:  folk have observed that pin setup issues can
> be painful to sort out. 

Absolutely - the problem that everyone is trying to solve - is how to do plug 
and play, with no enumeration?

Doing it early in the bootloader is akin to historical PC solution where early 
ISA PNP (shudder) filled out a table in memory, and passed it to the OS.

> So they adopt a strategy ("failfast"/"early") 
> which helps surface them early and basically removes them as issues
> in later debugging.

When the kernel engineer runs into a problem because a driver won't load, is 
it better that he can fix it himself (hopefully), or that they have to call 
the person maintaining the bootloader? There are pro/cons of either. I can 
see the value in both. 

We choose to do it in the driver, not the bootloader.

> > Right - for us - the code handing the hardware differences is easier
> > in the drivers, rather than the bootloaders.
> 
> Remember that I didn't argue in favor of putting that code into
> boot loaders ... I just pointed out that some product lines work
> that way, so Linux needs to cope with that strategy.  (One of the
> many examples involves OpenFirmware device tables.)
> 
> But regardless:  I can't buy any argument that it's better to put
> lots of board-specific code into drivers. 

I don't think we are putting board specific code in drivers (or if there is - 
it should get removed).

I did a quick look, and the only place this has happened is in some of our 
drivers that have not made it to main line yet - where we accidently put some 
mtd_partitions in the drivers, rather than the boards file. I know we are 
working on fixing this.

> That adds up quickly, 
> making maintaining the drivers painful.  "Real" updates (bugfixes,
> new features, API updates, cleanup, and so on) regularly end up
> in conflict with patches to support a few more boards, and board
> support patches must then always involve those driver maintainers.
> So merging new boards involves many more people than necessary...

I agree - which is why don't do this either. Board specific info does not go 
into drivers. I think this is something that Michael, Bryan and others 
working on the Blackfin arch & drivers will agree to 100%.

What we do is try to make the driver agnostic to the hardware as much as 
possible, where hardware specifics (chip selects, IRQ, GPIO, etc) are managed 
in Kconfig.

I can see the value of doing the initialisation in the bootloader - since this 
would allow you have a common driver - and hardware customisation is done in 
the bootloader.

>
> > 
> > linux-2.6.x/drivers/serial/Kconfig:
> 
> That can work, at least for *single-board* kernel builds.  Of course,
> that gets into territory some people will say is Kconfig abuse ...
> and the need for many ugly #ifdefs is very obvious.  :)

We have been trying to minimise that - and I think we have been doing a pretty 
good job. There doesn't seem to be any platform specific ifdefs in our 
drivers that are not abstracted out.

> Doing that in Kconfig is atypical ... it may well be a bit easier to
> pick up at the beginning of a developer's learning curve, but I think
> it doesn't scale very well as multi-board product lines evolve.

We have lots of end users (obviously not as many as ARM or PPC yet), and they 
have not been complaining, in fact some say that this is easier to deploy.

But - I think we both agree - that what we are doing is just an alternative 
implemention of hardware abstraction - that is different than the way that 
some others are doing it. Not better/worse (from what I can tell) - it just 
has different tradeoffs.

-Robin
-
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 02/12] Blackfin arch: Add label to call new GPIO API

[Robin Getz]

On Sun 19 Aug 2007 17:54, David Brownell pondered:
 On Saturday 18 August 2007, Robin Getz wrote:
 
  I don't see how early/late makes the problem easier/worse to debug. No
  matter when you do it - the driver refuses to install (or at least
  should). 
 
 If you arrange to *reliably* detect the pinmux/setup problems by
 the time the system starts init (early), that means one large
 class of hard-to-sort problems never needs runtime troubleshooting.

Sure it does - it just needs to do it in the bootloader, not the kernel. You 
haven't eliminated the problem - or made it any easier to debug - it is just 
moved somewhere else. Again - this is not bad. We decided/are attempting to 
do it in the kernel. Normally what we find is there are more kernel people on 
a project than bootloader (whether this makes this easier - or not - is still 
TDB :)

 Think of it this way:  folk have observed that pin setup issues can
 be painful to sort out. 

Absolutely - the problem that everyone is trying to solve - is how to do plug 
and play, with no enumeration?

Doing it early in the bootloader is akin to historical PC solution where early 
ISA PNP (shudder) filled out a table in memory, and passed it to the OS.

 So they adopt a strategy (failfast/early) 
 which helps surface them early and basically removes them as issues
 in later debugging.

When the kernel engineer runs into a problem because a driver won't load, is 
it better that he can fix it himself (hopefully), or that they have to call 
the person maintaining the bootloader? There are pro/cons of either. I can 
see the value in both. 

We choose to do it in the driver, not the bootloader.

  Right - for us - the code handing the hardware differences is easier
  in the drivers, rather than the bootloaders.
 
 Remember that I didn't argue in favor of putting that code into
 boot loaders ... I just pointed out that some product lines work
 that way, so Linux needs to cope with that strategy.  (One of the
 many examples involves OpenFirmware device tables.)
 
 But regardless:  I can't buy any argument that it's better to put
 lots of board-specific code into drivers. 

I don't think we are putting board specific code in drivers (or if there is - 
it should get removed).

I did a quick look, and the only place this has happened is in some of our 
drivers that have not made it to main line yet - where we accidently put some 
mtd_partitions in the drivers, rather than the boards file. I know we are 
working on fixing this.

 That adds up quickly, 
 making maintaining the drivers painful.  Real updates (bugfixes,
 new features, API updates, cleanup, and so on) regularly end up
 in conflict with patches to support a few more boards, and board
 support patches must then always involve those driver maintainers.
 So merging new boards involves many more people than necessary...

I agree - which is why don't do this either. Board specific info does not go 
into drivers. I think this is something that Michael, Bryan and others 
working on the Blackfin arch  drivers will agree to 100%.

What we do is try to make the driver agnostic to the hardware as much as 
possible, where hardware specifics (chip selects, IRQ, GPIO, etc) are managed 
in Kconfig.

I can see the value of doing the initialisation in the bootloader - since this 
would allow you have a common driver - and hardware customisation is done in 
the bootloader.


  
  linux-2.6.x/drivers/serial/Kconfig:
 
 That can work, at least for *single-board* kernel builds.  Of course,
 that gets into territory some people will say is Kconfig abuse ...
 and the need for many ugly #ifdefs is very obvious.  :)

We have been trying to minimise that - and I think we have been doing a pretty 
good job. There doesn't seem to be any platform specific ifdefs in our 
drivers that are not abstracted out.

 Doing that in Kconfig is atypical ... it may well be a bit easier to
 pick up at the beginning of a developer's learning curve, but I think
 it doesn't scale very well as multi-board product lines evolve.

We have lots of end users (obviously not as many as ARM or PPC yet), and they 
have not been complaining, in fact some say that this is easier to deploy.

But - I think we both agree - that what we are doing is just an alternative 
implemention of hardware abstraction - that is different than the way that 
some others are doing it. Not better/worse (from what I can tell) - it just 
has different tradeoffs.

-Robin
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz [EMAIL PROTECTED]

This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511

This ensures that a bootconsole is unregistered if it is not replaced. 
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.

Signed-off-by: Robin Getz [EMAIL PROTECTED]

---
 linux-2.6.x/kernel/printk.c |   14 ++
 1 file changed, 14 insertions(+)


Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c
+++ linux-2.6.x/kernel/printk.c
@@ -1104,6 +1104,20 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con-next) {
+   if (con-flags  CON_BOOT) {
+   printk(KERN_INFO Turn off boot console %s%d\n,
+   con-name, con-index);
+   unregister_console(con);
+   }
+   }
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 1/1] ensure we don't use bootconsoles after init has been released

[Robin Getz]

From: Robin Getz [EMAIL PROTECTED]
 
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
 
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
 
Signed-off-by: Robin Getz [EMAIL PROTECTED]
 
---

linux-2.6.x-old/kernel/printk.c |   15 +++
1 file changed, 15 insertions(+)

Index: linux-2.6.x-old/kernel/printk.c
===
--- linux-2.6.x-old/kernel/printk.c (revision 3583)
+++ linux-2.6.x-old/kernel/printk.c (working copy)
@@ -1104,6 +1104,21 @@
 }
 EXPORT_SYMBOL(unregister_console);
 
+static int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con-next) {
+   if (con-flags  CON_BOOT) {
+   printk(KERN_INFO Turn off boot console %s%d\n,
+   con-name, con-index);
+   unregister_console(con);
+   }
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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 02/12] Blackfin arch: Add label to call new GPIO API

[Robin Getz]

On Fri 17 Aug 2007 18:34, David Brownell pondered:
> On Friday 17 August 2007, Robin Getz wrote:
> > On Fri 17 Aug 2007 14:24, David Brownell pondered:
> > > Just for the record, this is an unusual way to use these calls.
> > 
> > That is part of the natural evolution of the kernel isn't it - per
> > James's keynote at OLS - you release something, and see how people 
> > [ab]use it until it either grows, evolves, or it dies.
> 
> Yep ... and it's worth knowing when you're doing
> something different.  Different isn't always worse,
> isn't always better.

No disagreements here.

> > > Other platforms completely decouple these issues from the
> > > IRQ infrastructure ... doing the pinmux and gpio claiming
> > > separately from the request_irq()/free_irq() paths, mostly
> > > as part of board setup.  Doing all of that "early":
> > 
> > is early:
> >  - early in the kernel?
> >  - early before the kernel? (in the bootloader).
> 
> Both of those are "earlier", yes.  Different product developers
> may argue for either placement.

Just like we say things are better/easier for us later.

> > >  - keeps those error returns from causing hard-to-track-down
> > >runtime bugs;
> > 
> > The current Blackfin implementation causes a run time message:
> > "the pin  driver requested, was already claimed by yyy driver".
> > 
> > I don't think that is too bad?
> 
> Given some product with a Blackfin chip, would you expect a
> customer -- who may not even see the Linux bits!! -- to be
> able to solve such problems?  If it's not possible for such
> problems to crop up in the field, product support (and field
> troubleshooting) gets easier...

Typically customers who are not familiar with the linux bits are not doing 
modprobe either...

I don't see how early/late makes the problem easier/worse to debug. No matter 
when you do it - the driver refuses to install (or at least should).

> > >  - works always, even on platforms where a given IRQ may
> > >appear on any of several pins/balls;
> > 
> > But requires custom bootloaders or board setup for every hardware
> > platform?
> 
> One or both, yes.  That's typical in embedded setups.
> They're not necessarily all that different, but that
> code does need to handle the hardware differences.

Right - for us - the code handing the hardware differences is easier in the 
drivers, rather than the bootloaders.

For other systems - where you can have a UART on any pin - I completely 
understand your point.

> > Most of our users would not like that, since they do as you say - use
> > the same kernel - with different drivers on multiple platforms.
> 
> I thought I referred to different revisions of one platform... :)

You did - I was just saying that some of our customers don't do it the way you 
were thinking.

> > >  - makes it easier to cross-check against board schematics,
> > >by keeping most board-specific setup in one source file;
> > 
> > Yes - but we are not talking about muxing a common peripheral (like a
> > single UART) out many different pins (A or B or C). The UART pins are
> > fixed. If you want the UART, you need to use pin A. If you want to use
> > the I2C that also sits on pin A, you will get the message:
> > "pin A, requested by I2C, was already claimed by UART driver".
> 
> Not all platforms work that way though.  There can often be several
> options for where a given signal gets routed.

But this is how it _always_ works on Blackfin. For other systems - like ARM, 
where n+1 silicon manufactures are all implementing things differently - I 
can understand your comments.


> > >  - allows the label to be more descriptive ... describeing
> > >exactly *which* IRQ, so that using the labels for better
> > >diagnostics actually gives better diagnostics.
> > 
> > I'm not sure what you mean?
> 
> The $SUBJECT patch uses the string "IRQ" in all cases.
> But "smc_irq" and "codec_irq" would be more informative
> as entries in a list of even just a handful of GPIOs.
> And with a few dozen, I'd find "IRQ" not at all helpful.

I agree - things can always be more descriptive.

> > > Again, not "wrong"; but probably sub-optimal.  You might
> > > want to move towards earlier binding now, while Linux is
> > > still young on Blackfin and you don't have legacy code to
> > > worry about.
> > 
> > Our overall goal is to keep as much code - including bootloader -
> > platform  agnostic, and not require people to write any of
> > code/configuration data to

Re: [draft] Blackfin Early Printk implmentation

[Robin Getz]

On Sat 18 Aug 2007 02:23, Sam Ravnborg pondered:
> > > What was preventing you from just using the x86_64 code here?
> > 
> > Some was borrowed - but not much. since we don't support vga, or 
> > 16550 UARTs (Blackfin has it's own on-chip UART), I don't think 
> > this would work.  Everyone implements implements direct IO to 
> > the hardware (except me, since I  put it into the driver file,
> > and force Sonic - the serial driver developer - to maintain it
> > forever). 
> > 
> > Most of the other early printks talks directly to the hardware.
> I only looked at your version and it looked general thats why I brought
> up the code sharing idea - which I agree is not possible.

Believe me - I would actually like this more - put the I/O parts into the 
serial driver or vga driver or xxx driver - and early printk becomes a 
generic function that is supported on every platform, with a CON_BOOT 
defined.

But, I didn't want (or have the time) to go mucking in everyone else's 
arch/drivers to move things around - but the more I think about it - the 
better it would be. Maybe on my next long plane trip I will look at it.

> > > Thinking that all should do the same so maybe alpha ought to
> > > change...
> > 
> > When I looked at all the printk implementations, I thought they were
> > all kind of hokey, and not very common - but what do you want for a
> > debug interface that lasts less than 5 seconds?
> > 
> > ./arch/x86_64/kernel/early_printk.c
> > ./arch/blackfin/kernel/early_printk.c
> > ./arch/sh64/kernel/early_printk.c
> > ./arch/sh/kernel/early_printk.c
> > ./arch/i386/kernel/early_printk.c
> > ./arch/mips/kernel/early_printk.c
> > 
> > I didn't see an alpha implementation - where is it done?
> Alpha uses the imlementation in lib/*print.c somehow.
> And I think the right choice would be to implement
> a private version of early_printk for alpha like the
> other architectures do.

When looked for EARLY_PRINTK in ./arch/alpha - and include/asm-alpha, it only 
shows up in the Kconfig files - nothing seems to use it...

> Thanks for the split-up. I could follow the changes now.

Any issues/comments? Or do things look OK?

-Robin
-
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: [draft] Blackfin Early Printk implmentation

[Robin Getz]

On Sat 18 Aug 2007 02:23, Sam Ravnborg pondered:
   What was preventing you from just using the x86_64 code here?
  
  Some was borrowed - but not much. since we don't support vga, or 
  16550 UARTs (Blackfin has it's own on-chip UART), I don't think 
  this would work.  Everyone implements implements direct IO to 
  the hardware (except me, since I  put it into the driver file,
  and force Sonic - the serial driver developer - to maintain it
  forever). 
  
  Most of the other early printks talks directly to the hardware.
 I only looked at your version and it looked general thats why I brought
 up the code sharing idea - which I agree is not possible.

Believe me - I would actually like this more - put the I/O parts into the 
serial driver or vga driver or xxx driver - and early printk becomes a 
generic function that is supported on every platform, with a CON_BOOT 
defined.

But, I didn't want (or have the time) to go mucking in everyone else's 
arch/drivers to move things around - but the more I think about it - the 
better it would be. Maybe on my next long plane trip I will look at it.

   Thinking that all should do the same so maybe alpha ought to
   change...
  
  When I looked at all the printk implementations, I thought they were
  all kind of hokey, and not very common - but what do you want for a
  debug interface that lasts less than 5 seconds?
  
  ./arch/x86_64/kernel/early_printk.c
  ./arch/blackfin/kernel/early_printk.c
  ./arch/sh64/kernel/early_printk.c
  ./arch/sh/kernel/early_printk.c
  ./arch/i386/kernel/early_printk.c
  ./arch/mips/kernel/early_printk.c
  
  I didn't see an alpha implementation - where is it done?
 Alpha uses the imlementation in lib/*print.c somehow.
 And I think the right choice would be to implement
 a private version of early_printk for alpha like the
 other architectures do.

When looked for EARLY_PRINTK in ./arch/alpha - and include/asm-alpha, it only 
shows up in the Kconfig files - nothing seems to use it...

 Thanks for the split-up. I could follow the changes now.

Any issues/comments? Or do things look OK?

-Robin
-
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 02/12] Blackfin arch: Add label to call new GPIO API

[Robin Getz]

On Fri 17 Aug 2007 18:34, David Brownell pondered:
 On Friday 17 August 2007, Robin Getz wrote:
  On Fri 17 Aug 2007 14:24, David Brownell pondered:
   Just for the record, this is an unusual way to use these calls.
  
  That is part of the natural evolution of the kernel isn't it - per
  James's keynote at OLS - you release something, and see how people 
  [ab]use it until it either grows, evolves, or it dies.
 
 Yep ... and it's worth knowing when you're doing
 something different.  Different isn't always worse,
 isn't always better.

No disagreements here.

   Other platforms completely decouple these issues from the
   IRQ infrastructure ... doing the pinmux and gpio claiming
   separately from the request_irq()/free_irq() paths, mostly
   as part of board setup.  Doing all of that early:
  
  is early:
   - early in the kernel?
   - early before the kernel? (in the bootloader).
 
 Both of those are earlier, yes.  Different product developers
 may argue for either placement.

Just like we say things are better/easier for us later.

- keeps those error returns from causing hard-to-track-down
  runtime bugs;
  
  The current Blackfin implementation causes a run time message:
  the pin  driver requested, was already claimed by yyy driver.
  
  I don't think that is too bad?
 
 Given some product with a Blackfin chip, would you expect a
 customer -- who may not even see the Linux bits!! -- to be
 able to solve such problems?  If it's not possible for such
 problems to crop up in the field, product support (and field
 troubleshooting) gets easier...

Typically customers who are not familiar with the linux bits are not doing 
modprobe either...

I don't see how early/late makes the problem easier/worse to debug. No matter 
when you do it - the driver refuses to install (or at least should).

- works always, even on platforms where a given IRQ may
  appear on any of several pins/balls;
  
  But requires custom bootloaders or board setup for every hardware
  platform?
 
 One or both, yes.  That's typical in embedded setups.
 They're not necessarily all that different, but that
 code does need to handle the hardware differences.

Right - for us - the code handing the hardware differences is easier in the 
drivers, rather than the bootloaders.

For other systems - where you can have a UART on any pin - I completely 
understand your point.

  Most of our users would not like that, since they do as you say - use
  the same kernel - with different drivers on multiple platforms.
 
 I thought I referred to different revisions of one platform... :)

You did - I was just saying that some of our customers don't do it the way you 
were thinking.

- makes it easier to cross-check against board schematics,
  by keeping most board-specific setup in one source file;
  
  Yes - but we are not talking about muxing a common peripheral (like a
  single UART) out many different pins (A or B or C). The UART pins are
  fixed. If you want the UART, you need to use pin A. If you want to use
  the I2C that also sits on pin A, you will get the message:
  pin A, requested by I2C, was already claimed by UART driver.
 
 Not all platforms work that way though.  There can often be several
 options for where a given signal gets routed.

But this is how it _always_ works on Blackfin. For other systems - like ARM, 
where n+1 silicon manufactures are all implementing things differently - I 
can understand your comments.


- allows the label to be more descriptive ... describeing
  exactly *which* IRQ, so that using the labels for better
  diagnostics actually gives better diagnostics.
  
  I'm not sure what you mean?
 
 The $SUBJECT patch uses the string IRQ in all cases.
 But smc_irq and codec_irq would be more informative
 as entries in a list of even just a handful of GPIOs.
 And with a few dozen, I'd find IRQ not at all helpful.

I agree - things can always be more descriptive.

   Again, not wrong; but probably sub-optimal.  You might
   want to move towards earlier binding now, while Linux is
   still young on Blackfin and you don't have legacy code to
   worry about.
  
  Our overall goal is to keep as much code - including bootloader -
  platform  agnostic, and not require people to write any of
  code/configuration data to boot up something, and get things
  working in a semi-standard manner. 
 
 The issue is just where those limits lie.  IMO it's not at
 all unreasonable to require board-specific code.  External
 chips will need board-specfic glue data in most cases (how
 they're addressed, what IRQs they use, and so on); and you
 may have drivers available that correspond to devices that
 are not wired up on that particular hardware.
 
 
  This still has it's limits - which is why we publish all our hardware
  designs. If you implement things the similar way (because for the
  most part it is fixed by the processor designer) - the
  bootloader/kernel/driver will just work.
 
 Sure ... you'd

Re: [PATCH 01/12] Blackfin arch: add peripheral resource allocation support

[Robin Getz]

On Fri 17 Aug 2007 17:10, David Brownell pondered:
> On the other hand, maybe you want your "typical" customer to
> be more of a systems integrator than anything else.

We are getting yelled at by our customers (I was on the phone yesterday), 
because the kernel build environment we distribute (the default) was not 
inside Eclipse, and someone couldn't push a button on a GUI rather than 
typing "make".

While Linux and other open source software is free, for some taking advantage 
of its benefits can require a significant investment in time. Linux is 
powerful, rich, and flexible. It is these very characteristics that make 
Linux so appealing that also create a significant level of complexity.

We are seeing more and more "first time buyers" jumping from bare metal - no 
OS, to Linux. For them - the ease of not having to write configuration files 
gives them a warm fuzzy feeling when they boot their board, and it 
just "works".

> > While potentially causing conflicting usage, for someone without
> > detailed hardware knowledge. The platform device board file is a good
> > thing to track conflicting memory or IO space resources as well as
> > IRQs. We also utilize platform device files for exactly these purposes.
> > 
> > The dynamic resource allocation for pinmux and gpio seems to us the
> > best way to handle things. The "resource allocation" mechanism will
> > spill an error and dump in case conflicting usage is detected. It'll
> > also tell you who is causing the conflicting usage.   
> 
> That's your call, of course.  I was pointing out why the "early"
> binding of pin resources is the more usual strategy with Linux.
> A "late" strategy is a bit surprising, and has its own issues.

Agreed - Every implementation has its own issues, but based on what we were 
being asked to do - it was the best way we could accommodate everyone.

> > >That said, how you handle pinmux on Blackfin is your business.
> > >
> > >But you should know that this approach seems idiosyncratic and
> > >more complex than needed:  when pin config is done early and as
> > >part of board setup, drivers don't need to care about it or to
> > >handle any pinmux errors.  And heck, products can sometimes be
> > >shipped with the bootloader having done all pinmux setup, so
> > >Linux won't need to worry about it at all.  That can help ship
> > >multiple board revisions using the same kernel.
> > 
> > This works for fixed function boards.
> 
> That is, for typical products embedding Linux...

We have multiple customers shipping the same bootloader/kernel binary on 
different products, and the only difference is the /etc/rc file - which 
drivers they install, and a few things in userspace.

Could this be smaller - sure - but NAND is cheap (according to them) compared 
to the effort and cost of maintaining and testing multiple kernel versions 
for every product.
 
Could this be faster - sure - but it is done at init - and then never again. 
We have a ~2-3 second boot time - maybe we shave off a few ms - things go 
pretty fast at 600MHz.

-Robin
-
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 02/12] Blackfin arch: Add label to call new GPIO API

[Robin Getz]

On Fri 17 Aug 2007 14:24, David Brownell pondered:
> Just for the record, this is an unusual way to use these calls.

That is part of the natural evolution of the kernel isn't it - per James's 
keynote at OLS - you release something, and see how people [ab]use it until 
it either grows, evolves, or it dies.

> Other platforms completely decouple these issues from the
> IRQ infrastructure ... doing the pinmux and gpio claiming
> separately from the request_irq()/free_irq() paths, mostly
> as part of board setup.  Doing all of that "early":

is early:
 - early in the kernel?
 - early before the kernel? (in the bootloader).

>  - keeps those error returns from causing hard-to-track-down
>runtime bugs;

The current Blackfin implementation causes a run time message:
"the pin  driver requested, was already claimed by yyy driver".

I don't think that is too bad?

>  - works always, even on platforms where a given IRQ may
>appear on any of several pins/balls;

But requires custom bootloaders or board setup for every hardware platform? 
Most of our users would not like that, since they do as you say - use the 
same kernel - with different drivers on multiple platforms.

>  - makes it easier to cross-check against board schematics,
>by keeping most board-specific setup in one source file;

Yes - but we are not talking about muxing a common peripheral (like a single 
UART) out many different pins (A or B or C). The UART pins are fixed. If you 
want the UART, you need to use pin A. If you want to use the I2C that also 
sits on pin A, you will get the message:
"pin A, requested by I2C, was already claimed by UART driver".

>  - shrinks the kernel's runtime footprint;

I agree - making things more flexible/easier to use - is normally more 
complex/larger/slower. (I know - easier to use is a matter of opinion). Since 
this is normally done once, in _init functions, I'm not sure that makes much 
of a difference here.
 
>  - allows the label to be more descriptive ... describeing
>exactly *which* IRQ, so that using the labels for better
>diagnostics actually gives better diagnostics.

I'm not sure what you mean?

> Again, not "wrong"; but probably sub-optimal.  You might
> want to move towards earlier binding now, while Linux is
> still young on Blackfin and you don't have legacy code to
> worry about.

Our overall goal is to keep as much code - including bootloader - platform 
agnostic, and not require people to write any of code/configuration data to 
boot up something, and get things working in a semi-standard manner.

This still has it's limits - which is why we publish all our hardware designs. 
If you implement things the similar way (because for the most part it is 
fixed by the processor designer) - the bootloader/kernel/driver will just 
work.

I would rather force a little extra complexity on me (as a kernel developer) 
than have to answer thousands of questions from end users, who are trying to 
move the kernel onto their hardware.

-Robin
-
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: Early printk behaviour

[Robin Getz]

On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> >
> > Something like:
> >
> > Index: kernel/printk.c
> > ===
> > --- kernel/printk.c (revision 3568)
> > +++ kernel/printk.c (working copy)
> > @@ -1104,6 +1104,22 @@
> >  }
> >  EXPORT_SYMBOL(unregister_console);
> >
> > +int __init disable_boot_consoles(void)
> > +{
> > +   struct console *con;
> > +
> > +   for (con = console_drivers; con; con = con->next) {
> > +   if (con->flags & CON_BOOT) {
> > +   printk(KERN_INFO "Unregister BootConsole %s%d\n",
> > +   con->name, con->index);
> > +   unregister_console(con);
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +late_initcall(disable_boot_consoles);
> 
> is there any need for a return value then ?
> void __init disable_boot_consoles(void);

So, we don't get compiler warnings?

Otherwise:
kernel/printk.c:1119: warning: initialization from incompatible pointer type

> and if we dont think anyone else wants to call it ...
> static void __init disable_boot_consoles(void);

So I think static is Ok, but it needs to be int - that is the proper prototype

-Robin
-
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: Early printk behaviour

[Robin Getz]

On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
> Mike Frysinger wrote:
> >> Hmm, sort of, although I didn't think about the case of no real console
> >> replacing the early console.  The intention of the patch is to have a
> >> smooth handover from the boot console to the real console.  And, yes, if
> >> no real console is ever registered the boot console keeps running ...
> > 
> > i think it also occurs in the case where real console != early console
> 
> No.  At least not of the boot console has the CON_BOOT flag set as it
> should.  Last message you'll see on the boot console is the handover
> printk, telling you which real console device prints the following
> messages.  Whenever early and real console go to the physical device or
> not doesn't matter.
> 
> >> So you can either let it running and *not* mark it __init, so it can
> >> keep on going without breaking.  Or you can explicitly unregister your
> >> boot console at some point, maybe using a late_initcall.
> > 
> > wouldnt a common kernel late_initcall() be more appropriate ?  if
> > early console hasnt switched over (for whatever reason), then kill it
> 
> Hmm, yes, should be doable in generic code.  Check whenever the current
> console has CON_BOOT set and if so unregister it.

Something like:

Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
 }
 EXPORT_SYMBOL(unregister_console);

+int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con->next) {
+   if (con->flags & CON_BOOT) {
+   printk(KERN_INFO "Unregister BootConsole %s%d\n",
+   con->name, con->index);
+   unregister_console(con);
+   }
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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: [draft] Blackfin Early Printk implmentation

[Robin Getz]

537/head.S (revision 3568)
+++ linux-2.6.x/arch/blackfin/mach-bf537/head.S (working copy)
@@ -224,6 +224,12 @@
fp = sp;
usp = sp;
 
+#ifdef CONFIG_EARLY_PRINTK
+   SP += -12;
+   call _init_early_exception_vectors;
+   SP += 12;
+#endif
+
/* Put The Code for PLL Programming and SDRAM Programming in L1 ISRAM */
call _bf53x_relocate_l1_mem;
 #if CONFIG_BFIN_KERNEL_CLOCK
Index: linux-2.6.x/arch/blackfin/mach-bf548/head.S
===
--- linux-2.6.x/arch/blackfin/mach-bf548/head.S (revision 3568)
+++ linux-2.6.x/arch/blackfin/mach-bf548/head.S (working copy)
@@ -125,6 +125,12 @@
FP = SP;
USP = SP;
 
+#ifdef CONFIG_EARLY_PRINTK
+   SP += -12;
+   call _init_early_exception_vectors;
+   SP += 12;
+#endif
+
/* Put The Code for PLL Programming and SDRAM Programming in L1 ISRAM */
call _bf53x_relocate_l1_mem;
 #if CONFIG_BFIN_KERNEL_CLOCK
Index: linux-2.6.x/arch/blackfin/mach-common/entry.S
===
--- linux-2.6.x/arch/blackfin/mach-common/entry.S   (revision 3568)
+++ linux-2.6.x/arch/blackfin/mach-common/entry.S   (working copy)
@@ -803,14 +803,57 @@
 .section .l1.data.B
 #endif
 ENTRY(_trace_buff_offset)
-.long 0;
+   .long 0;
 ALIGN
 ENTRY(_software_trace_buff)
.rept ((1 << CONFIG_DEBUG_BFIN_HWTRACE_EXPAND_LEN)*256);
.long 0
.endr
+#endif /* CONFIG_DEBUG_BFIN_HWTRACE_EXPAND */
+
+#ifdef CONFIG_EARLY_PRINTK
+#ifdef CONFIG_EXCPT_IRQ_SYSC_L1
+.section .l1.text
+#else
+.text
 #endif
 
+ENTRY(_early_trap)
+   SAVE_ALL_SYS
+   trace_buffer_stop(p0, r0);
+
+   /* Turn caches off, to ensure we don't get double exceptions */
+
+   P4.L = LO(IMEM_CONTROL);
+   P4.H = HI(IMEM_CONTROL);
+
+   R5 = [P4];  /* Control Register*/
+   BITCLR(R5,ENICPLB_P);
+   CLI R1;
+   SSYNC;  /* SSYNC required before writing to IMEM_CONTROL. */
+   .align 8;
+   [P4] = R5;
+   SSYNC;
+
+   P4.L = LO(DMEM_CONTROL);
+   P4.H = HI(DMEM_CONTROL);
+   R5 = [P4];
+   BITCLR(R5,ENDCPLB_P);
+   SSYNC;  /* SSYNC required before writing to DMEM_CONTROL. */
+   .align 8;
+   [P4] = R5;
+   SSYNC;
+   STI R1;
+
+   r0 = sp;/* stack frame pt_regs pointer argument ==> r0 */
+   r1 = RETX;
+
+   SP += -12;
+   call _early_trap_c;
+   SP += 12;
+ENDPROC(_early_trap)
+#endif /* CONFIG_EARLY_PRINTK */
+
 /*
  * Put these in the kernel data section - that should always be covered by
  * a CPLB. This is needed to ensure we don't get double fault conditions


> -> adds early_printk





Index: linux-2.6.x/include/asm-blackfin/early_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author:   Robin Getz <[EMAIL PROTECTED]
+ *
+ * Created:  14Aug2007
+ * Description:  function prototpyes for early printk
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_EARLY_PRINTK
+extern int setup_early_printk(char *);
+#else
+#define setup_early_printk(fmt) do { } while (0)
+#endif /* CONFIG_EARLY_PRINTK */

Index: linux-2.6.x/Documentation/kernel-parameters.txt
===
--- linux-2.6.x/Documentation/kernel-parameters.txt (revision 3568)
+++ linux-2.6.x/Documentation/kernel-parameters.txt (working copy)
@@ -34,6 +34,7 @@
APICAPIC support is enabled.
APM Advanced Power Management support is enabled.
AX25Appropriate AX.25 support is enabled.
+   BLACKFIN Blackfin architecture is enabled.
CD  Appropriate CD support is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -558,7 +559,7 @@
 
dtc3181e=   [HW,SCSI]
 
-   earlyprintk=[IA-32,X86-64,SH]
+   earlyprintk=[IA-32,X86-64,SH,BLACKFIN]
earlyprintk=vga
earlyprintk=serial[,ttySn[,baudrate]]

I

Re: [draft] Blackfin Early Printk implmentation

[Robin Getz]

On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> > +int __init disable_early_printk(void)
> > +{
> > +   if (!early_console_initialized)
> > +   return 0;
> > +
> > +   printk(KERN_INFO "Unregister %s%d\n", 
early_console_initialized->name,
> > +   early_console_initialized->index);
> > +   unregister_console(early_console_initialized);
> > +   early_console_initialized = NULL;
> > +   return 0;
> > +}
> > +
> > +late_initcall(disable_early_printk);
> 
> i think we agreed this would be OK/good to have in common code

I didn't hear back from Gerd - and in the past this was implemented in the
arch/*/kernel/early_printk.c - so this is where I put it

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

[draft] Blackfin Early Printk implmentation

[Robin Getz]

The patch (for review - not inclusion - I will send to Bryan if no one has any 
major objections, and he can push it via git) implements early printk for the 
Blackfin architecture.

It also adds an early exception handler, so if an 
interrupt/exception/violation happens before the kernel enables it's 
interrupts (yes that does happen periodically, and it is a nice to have a 
debug feature to help , that we don't go back to the bootloaders exception 
processing table...

It also removes some of the crap that was trying to implement the same thing 
(poorly).

Before I send to Bryan "officially" - I thought I would see what others think.


---

 Documentation/kernel-parameters.txt |3
 arch/blackfin/Kconfig   |   32 +--
 arch/blackfin/kernel/Makefile   |1
 arch/blackfin/kernel/early_printk.c |  210 +
 arch/blackfin/kernel/setup.c|   76 +++
 arch/blackfin/mach-bf533/head.S |  249 --
 arch/blackfin/mach-bf537/head.S |6
 arch/blackfin/mach-bf548/head.S |6
 arch/blackfin/mach-bf561/head.S |6
 arch/blackfin/mach-common/entry.S   |   45 
 drivers/serial/bfin_5xx.c   |  130 ++---
 include/asm-blackfin/early_printk.h |   28 ++
 include/asm-blackfin/irq_handler.h  |   22 ++
 13 files changed, 485 insertions(+), 329 deletions(-)



Index: linux-2.6.x/include/asm-blackfin/early_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author:   Robin Getz <[EMAIL PROTECTED]
+ *
+ * Created:  14Aug2007
+ * Description:  function prototpyes for early printk
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_EARLY_PRINTK
+extern int setup_early_printk(char *);
+#else
+#define setup_early_printk(fmt) do { } while (0)
+#endif /* CONFIG_EARLY_PRINTK */
Index: linux-2.6.x/include/asm-blackfin/irq_handler.h
===
--- linux-2.6.x/include/asm-blackfin/irq_handler.h  (revision 3568)
+++ linux-2.6.x/include/asm-blackfin/irq_handler.h  (working copy)
@@ -1,3 +1,24 @@
+/*
+ * File: include/asm-blackfin/irq_handler.h
+ *
+ * Description:  function prototypes for interrupt handler routines
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
 #ifndef _IRQ_HANDLER_H
 #define _IRQ_HANDLER_H
 
@@ -22,6 +43,7 @@
 asmlinkage void init_exception_buff(void);
 asmlinkage void trap_c(struct pt_regs *fp);
 asmlinkage void ex_replaceable(void);
+asmlinkage void early_trap(void);
 
 extern void *ex_table[];
 extern void return_from_exception(void);
Index: linux-2.6.x/Documentation/kernel-parameters.txt
===
--- linux-2.6.x/Documentation/kernel-parameters.txt (revision 3568)
+++ linux-2.6.x/Documentation/kernel-parameters.txt (working copy)
@@ -34,6 +34,7 @@
APICAPIC support is enabled.
APM Advanced Power Management support is enabled.
AX25Appropriate AX.25 support is enabled.
+   BLACKFIN Blackfin architecture is enabled.
CD  Appropriate CD support is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -558,7 +559,7 @@
 
dtc3181e=   [HW,SCSI]
 
-   earlyprintk=[IA-32,X86-64,SH]
+   earlyprintk=[IA-32,X86-64,SH,BLACKFIN]
earlyprintk=vga
earlyprintk=serial[,ttySn[,baudrate]]
 
Index: linux-2.6.x/

[draft] Blackfin Early Printk implmentation

[Robin Getz]

The patch (for review - not inclusion - I will send to Bryan if no one has any 
major objections, and he can push it via git) implements early printk for the 
Blackfin architecture.

It also adds an early exception handler, so if an 
interrupt/exception/violation happens before the kernel enables it's 
interrupts (yes that does happen periodically, and it is a nice to have a 
debug feature to help , that we don't go back to the bootloaders exception 
processing table...

It also removes some of the crap that was trying to implement the same thing 
(poorly).

Before I send to Bryan officially - I thought I would see what others think.


---

 Documentation/kernel-parameters.txt |3
 arch/blackfin/Kconfig   |   32 +--
 arch/blackfin/kernel/Makefile   |1
 arch/blackfin/kernel/early_printk.c |  210 +
 arch/blackfin/kernel/setup.c|   76 +++
 arch/blackfin/mach-bf533/head.S |  249 --
 arch/blackfin/mach-bf537/head.S |6
 arch/blackfin/mach-bf548/head.S |6
 arch/blackfin/mach-bf561/head.S |6
 arch/blackfin/mach-common/entry.S   |   45 
 drivers/serial/bfin_5xx.c   |  130 ++---
 include/asm-blackfin/early_printk.h |   28 ++
 include/asm-blackfin/irq_handler.h  |   22 ++
 13 files changed, 485 insertions(+), 329 deletions(-)



Index: linux-2.6.x/include/asm-blackfin/early_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author:   Robin Getz [EMAIL PROTECTED]
+ *
+ * Created:  14Aug2007
+ * Description:  function prototpyes for early printk
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_EARLY_PRINTK
+extern int setup_early_printk(char *);
+#else
+#define setup_early_printk(fmt) do { } while (0)
+#endif /* CONFIG_EARLY_PRINTK */
Index: linux-2.6.x/include/asm-blackfin/irq_handler.h
===
--- linux-2.6.x/include/asm-blackfin/irq_handler.h  (revision 3568)
+++ linux-2.6.x/include/asm-blackfin/irq_handler.h  (working copy)
@@ -1,3 +1,24 @@
+/*
+ * File: include/asm-blackfin/irq_handler.h
+ *
+ * Description:  function prototypes for interrupt handler routines
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
 #ifndef _IRQ_HANDLER_H
 #define _IRQ_HANDLER_H
 
@@ -22,6 +43,7 @@
 asmlinkage void init_exception_buff(void);
 asmlinkage void trap_c(struct pt_regs *fp);
 asmlinkage void ex_replaceable(void);
+asmlinkage void early_trap(void);
 
 extern void *ex_table[];
 extern void return_from_exception(void);
Index: linux-2.6.x/Documentation/kernel-parameters.txt
===
--- linux-2.6.x/Documentation/kernel-parameters.txt (revision 3568)
+++ linux-2.6.x/Documentation/kernel-parameters.txt (working copy)
@@ -34,6 +34,7 @@
APICAPIC support is enabled.
APM Advanced Power Management support is enabled.
AX25Appropriate AX.25 support is enabled.
+   BLACKFIN Blackfin architecture is enabled.
CD  Appropriate CD support is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -558,7 +559,7 @@
 
dtc3181e=   [HW,SCSI]
 
-   earlyprintk=[IA-32,X86-64,SH]
+   earlyprintk=[IA-32,X86-64,SH,BLACKFIN]
earlyprintk=vga
earlyprintk=serial[,ttySn[,baudrate]]
 
Index: linux-2.6.x/arch/blackfin

Re: [draft] Blackfin Early Printk implmentation

[Robin Getz]

On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
 On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
  +int __init disable_early_printk(void)
  +{
  +   if (!early_console_initialized)
  +   return 0;
  +
  +   printk(KERN_INFO Unregister %s%d\n, 
early_console_initialized-name,
  +   early_console_initialized-index);
  +   unregister_console(early_console_initialized);
  +   early_console_initialized = NULL;
  +   return 0;
  +}
  +
  +late_initcall(disable_early_printk);
 
 i think we agreed this would be OK/good to have in common code

I didn't hear back from Gerd - and in the past this was implemented in the
arch/*/kernel/early_printk.c - so this is where I put it

-Robin
-
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: [draft] Blackfin Early Printk implmentation

[Robin Getz]

 +224,12 @@
fp = sp;
usp = sp;
 
+#ifdef CONFIG_EARLY_PRINTK
+   SP += -12;
+   call _init_early_exception_vectors;
+   SP += 12;
+#endif
+
/* Put The Code for PLL Programming and SDRAM Programming in L1 ISRAM */
call _bf53x_relocate_l1_mem;
 #if CONFIG_BFIN_KERNEL_CLOCK
Index: linux-2.6.x/arch/blackfin/mach-bf548/head.S
===
--- linux-2.6.x/arch/blackfin/mach-bf548/head.S (revision 3568)
+++ linux-2.6.x/arch/blackfin/mach-bf548/head.S (working copy)
@@ -125,6 +125,12 @@
FP = SP;
USP = SP;
 
+#ifdef CONFIG_EARLY_PRINTK
+   SP += -12;
+   call _init_early_exception_vectors;
+   SP += 12;
+#endif
+
/* Put The Code for PLL Programming and SDRAM Programming in L1 ISRAM */
call _bf53x_relocate_l1_mem;
 #if CONFIG_BFIN_KERNEL_CLOCK
Index: linux-2.6.x/arch/blackfin/mach-common/entry.S
===
--- linux-2.6.x/arch/blackfin/mach-common/entry.S   (revision 3568)
+++ linux-2.6.x/arch/blackfin/mach-common/entry.S   (working copy)
@@ -803,14 +803,57 @@
 .section .l1.data.B
 #endif
 ENTRY(_trace_buff_offset)
-.long 0;
+   .long 0;
 ALIGN
 ENTRY(_software_trace_buff)
.rept ((1  CONFIG_DEBUG_BFIN_HWTRACE_EXPAND_LEN)*256);
.long 0
.endr
+#endif /* CONFIG_DEBUG_BFIN_HWTRACE_EXPAND */
+
+#ifdef CONFIG_EARLY_PRINTK
+#ifdef CONFIG_EXCPT_IRQ_SYSC_L1
+.section .l1.text
+#else
+.text
 #endif
 
+ENTRY(_early_trap)
+   SAVE_ALL_SYS
+   trace_buffer_stop(p0, r0);
+
+   /* Turn caches off, to ensure we don't get double exceptions */
+
+   P4.L = LO(IMEM_CONTROL);
+   P4.H = HI(IMEM_CONTROL);
+
+   R5 = [P4];  /* Control Register*/
+   BITCLR(R5,ENICPLB_P);
+   CLI R1;
+   SSYNC;  /* SSYNC required before writing to IMEM_CONTROL. */
+   .align 8;
+   [P4] = R5;
+   SSYNC;
+
+   P4.L = LO(DMEM_CONTROL);
+   P4.H = HI(DMEM_CONTROL);
+   R5 = [P4];
+   BITCLR(R5,ENDCPLB_P);
+   SSYNC;  /* SSYNC required before writing to DMEM_CONTROL. */
+   .align 8;
+   [P4] = R5;
+   SSYNC;
+   STI R1;
+
+   r0 = sp;/* stack frame pt_regs pointer argument == r0 */
+   r1 = RETX;
+
+   SP += -12;
+   call _early_trap_c;
+   SP += 12;
+ENDPROC(_early_trap)
+#endif /* CONFIG_EARLY_PRINTK */
+
 /*
  * Put these in the kernel data section - that should always be covered by
  * a CPLB. This is needed to ensure we don't get double fault conditions


 - adds early_printk





Index: linux-2.6.x/include/asm-blackfin/early_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author:   Robin Getz [EMAIL PROTECTED]
+ *
+ * Created:  14Aug2007
+ * Description:  function prototpyes for early printk
+ *
+ * Modified:
+ *   Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_EARLY_PRINTK
+extern int setup_early_printk(char *);
+#else
+#define setup_early_printk(fmt) do { } while (0)
+#endif /* CONFIG_EARLY_PRINTK */

Index: linux-2.6.x/Documentation/kernel-parameters.txt
===
--- linux-2.6.x/Documentation/kernel-parameters.txt (revision 3568)
+++ linux-2.6.x/Documentation/kernel-parameters.txt (working copy)
@@ -34,6 +34,7 @@
APICAPIC support is enabled.
APM Advanced Power Management support is enabled.
AX25Appropriate AX.25 support is enabled.
+   BLACKFIN Blackfin architecture is enabled.
CD  Appropriate CD support is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -558,7 +559,7 @@
 
dtc3181e=   [HW,SCSI]
 
-   earlyprintk=[IA-32,X86-64,SH]
+   earlyprintk=[IA-32,X86-64,SH,BLACKFIN]
earlyprintk=vga
earlyprintk=serial[,ttySn[,baudrate]]

Index: linux-2.6.x/arch/blackfin/kernel/early_printk.c

Re: Early printk behaviour

[Robin Getz]

On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
 Mike Frysinger wrote:
  Hmm, sort of, although I didn't think about the case of no real console
  replacing the early console.  The intention of the patch is to have a
  smooth handover from the boot console to the real console.  And, yes, if
  no real console is ever registered the boot console keeps running ...
  
  i think it also occurs in the case where real console != early console
 
 No.  At least not of the boot console has the CON_BOOT flag set as it
 should.  Last message you'll see on the boot console is the handover
 printk, telling you which real console device prints the following
 messages.  Whenever early and real console go to the physical device or
 not doesn't matter.
 
  So you can either let it running and *not* mark it __init, so it can
  keep on going without breaking.  Or you can explicitly unregister your
  boot console at some point, maybe using a late_initcall.
  
  wouldnt a common kernel late_initcall() be more appropriate ?  if
  early console hasnt switched over (for whatever reason), then kill it
 
 Hmm, yes, should be doable in generic code.  Check whenever the current
 console has CON_BOOT set and if so unregister it.

Something like:

Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
 }
 EXPORT_SYMBOL(unregister_console);

+int __init disable_boot_consoles(void)
+{
+   struct console *con;
+
+   for (con = console_drivers; con; con = con-next) {
+   if (con-flags  CON_BOOT) {
+   printk(KERN_INFO Unregister BootConsole %s%d\n,
+   con-name, con-index);
+   unregister_console(con);
+   }
+   }
+   return 0;
+}
+late_initcall(disable_boot_consoles);
+
+
 /**
  * tty_write_message - write a message to a certain tty, not just the console.
  * @tty: the destination tty_struct
-
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: Early printk behaviour

[Robin Getz]

On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
 On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
 
  Something like:
 
  Index: kernel/printk.c
  ===
  --- kernel/printk.c (revision 3568)
  +++ kernel/printk.c (working copy)
  @@ -1104,6 +1104,22 @@
   }
   EXPORT_SYMBOL(unregister_console);
 
  +int __init disable_boot_consoles(void)
  +{
  +   struct console *con;
  +
  +   for (con = console_drivers; con; con = con-next) {
  +   if (con-flags  CON_BOOT) {
  +   printk(KERN_INFO Unregister BootConsole %s%d\n,
  +   con-name, con-index);
  +   unregister_console(con);
  +   }
  +   }
  +   return 0;
  +}
  +late_initcall(disable_boot_consoles);
 
 is there any need for a return value then ?
 void __init disable_boot_consoles(void);

So, we don't get compiler warnings?

Otherwise:
kernel/printk.c:1119: warning: initialization from incompatible pointer type

 and if we dont think anyone else wants to call it ...
 static void __init disable_boot_consoles(void);

So I think static is Ok, but it needs to be int - that is the proper prototype

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