Pending patches

Pending patches

[Alan Stern]

James:

May I draw your attention to these patch submissions:

http://marc.theaimsgroup.com/?l=linux-scsi&m=111221335824727&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112117962214214&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238708903663&w=2 (this 
	is a cover message, not a patch)
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238753725214&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

I never received any word back after submitting them, and they aren't 
present in the source tree at

http://www.parisc-linux.org/cgi-bin/gitweb.pl

Is it possible to get these patches into the queue?

Alan Stern

Re: Pending patches

[Patrick Mansfield]

On Tue, Sep 06, 2005 at 04:17:53PM -0400, Alan Stern wrote:

> I never received any word back after submitting them, and they aren't 
> present in the source tree at
> 
> http://www.parisc-linux.org/cgi-bin/gitweb.pl
> 
> Is it possible to get these patches into the queue?

Not that your patches are in it, but the scsi-misc tre is at:

http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary

-- Patrick Mansfield

Re: Pending patches

[Alan Stern]

On Tue, 6 Sep 2005, Patrick Mansfield wrote:

> On Tue, Sep 06, 2005 at 04:17:53PM -0400, Alan Stern wrote:
> 
> > I never received any word back after submitting them, and they aren't 
> > present in the source tree at
> > 
> > http://www.parisc-linux.org/cgi-bin/gitweb.pl
> > 
> > Is it possible to get these patches into the queue?
> 
> Not that your patches are in it, but the scsi-misc tre is at:
> 
> http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary

Thanks for the pointer.  James's earlier message didn't make it clear
whether the browser he mentioned was for the scsi-rc-fixes tree or the
scsi-misc tree.  Nor was it clear which patches one should expect to find 
in those two trees; I assume that patches go first into the scsi-misc 
tree, then eventually migrate to the scsi-rc-fixes tree, and hence to 
Linus.  Is that right?

Alan Stern

Re: Pending patches

[James Bottomley]

On Tue, 2005-09-06 at 16:17 -0400, Alan Stern wrote:
> May I draw your attention to these patch submissions:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=111221335824727&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112117962214214&w=2

These two should be in.

> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238708903663&w=2 (this 
> 	is a cover message, not a patch)
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238753725214&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

I was hoping that Mike Anderson would review these, but since he hasn't
I'll take a look.

James

Re: Pending patches

[Mike Anderson]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Tue, 2005-09-06 at 16:17 -0400, Alan Stern wrote:
> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2

On as542. The first hunk of the diff is already in (declare of
scsi_host_set_state). The second hunk looks good (SHOST_RECOVERY label).
The third hunk I will take in combination with the other patch that
effects the scan code. This should have probably been
another patch.

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2

Have not looked at this yet, but will look at it in combination to the
above scan change.

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2

Do we need to revist how we are walking these lists for cleanup post
James's kilst fix / update?

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

This looks ok for an added check, but I guess I need to look at old mail
and understand how we got here with the added scan mutex.

> 
> I was hoping that Mike Anderson would review these, but since he hasn't
> I'll take a look.

Sorry asleep at the keyboard on these. Comments above if you have not
already looked at them.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Pending patches

[Dirk Behme]

Hello,

find below a list of pending patches from last weeks.

Feel free to update, correct, extend etc.

Hth,

Dirk


List of pending patches for OMAP Linux.

Last modified: 2005/12/27

Pending patches (ready for inclusion):
======================================

1) Fix OMAP audio miscompile
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005830.html

2) Fix miscompile if CONFIG_FB_OMAP_LCDC_INTERNAL=n
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005831.html

3) Fix omap keypad
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005833.html

4) Convert touchscreen to input_allocate_device
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005837.html
(input_allocate_device & timer fix)

_or_ (timer fix only!)

OMAP touchscreen timer BUG
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005899.html

5) Fix warning in pm.c
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005838.html

6) USB clock changes from Juha
http://linux.omap.com/pipermail/linux-omap-open-source/2005-August/004818.html
(http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005846.html)
(http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006027.html)

7) OSS Audio L/R Channel Interchanges fix
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005890.html

8) omap1510 MPU interupt BUG
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005894.html

9) LDM wakeup flags for OMAP keypad
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005897.html

