Colin Ian King | 1 Sep 09:12 2008

[Hardy LUM] SRU request for LP#157919

https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/157919

SRU justification:

Impact: The appleir driver does not work with the most recent MacBook
Pro because the device now has a new ID 0x8242.

Fix: Add new device ID in appleir_ids[]. Also add in appropriate key
response codes for this device.

Testcase: Without the patch, appleir driver on newer MacBook Pros do not
detect this device. With the patch, the device is detected.

Patch tested and confirmed by user:
https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/157919/comments/14
https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/157919

SRU justification:

Impact: The appleir driver does not work with the most recent MacBook
Pro because the device now has a new ID 0x8242.

Fix: Add new device ID in appleir_ids[]. Also add in appropriate key
response codes for this device.

Testcase: Without the patch, appleir driver on newer MacBook Pros do not
detect this device. With the patch, the device is detected.
(Continue reading)

Tim Gardner | 1 Sep 15:55 2008

Re: [Hardy-LUM][Intrepid] SRU request for LP#25896

Stefan Bader wrote:
> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/25896
> 
> Added to Intrepid HEAD as SAUCE patch. Needs to be done for 2.6.26 (which branch?)
> 
> SRU justification:
> 
> Impact: Correct chipset model is not selected for hda sound driver. Sound does
> not work after resume.
> 
> Fix: Update the quirks table to select the correct chipset for a given computer
> model.
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=f4c9e59860fd5efbfb077aca95445000fe51ba5d
> 
> Testcase: See bug report.
> 

ACK
--

-- 
Tim Gardner tim.gardner <at> ubuntu.com

Tim Gardner | 1 Sep 16:05 2008

Re: [Hardy LUM] SRU request for LP#157919

Colin Ian King wrote:
> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/157919
> 
> SRU justification:
> 
> Impact: The appleir driver does not work with the most recent MacBook
> Pro because the device now has a new ID 0x8242.
> 
> Fix: Add new device ID in appleir_ids[]. Also add in appropriate key
> response codes for this device.
> 
> Testcase: Without the patch, appleir driver on newer MacBook Pros do not
> detect this device. With the patch, the device is detected.
> 
> Patch tested and confirmed by user:
> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/157919/comments/14
> 

ACK
--

-- 
Tim Gardner tim.gardner <at> ubuntu.com

Henrik Rydberg | 1 Sep 17:47 2008
Picon

[PATCH] Intrepid: Mouse pointer frozen by default on bcm5974-based macbooks (#263451)

Starting up the CD on a Macbook Air or Macbook Pro Penryn, both of
which use the bcm5974 trackpad driver, the mouse pointer is initially
frozen. The reason is that the bcm5974 driver only mimics a synaptics
touchpad, not a mouse. After configuring the synaptics driver
everything is fine, but the default behavior is simply not going to
work well for first time users.  This patch upgrades Intrepid to
bcm5974-0.6, which by default operates as a regular mouse.

Bug: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/263451

Signed-off-by: Henrik Rydberg <rydberg <at> euromail.se>
---
 drivers/input/mouse/bcm5974.c |  230 ++++++++++++++++++++++++++++++++++-------
 1 files changed, 193 insertions(+), 37 deletions(-)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 2ec921b..adc7102 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
 <at>  <at>  -63,7 +63,7  <at>  <at> 
 }

 /* table of devices that work with this driver */