10) Add MMC password protection (lock/unlock) support
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005911.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005912.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005913.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005914.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005915.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005916.html

Note: Still in discussion with RMK?

11) MMC - CONFIG_HOTPLUG support
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005963.html

Note: Still in discussion with RMK?

12) ALSA Audio L/R Channel Interchanges fix
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005971.html

13) Disable DEBUG_LL in omap_h3_1710_defconfig
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005997.html

14) I2C: Use struct platform_driver
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006025.html


Experimental & test (do not apply yet):
=======================================

1) omap24xx vout and dispc library
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005932.html

2) omap24xx spi + touchscreen
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005980.html

3) keypad: platform_data and 24xx support -exp
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005889.html

4) omap24xx IrDA update
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005992.html


Already applied (by Juha, nothing to do):
=========================================

1) Omapfb: panel enable/disable reordering
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005844.html

2) H3 LCD clocking changes suggested by the driver
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005898.html

3) fix watchdog
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005969.html

Re: Pending patches

[Anderson.Briglia]

> Hello,

> find below a list of pending patches from last weeks.

> Feel free to update, correct, extend etc.

> Hth,

> Dirk

> List of pending patches for OMAP Linux.

> Last modified: 2005/12/27

> Pending patches (ready for inclusion):
> ======================================

> 11) MMC - CONFIG_HOTPLUG support
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005963.html

> Note: Still in discussion with RMK?

I guess it's ok this one. Please, see the lastest RMK e-mail about the patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006024.html

BR,

Anderson Briglia

Re: Pending patches

[Anderson Lizardo]

On 12/27/05, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> Hello,
>
> find below a list of pending patches from last weeks.
>
> Feel free to update, correct, extend etc.
> [...]
> 10) Add MMC password protection (lock/unlock) support

Hi,

These series of patches are not intended for inclusion on linux-omap
(they are platform independent). We have CC: ed the linux-omap list
because one of the patches is OMAP specific:

http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005916.html

But this patch is still in discussion, so don't apply it yet.

Regards,
--
Anderson Lizardo
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil

Re: Pending patches

[Tony Lindgren]

* Dirk Behme <dirk.behme@de.bosch.com> [051227 01:56]:
> Hello,
> 
> find below a list of pending patches from last weeks.

Cool, this is a nice summary :)
 
> Feel free to update, correct, extend etc.

Anybody else know if pending patches?
 
> List of pending patches for OMAP Linux.
> 
> 6) USB clock changes from Juha
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-August/004818.html
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005846.html)
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006027.html)

No comments from Dave, so let's plan on pushing the USB clock patches.

Regards,

Tony 

pending patches

[Yoshinori K. Okuji]

Hello,

As you know, I am quite inactive these days, and haven't dealt with pending 
patches at all. But I am willing to solve them as soon as possible, thus I 
would appreciate if somebody could assist me. Unfortunately, due to my short 
memory, I even don't remember all of them. In addition, I now have 400 unread 
messages in my mailbox, and I don't think I can read every message carefully.

So, if you know any patches I should take a look, please remind me. What I can 
recall are:

- IA-64 port. I think I can find it myself.

- Various patches by Ozeki-san.

- (Unofficial) reiserfs patch by Vincent. I must test this really soon...

Best regards,
Okuji

Re: pending patches

[Robert Millan]

Hi Okuji!

Sorry for the late reply.  I don't have much time lately either.. ;-)

On Tue, Aug 07, 2007 at 09:26:31PM +0200, Yoshinori K. Okuji wrote:
> Hello,
> 
> As you know, I am quite inactive these days, and haven't dealt with pending 
> patches at all. But I am willing to solve them as soon as possible, thus I 
> would appreciate if somebody could assist me. Unfortunately, due to my short 
> memory, I even don't remember all of them. In addition, I now have 400 unread 
> messages in my mailbox, and I don't think I can read every message carefully.
> 
> So, if you know any patches I should take a look, please remind me. What I can 
> recall are:
> 
> - IA-64 port. I think I can find it myself.
> 
> - Various patches by Ozeki-san.
> 
> - (Unofficial) reiserfs patch by Vincent. I must test this really soon...

I found three patches/comments that I think deserve your attention:

  "bug-grub@gnu.org"

  http://lists.gnu.org/archive/html/grub-devel/2007-05/msg00083.html

  "Self multiboot patch"
  http://lists.gnu.org/archive/html/grub-devel/2007-06/msg00170.html

  "Re: Self multiboot patch" (Marco's reply)
  http://lists.gnu.org/archive/html/grub-devel/2007-07/msg00078.html

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: pending patches

[tgingold]

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> Hello,
>
> So, if you know any patches I should take a look, please remind me. What I
> can
> recall are:
>
> - IA-64 port. I think I can find it myself.

I plan to work again on the ia64 port soon.

There are three different parts/issues:

* ia64 specific files: no real issues, the copyright assignment process is
  completed.

* build issue: the old patch uses objdump+tricks to convert from ELF to PE/COFF
 (EFI object format).  A small part of the trick is based on an HP start.S which
 is not assigned to FSF.
  During work on EFI, I have written a standalone ELF to PE/COFF converted.  I
  still have to mark it work within the grub framework.  Not a lot of work but
  it requires a few hours.

* modules: Dynamically loading modules requires handling relocation, which is
  a nightmare on ia64.  On the other side, because it's ia64 and EFI this
  feature is certainly not a must have (this should be discussed more lengthly).
  This is currently working by prelinking required modules.
  I think the pre-link method is a good idea (it simplifies porting work),
  is not target dependent but patches common files.

This is the current status.
I am very interested in having an ia64 port of grub (almost required for Xen).
Tristan.

Re: pending patches

[Johan Rydberg]

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

tgingold@free.fr writes:

>   During work on EFI, I have written a standalone ELF to PE/COFF converted.  I
>   still have to mark it work within the grub framework.  Not a lot of work but
>   it requires a few hours.

IIRC, we already have a ELF to PE/COFF converter in GRUB.  Look at 
util/i386/efi/grub-mkimage.c .

If not, I have one written for GNUFI that could be used.  

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Pending patches

[Mauro Carvalho Chehab]

Hi guys,

Unfortunately, there were a crash at the server that I use for my inboxes. Due
to that, I lost several non-proccessed pull requests and e-mail patches that
should be committed into v4l-dvb tree and forward to kernel.

While I still hope that people will recover the lost e-mails, it would be safer
if those of you that forwarded me a patch, to re-send they to my inbox.

I kindly ask you to send those requests to me, c/c the lists, with the magic
tags at the subject:
[PATCH (resend)] - for patches that you're re-sending to me
[PULL (resend)] - for hg pull requests that you're re-sending



Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Pending patches

[Felipe Balbi]

Hi Tony,

You seem to have pushed most of the patches I sent but we're still
missing some of them.

Are there still any comments for those patches ? It's higly tested on my
n810 and all of them are working fine here.

Below is an output from:
$ git cherry master | cut -d+ -f2 | xargs git show --stat

commit a3b9e4f4397876d32d51f7fb3742318285a78601
Author: Daniel Stone <daniel.stone@nokia.com>
Date:   Mon Apr 7 17:07:37 2008 +0300

    I2C: LM8323: Introduce lm8323 keypad driver
    
    Introduce lm8323 keypad driver.
    
    Signed-off-by: Daniel Stone <daniel.stone@nokia.com
    
    Updated to build with recent linux-omap and new-style
    i2c driver.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |   77 ++++
 arch/arm/mach-omap2/board-n810.c |    2 +
 drivers/input/keyboard/Kconfig   |    7 +
 drivers/input/keyboard/Makefile  |    1 +
 drivers/input/keyboard/lm8323.c  |  911 ++++++++++++++++++++++++++++++++++++++
 include/linux/i2c/lm8323.h       |   39 ++
 6 files changed, 1037 insertions(+), 0 deletions(-)

commit a68ff943d8e2e09e218b127142dfa99e6c618ac8
Author: Mathias Nyman <mathias.nyman@nokia.com>
Date:   Mon Apr 7 16:21:28 2008 +0300

    I2C: TSL2563: Add support for Taos tsl2563 ambient light sensor
    
    Add support for Taos tsl2563 ambient light sensor.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
    
    Updated to build with current linux-omap, new-style
    i2c driver and cleaned up checkpatch.pl issues.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |    4 +
 drivers/i2c/chips/Kconfig        |   10 +
 drivers/i2c/chips/Makefile       |    2 +-
 drivers/i2c/chips/tsl2563.c      |  731 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 746 insertions(+), 1 deletions(-)

commit 9416f0ccc9669a0588e16f776308f8f6c9e91661
Author: Lauri Leukkunen <lauri.leukkunen@nokia.com>
Date:   Mon Apr 7 19:57:43 2008 +0300

    INPUT: TOUCHSCREEN: Introduce tsc2005 driver
    
    Introduce n810's tsc2005 driver
    
    Signed-off-by: Lauri Leukkunen <lauri.leukkunen@nokia.com>
    
    Updated to build with current linux-omap.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c    |   95 +++++-
 drivers/input/touchscreen/Kconfig   |    5 +
 drivers/input/touchscreen/Makefile  |    1 +
 drivers/input/touchscreen/tsc2005.c |  739 +++++++++++++++++++++++++++++++++++
 include/linux/spi/tsc2005.h         |   29 ++
 5 files changed, 865 insertions(+), 4 deletions(-)

commit 57871dcd31fa8598ae5d0d3e3979e5e6f5477ea4
Author: Mathias Nyman <mathias.nyman@nokia.com>
Date:   Tue Apr 8 13:33:04 2008 +0300

    I2C: LP5521: Introduce lp5521 LED driver
    
    Introduce n810's lp5521 LED driver.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com
    
    Updated to new style i2c driver and to build on current
    linux-omap head.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |    4 +
 drivers/i2c/chips/Kconfig        |    7 +
 drivers/i2c/chips/Makefile       |    1 +
 drivers/i2c/chips/lp5521.c       |  577 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 589 insertions(+), 0 deletions(-)

commit 88573faf7d1e556376c0abb1adaf3497d814660b
Author: Felipe Balbi <felipe.balbi@nokia.com>
Date:   Tue Apr 8 15:36:32 2008 +0300

    ARM: N800: Update n800 defconfig
    
    Enables recent drivers and usb.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/configs/n800_defconfig |  189 +++++++++++++++++++++++++++++++++++++--
 1 files changed, 182 insertions(+), 7 deletions(-)

-- 
	- Balbi

Re: Pending patches

[Tony Lindgren]

* Felipe Balbi <felipe.balbi@nokia.com> [080412 09:42]:
> Hi Tony,
> 
> You seem to have pushed most of the patches I sent but we're still
> missing some of them.
> 
> Are there still any comments for those patches ? It's higly tested on my
> n810 and all of them are working fine here.

Yeah, thanks. Pushing all of them today.

Tony


> Below is an output from:
> $ git cherry master | cut -d+ -f2 | xargs git show --stat
> 
> commit a3b9e4f4397876d32d51f7fb3742318285a78601
> Author: Daniel Stone <daniel.stone@nokia.com>
> Date:   Mon Apr 7 17:07:37 2008 +0300
> 
>     I2C: LM8323: Introduce lm8323 keypad driver
>     
>     Introduce lm8323 keypad driver.
>     
>     Signed-off-by: Daniel Stone <daniel.stone@nokia.com
>     
>     Updated to build with recent linux-omap and new-style
>     i2c driver.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |   77 ++++
>  arch/arm/mach-omap2/board-n810.c |    2 +
>  drivers/input/keyboard/Kconfig   |    7 +
>  drivers/input/keyboard/Makefile  |    1 +
>  drivers/input/keyboard/lm8323.c  |  911 ++++++++++++++++++++++++++++++++++++++
>  include/linux/i2c/lm8323.h       |   39 ++
>  6 files changed, 1037 insertions(+), 0 deletions(-)
> 
> commit a68ff943d8e2e09e218b127142dfa99e6c618ac8
> Author: Mathias Nyman <mathias.nyman@nokia.com>
> Date:   Mon Apr 7 16:21:28 2008 +0300
> 
>     I2C: TSL2563: Add support for Taos tsl2563 ambient light sensor
>     
>     Add support for Taos tsl2563 ambient light sensor.
>     
>     Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
>     
>     Updated to build with current linux-omap, new-style
>     i2c driver and cleaned up checkpatch.pl issues.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |    4 +
>  drivers/i2c/chips/Kconfig        |   10 +
>  drivers/i2c/chips/Makefile       |    2 +-
>  drivers/i2c/chips/tsl2563.c      |  731 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 746 insertions(+), 1 deletions(-)
> 
> commit 9416f0ccc9669a0588e16f776308f8f6c9e91661
> Author: Lauri Leukkunen <lauri.leukkunen@nokia.com>
> Date:   Mon Apr 7 19:57:43 2008 +0300
> 
>     INPUT: TOUCHSCREEN: Introduce tsc2005 driver
>     
>     Introduce n810's tsc2005 driver
>     
>     Signed-off-by: Lauri Leukkunen <lauri.leukkunen@nokia.com>
>     
>     Updated to build with current linux-omap.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c    |   95 +++++-
>  drivers/input/touchscreen/Kconfig   |    5 +
>  drivers/input/touchscreen/Makefile  |    1 +
>  drivers/input/touchscreen/tsc2005.c |  739 +++++++++++++++++++++++++++++++++++
>  include/linux/spi/tsc2005.h         |   29 ++
>  5 files changed, 865 insertions(+), 4 deletions(-)
> 
> commit 57871dcd31fa8598ae5d0d3e3979e5e6f5477ea4
> Author: Mathias Nyman <mathias.nyman@nokia.com>
> Date:   Tue Apr 8 13:33:04 2008 +0300
> 
>     I2C: LP5521: Introduce lp5521 LED driver
>     
>     Introduce n810's lp5521 LED driver.
>     
>     Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com
>     
>     Updated to new style i2c driver and to build on current
>     linux-omap head.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |    4 +
>  drivers/i2c/chips/Kconfig        |    7 +
>  drivers/i2c/chips/Makefile       |    1 +
>  drivers/i2c/chips/lp5521.c       |  577 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 589 insertions(+), 0 deletions(-)
> 
> commit 88573faf7d1e556376c0abb1adaf3497d814660b
> Author: Felipe Balbi <felipe.balbi@nokia.com>
> Date:   Tue Apr 8 15:36:32 2008 +0300
> 
>     ARM: N800: Update n800 defconfig
>     
>     Enables recent drivers and usb.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/configs/n800_defconfig |  189 +++++++++++++++++++++++++++++++++++++--
>  1 files changed, 182 insertions(+), 7 deletions(-)
> 
> -- 
> 	- Balbi

Pending patches

[Alan Stern]

James:

The patches below have been pending for quite a while:

	http://marc.info/?l=linux-scsi&m=122814525009429&w=2
	http://marc.info/?l=linux-scsi&m=122935526508941&w=2

I expected to see them already in 2.6.29-rc1.  They certainly should be 
merged sometime during the 2.6.29 time frame.

Alan Stern

Pending patches

[Alan Stern]

James:

Whatever happened to the 6-part patch series I submitted at the end of 
May?

0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2

Is there any reason they haven't gotten into scsi-misc for the next 
merge window?  It has been six weeks...

Alan Stern

Re: Pending patches

[James Bottomley]

On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> James:
> 
> Whatever happened to the 6-part patch series I submitted at the end of 
> May?
> 
> 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> 
> Is there any reason they haven't gotten into scsi-misc for the next 
> merge window?  It has been six weeks...

According to the thread, there's no confirmation from the reporter that
they actually fix the problem.

James

Re: Pending patches

[Alan Stern]

On Thu, 16 Jul 2009, James Bottomley wrote:

> On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> > James:
> > 
> > Whatever happened to the 6-part patch series I submitted at the end of 
> > May?
> > 
> > 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> > 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> > 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> > 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> > 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> > 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> > 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> > 
> > Is there any reason they haven't gotten into scsi-misc for the next 
> > merge window?  It has been six weeks...
> 
> According to the thread, there's no confirmation from the reporter that
> they actually fix the problem.

Please reconsider them not as specific bug fixes but rather as general
cleanups and improvements.  I.e., the sort of thing one would not send
to Linus until the next merge window.

Alan Stern

Re: Pending patches

[Alan Stern]

On Thu, 16 Jul 2009, Alan Stern wrote:

> On Thu, 16 Jul 2009, James Bottomley wrote:
> 
> > On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> > > James:
> > > 
> > > Whatever happened to the 6-part patch series I submitted at the end of 
> > > May?
> > > 
> > > 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> > > 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> > > 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> > > 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> > > 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> > > 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> > > 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> > > 
> > > Is there any reason they haven't gotten into scsi-misc for the next 
> > > merge window?  It has been six weeks...
> > 
> > According to the thread, there's no confirmation from the reporter that
> > they actually fix the problem.
> 
> Please reconsider them not as specific bug fixes but rather as general
> cleanups and improvements.  I.e., the sort of thing one would not send
> to Linus until the next merge window.

James, I haven't heard anything back about this.  It's very 
discouraging to submit serious patches only to have them ignored for 
two months.

Would it help if I rewrote the changelogs?  Is there anything else I 
can do to bring these into consideration?

Alan Stern

Pending patches

[Alan Stern]

James:

Have you had any time to review these three bug-fix patches?

	http://marc.info/?l=linux-scsi&m=126894117503693&w=2
	http://marc.info/?l=linux-scsi&m=126894127403891&w=2
	http://marc.info/?l=linux-scsi&m=126894128403918&w=2

Each one is quite short, and it should be easy to verify that they 
really do what they claim.

Alan Stern

Pending patches

[Robert Jarzmik]

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

Hi Sascha,

I have 2 sent patches which were somehow ... lost.
They have been sent on January the 26th, with the following subjects:
 - [PATCH] arm/mach-pxa: add standard LCD panel GPIO settings
 - [PATCH] arm/mach-pxa: add CCCR bits definitions

These are targeted at next branch. Could you consider pulling them ?
I joined them in this mail to ease your search.

Cheers.

-- 
Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-arm-mach-pxa-add-standard-LCD-panel-GPIO-settings.patch --]
[-- Type: text/x-diff, Size: 1630 bytes --]