-static const struct usb_device_id bcm5974_table [] = {
+static const struct usb_device_id bcm5974_table[] = {
 	/* MacbookAir1.1 */
 	BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
 	BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING_ISO),
 <at>  <at>  -84,10 +84,33  <at>  <at>  MODULE_LICENSE("GPL");
 #define dprintk(level, format, a...)\
(Continue reading)

Cory K. | 1 Sep 18:39 2008

Ubuntu Studio, -rt and 2.6.27

Please excuse me if I can't speak with as much technical aptitude as I
would like. I'm simply trying to stimulate conversation.

Ok. There have been a couple of reasons why the -rt kernel has had
issues this cycle.

    * Alessio has had to fight upstream for support of .26.
    * This work has landed late in the cycle.
    * Alession has had personal issues.
    * There has been a perceived lack of help from the kernel team to
      deal with how the kernels are done now. (I cite no response to
      this thread:
      https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)
    * We have now moved to 2.6.27
    * The kernels are managed different in this cycle.

I am not at all saying this the kernel teams fault. This is an
unfortunate combination of events. There was also no response to this:
https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026184.html I
think, in part, because Alessio can't provide a patch against .27.
(Again, not the kernel teams fault)

So, atm, it *looks* like our only option is to base off of 2.6.26. We
have a kernel in Universe now (though the source was recently NBS'ed)
but lrm/lum/drivers and such are looking to be issues.

I'll let Alessio chime in but I'm opening this up to the wider kernel
community for options/opinions.

How has -zen dealt with this for instance?
(Continue reading)

Henrik Rydberg | 1 Sep 19:14 2008
Picon

[PATCH] applesmc: DMI reordering to properly match the Macbook Air (MBA)

The DMI matching algorithm in applesmc requires the most detailed product identifier to be
listed first. The current list violates this rule for the MBA, in effect being matched to
the regular Macbook. This patch moves the MBA to the appropriate place.

Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/248238

Signed-off-by: Henrik Rydberg <rydberg <at> euromail.se>
---
 drivers/hwmon/applesmc.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 6a94e5a..1a7ecfe 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
 <at>  <at>  -1242,6 +1242,10  <at>  <at>  static __initdata struct dmi_match_data applesmc_dmi_data[] = {
 /* Note that DMI_MATCH(...,"MacBook") will match "MacBookPro1,1".
  * So we need to put "Apple MacBook Pro" before "Apple MacBook". */
 static __initdata struct dmi_system_id applesmc_whitelist[] = {
+	{ applesmc_dmi_match, "Apple MacBook Air", {
+	  DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
+	  DMI_MATCH(DMI_PRODUCT_NAME,"MacBookAir") },
+		(void*)&applesmc_dmi_data[7]},
 	{ applesmc_dmi_match, "Apple MacBook Pro", {
 	  DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
 	  DMI_MATCH(DMI_PRODUCT_NAME,"MacBookPro") },
 <at>  <at>  -1270,10 +1274,6  <at>  <at>  static __initdata struct dmi_system_id applesmc_whitelist[] = {
 	  DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
 	  DMI_MATCH(DMI_PRODUCT_NAME,"iMac") },
 		(void*)&applesmc_dmi_data[5]},
(Continue reading)

Cory K. | 2 Sep 01:58 2008

Re: Ubuntu Studio, -rt and 2.6.27

Cory K. wrote:
> Please excuse me if I can't speak with as much technical aptitude as I
> would like. I'm simply trying to stimulate conversation.
>
> Ok. There have been a couple of reasons why the -rt kernel has had
> issues this cycle.
>
>     * Alessio has had to fight upstream for support of .26.
>     * This work has landed late in the cycle.
>     * Alession has had personal issues.
>     * There has been a perceived lack of help from the kernel team to
>       deal with how the kernels are done now. (I cite no response to
>       this thread:
>       https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)
>     * We have now moved to 2.6.27
>     * The kernels are managed different in this cycle.
>
> I am not at all saying this the kernel teams fault. This is an
> unfortunate combination of events. There was also no response to this:
> https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026184.html I
> think, in part, because Alessio can't provide a patch against .27.
> (Again, not the kernel teams fault)
>
> So, atm, it *looks* like our only option is to base off of 2.6.26. We
> have a kernel in Universe now (though the source was recently NBS'ed)
> but lrm/lum/drivers and such are looking to be issues.
>
> I'll let Alessio chime in but I'm opening this up to the wider kernel
> community for options/opinions.
>
(Continue reading)

Huaxu Wan | 2 Sep 07:38 2008
Picon

[Pull request] iwl5000 driver for Shirley Peak

The following changes since commit b3902ba575f728086e909e1c345a9d6bfbe754ed:
  Tim Gardner (1):
        UBUNTU: Ubuntu-2.6.24-21.31

are available in the git repository at:

  git://kernel.ubuntu.com/hwan/hardy-lum/ master

Huaxu Wan (3):
      UBUNTU: iwl5000-2.3.3.3
      UBUNTU: iwl5000-2.3.5
      UBUNTU: Disable the support for iwl4965/3945

 ubuntu-firmware/iwlwifi/iwlwifi-4965-2.ucode       |  Bin 0 -> 187672 bytes
 ubuntu/wireless/iwlwifi/1.2.0.update.patch         |  156 -
 ubuntu/wireless/iwlwifi/BOM                        |   55 -
 ubuntu/wireless/iwlwifi/MUNGE                      |  146 +-
 ubuntu/wireless/iwlwifi/Makefile                   |    2 -
 .../iwlwifi/drivers/net/wireless/iwlwifi/Makefile  |   20 +
 .../net/wireless/iwlwifi/iwl-3945-commands.h       | 1696 ++++
 .../drivers/net/wireless/iwlwifi/iwl-3945-core.h   |   80 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-debug.h  |  167 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-hw.h     |  488 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-io.h     |  426 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-led.c    |  434 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-led.h    |   73 +
 .../drivers/net/wireless/iwlwifi/iwl-3945-rs.c     |  988 ++
 .../drivers/net/wireless/iwlwifi/iwl-3945-rs.h     |  215 +
 .../drivers/net/wireless/iwlwifi/iwl-3945.c        | 2666 ++++++
 .../drivers/net/wireless/iwlwifi/iwl-3945.h        |  981 ++
(Continue reading)

Ben Collins | 2 Sep 18:42 2008

Re: Ubuntu Studio, -rt and 2.6.27

Cory K. wrote:
> Please excuse me if I can't speak with as much technical aptitude as I
> would like. I'm simply trying to stimulate conversation.
> 
> Ok. There have been a couple of reasons why the -rt kernel has had
> issues this cycle.
> 
>     * Alessio has had to fight upstream for support of .26.
>     * This work has landed late in the cycle.
>     * Alession has had personal issues.
>     * There has been a perceived lack of help from the kernel team to
>       deal with how the kernels are done now. (I cite no response to
>       this thread:
>       https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)

I believe I had told you or Alessio that lrm was moving to dkms, which 
means it wouldn't be necessary. Lrm should not be considered a blocker 
for -rt, since the drivers in it are, for the most part, supported in 
stock kernel anyway. Nvidia and fglrx are separately packaged using dkms.

>     * We have now moved to 2.6.27

Irrelevant. The -rt kernel was delayed well before we made this move. 
This may delay it further, but it in no part brought -rt to the issues 
it is trying to resolve right now.

>     * The kernels are managed different in this cycle.

I had stated to you and Alessio that if he were to provide a patch, I 
would help with the packaging end of it. That was never done.
(Continue reading)

Cory K. | 2 Sep 18:59 2008

Re: Ubuntu Studio, -rt and 2.6.27

Ben Collins wrote:
> Cory K. wrote:
>> Please excuse me if I can't speak with as much technical aptitude as I
>> would like. I'm simply trying to stimulate conversation.
>>
>> Ok. There have been a couple of reasons why the -rt kernel has had
>> issues this cycle.
>>
>>     * Alessio has had to fight upstream for support of .26.
>>     * This work has landed late in the cycle.
>>     * Alession has had personal issues.
>>     * There has been a perceived lack of help from the kernel team to
>>       deal with how the kernels are done now. (I cite no response to
>>       this thread:
>>      
>> https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)
>
> I believe I had told you or Alessio that lrm was moving to dkms, which
> means it wouldn't be necessary. Lrm should not be considered a blocker
> for -rt, since the drivers in it are, for the most part, supported in
> stock kernel anyway. Nvidia and fglrx are separately packaged using dkms.

Sure. From what I can tell he isn't understanding the new interaction
with DKMS atm.

>>     * We have now moved to 2.6.27
>
> Irrelevant. The -rt kernel was delayed well before we made this move.
> This may delay it further, but it in no part brought -rt to the issues
> it is trying to resolve right now.
(Continue reading)


Gmane