From 2a3e758be559e34bffca8224b92e1d6f304ca5b8 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed, 25 Jan 2012 10:12:28 +0100
Subject: [PATCH 1/2] arm/mach-pxa: add standard LCD panel GPIO settings

Add standard GPIO routings for LCD panels, taken from linux
kernel.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/include/mach/mfp-pxa27x.h |   32 +++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
index 6543c05..f6a27a2 100644
--- a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
@@ -434,5 +434,37 @@
 #define GPIO112_nMSINS		MFP_CFG_IN(GPIO112, AF2)
 #define GPIO32_MSSCLK		MFP_CFG_OUT(GPIO32, AF1, DRIVE_LOW)
 
+/* commonly used pin configurations */
+#define GPIOxx_LCD_16BPP	\
+	GPIO58_LCD_LDD_0,	\
+	GPIO59_LCD_LDD_1,	\
+	GPIO60_LCD_LDD_2,	\
+	GPIO61_LCD_LDD_3,	\
+	GPIO62_LCD_LDD_4,	\
+	GPIO63_LCD_LDD_5,	\
+	GPIO64_LCD_LDD_6,	\
+	GPIO65_LCD_LDD_7,	\
+	GPIO66_LCD_LDD_8,	\
+	GPIO67_LCD_LDD_9,	\
+	GPIO68_LCD_LDD_10,	\
+	GPIO69_LCD_LDD_11,	\
+	GPIO70_LCD_LDD_12,	\
+	GPIO71_LCD_LDD_13,	\
+	GPIO72_LCD_LDD_14,	\
+	GPIO73_LCD_LDD_15
+
+#define GPIOxx_LCD_DSTN_16BPP	\
+	GPIOxx_LCD_16BPP,	\
+	GPIO74_LCD_FCLK,	\
+	GPIO75_LCD_LCLK,	\
+	GPIO76_LCD_PCLK
+
+#define GPIOxx_LCD_TFT_16BPP	\
+	GPIOxx_LCD_16BPP,	\
+	GPIO74_LCD_FCLK,	\
+	GPIO75_LCD_LCLK,	\
+	GPIO76_LCD_PCLK,	\
+	GPIO77_LCD_BIAS
+
 extern int keypad_set_wake(unsigned int on);
 #endif /* __ASM_ARCH_MFP_PXA27X_H */
-- 
1.7.5.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-arm-mach-pxa-add-CCCR-bits-definitions.patch --]
[-- Type: text/x-diff, Size: 1459 bytes --]

From f6f80c5430c279eddaee39929e2182b6f4b6ac90 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed, 25 Jan 2012 10:13:55 +0100
Subject: [PATCH 2/2] arm/mach-pxa: add CCCR bits definitions

Add CCCR bits definition for PXA SoC, so that the bootloader
can setup a stable core clock frequency, which is not the
initial reset clock, as required by Intel's PXA27x Processor
family developer's guide, chapter 3.5.5, table 3.7 (clock
frequencies).

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
index 4762d8a..b43648e 100644
--- a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
+++ b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
@@ -222,6 +222,11 @@
 #define CCCR_N_MASK	0x0380	/* Run Mode Frequency to Turbo Mode Frequency Multiplier */
 #define CCCR_M_MASK	0x0060	/* Memory Frequency to Run Mode Frequency Multiplier */
 #define CCCR_L_MASK	0x001f	/* Crystal Frequency to Memory Frequency Multiplier */
+#define CCCR_CPDIS	(1 << 31)
+#define CCCR_PPDIS	(1 << 30)
+#define CCCR_LCD26	(1 << 27)
+#define CCCR_PLL_EARLY	(1 << 26)
+#define CCCR_A		(1 << 25)
 
 #define CKEN_AC97CONF   (1 << 31)    /* AC97 Controller Configuration */
 #define CKEN_CAMERA	(1 << 24)	/* Camera Interface Clock Enable */
-- 
1.7.5.4


[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Pending patches

[Sascha Hauer]

Hi Robert,

On Tue, Feb 21, 2012 at 01:10:34PM +0100, Robert Jarzmik wrote:
> Hi Sascha,
> 
> I have 2 sent patches which were somehow ... lost.
> They have been sent on January the 26th, with the following subjects:
>  - [PATCH] arm/mach-pxa: add standard LCD panel GPIO settings
>  - [PATCH] arm/mach-pxa: add CCCR bits definitions
> 
> These are targeted at next branch. Could you consider pulling them ?
> I joined them in this mail to ease your search.

Yeah, I lost them. Applied now.

Thanks
 Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Pending patches

[Denys Dmytriyenko]

All,

I have not forgotten about the patches submitted last week. There are some 
critical issues I'm investigating right and will get to the patches as soon as 
possible. Thanks.

-- 
Denys

Pending patches

[Denys Dmytriyenko]

All,

Most of the patches submitted this week probably won't make it to 2016.02 
release, as the last RC was cut on Monday and we are trying to close it this 
week. So, I'll get back to pending patches as soon as release is out.

-- 
Denys

pending patches

[Vadim Pasternak]

Hi Pavel,

I have two pending patches:
https://patches.linaro.org/patch/432324/ from 2021-05-07
https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been re-sent.

Could these patches be accepted?

Thanks,
Vadim.

Re: pending patches

[Pavel Machek]

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

Hi!

> I have two pending patches:
> https://patches.linaro.org/patch/432324/ from 2021-05-07

I don't understand this one. Are these normal single-color LEDs, or is
it some kind of weird red/orange/amber/green combination exposed as
single LED?

> https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been re-sent.

In this case, I don't think i2c bus number is suitable way to identify
add-on card. Having some way of identifying add-on cards makes sense
(as we'll probably have other vendors having "fault" or "activity"
light on their cards), but those boards will not neccessarily have i2c
on them.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

RE: pending patches

[Vadim Pasternak]

> -----Original Message-----
> From: Pavel Machek <pavel@ucw.cz>
> Sent: Friday, August 20, 2021 11:07 AM
> To: Vadim Pasternak <vadimp@nvidia.com>
> Cc: linux-leds@vger.kernel.org
> Subject: Re: pending patches
> 
> Hi!
> 
> > I have two pending patches:
> > https://patches.linaro.org/patch/432324/ from 2021-05-07
> 
> I don't understand this one. Are these normal single-color LEDs, or is it some
> kind of weird red/orange/amber/green combination exposed as single LED?

This is not single-color LED. LED is controlled by programmable device, color is
set by writing relevant bit mask combination to the related LED register.

> 
> > https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been
> re-sent.
> 
> In this case, I don't think i2c bus number is suitable way to identify add-on
> card. Having some way of identifying add-on cards makes sense (as we'll
> probably have other vendors having "fault" or "activity"
> light on their cards), but those boards will not neccessarily have i2c on them.

Line card always has I2C connection, LED color is controlled through a programmable
device, which is always I2C device. So, this is I2C and bus number identifies topology.

Pavel,
I have those patches pending very long time. Could you, please, help to get them
accepted?

Thanks,
Vadim.


> 
> Best regards,
> 								Pavel
> --
> http://www.livejournal.com/~pavelmachek

Re: pending patches

[Pavel Machek]

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

Hi!

> > > I have two pending patches:
> > > https://patches.linaro.org/patch/432324/ from 2021-05-07
> > 
> > I don't understand this one. Are these normal single-color LEDs, or is it some
> > kind of weird red/orange/amber/green combination exposed as single LED?
> 
> This is not single-color LED. LED is controlled by programmable device, color is
> set by writing relevant bit mask combination to the related LED register.

Not a single-color LED yet using single-color API, and now you are
introducing additional hacks on the top of it. Sorry, no.

> > > https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been
> > re-sent.
> > 
> > In this case, I don't think i2c bus number is suitable way to identify add-on
> > card. Having some way of identifying add-on cards makes sense (as we'll
> > probably have other vendors having "fault" or "activity"
> > light on their cards), but those boards will not neccessarily have i2c on them.
> 
> Line card always has I2C connection, LED color is controlled through a programmable
> device, which is always I2C device. So, this is I2C and bus number identifies topology.

I see it works for your hardware. I don't believe it works for other
vendors having "activity" LED on their card, and I'd like to see
consistent naming across vendors.

> Pavel,
> I have those patches pending very long time. Could you, please, help to get them
> accepted?

Not really, sorry.

Best regards,
									Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

RE: pending patches

[Vadim Pasternak]

> -----Original Message-----
> From: Pavel Machek <pavel@ucw.cz>
> Sent: Sunday, September 12, 2021 10:11 AM
> To: Vadim Pasternak <vadimp@nvidia.com>
> Cc: linux-leds@vger.kernel.org
> Subject: Re: pending patches
> 
> Hi!
> 
> > > > I have two pending patches:
> > > > https://patches.linaro.org/patch/432324/ from 2021-05-07
> > >
> > > I don't understand this one. Are these normal single-color LEDs, or
> > > is it some kind of weird red/orange/amber/green combination exposed
> as single LED?
> >
> > This is not single-color LED. LED is controlled by programmable
> > device, color is set by writing relevant bit mask combination to the related
> LED register.
> 
> Not a single-color LED yet using single-color API, and now you are introducing
> additional hacks on the top of it. Sorry, no.

Could you explain your point, please?
Where is the hack? API is used on top of specific hardware by setting bitmask, while
generic API is used.

> 
> > > > https://patches.linaro.org/patch/403538/ from 2021-03-16, which
> > > > has been
> > > re-sent.
> > >
> > > In this case, I don't think i2c bus number is suitable way to
> > > identify add-on card. Having some way of identifying add-on cards
> > > makes sense (as we'll probably have other vendors having "fault" or
> "activity"
> > > light on their cards), but those boards will not neccessarily have i2c on
> them.
> >
> > Line card always has I2C connection, LED color is controlled through a
> > programmable device, which is always I2C device. So, this is I2C and bus
> number identifies topology.
> 
> I see it works for your hardware. I don't believe it works for other vendors
> having "activity" LED on their card, and I'd like to see consistent naming
> across vendors.

Name is constructed like:
/sys/class/leds/<card type><bus>:status:green/
In same way it will work for other vendors. 

> 
> > Pavel,
> > I have those patches pending very long time. Could you, please, help
> > to get them accepted?
> 
> Not really, sorry.
> 
> Best regards,
> 									Pavel
> --
> http://www.livejournal.com/~pavelmachek