--- /dev/null
+From eaae55dac6b64c0616046436b294e69fc5311581 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 14 Feb 2011 22:45:59 +0100
+Subject: ALSA: caiaq - Fix possible string-buffer overflow
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit eaae55dac6b64c0616046436b294e69fc5311581 upstream.
+
+Use strlcpy() to assure not to overflow the string array sizes by
+too long USB device name string.
+
+Reported-by: Rafa <rafa@mwrinfosecurity.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/usb/caiaq/audio.c | 2 +-
+ sound/usb/caiaq/midi.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/caiaq/audio.c
++++ b/sound/usb/caiaq/audio.c
+@@ -785,7 +785,7 @@ int snd_usb_caiaq_audio_init(struct snd_
+ }
+
+ dev->pcm->private_data = dev;
+- strcpy(dev->pcm->name, dev->product_name);
++ strlcpy(dev->pcm->name, dev->product_name, sizeof(dev->pcm->name));
+
+ memset(dev->sub_playback, 0, sizeof(dev->sub_playback));
+ memset(dev->sub_capture, 0, sizeof(dev->sub_capture));
+--- a/sound/usb/caiaq/midi.c
++++ b/sound/usb/caiaq/midi.c
+@@ -136,7 +136,7 @@ int snd_usb_caiaq_midi_init(struct snd_u
+ if (ret < 0)
+ return ret;
+
+- strcpy(rmidi->name, device->product_name);
++ strlcpy(rmidi->name, device->product_name, sizeof(rmidi->name));
+
+ rmidi->info_flags = SNDRV_RAWMIDI_INFO_DUPLEX;
+ rmidi->private_data = device;
--- /dev/null
+From b540afc2b3d6e4cd1d1f137ef6d9e9c78d67fecd Mon Sep 17 00:00:00 2001
+From: David Henningsson <david.henningsson@canonical.com>
+Date: Mon, 14 Feb 2011 20:27:44 +0100
+Subject: ALSA: HDA: Add position_fix quirk for an Asus device
+
+From: David Henningsson <david.henningsson@canonical.com>
+
+commit b540afc2b3d6e4cd1d1f137ef6d9e9c78d67fecd upstream.
+
+The bug reporter claims that position_fix=1 is needed for his
+microphone to work. The controller PCI vendor-id is [1002:4383] (rev 40).
+
+Reported-by: Kjell L.
+BugLink: http://bugs.launchpad.net/bugs/718402
+Signed-off-by: David Henningsson <david.henningsson@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ sound/pci/hda/hda_intel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -2305,6 +2305,7 @@ static struct snd_pci_quirk position_fix
+ SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
++ SND_PCI_QUIRK(0x1043, 0x8410, "ASUS", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1106, 0x3288, "ASUS M2V-MX SE", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba A100-259", POS_FIX_LPIB),
--- /dev/null
+From 89724958e5d596bb91328644c97dd80399443e87 Mon Sep 17 00:00:00 2001
+From: David Henningsson <david.henningsson@canonical.com>
+Date: Wed, 16 Feb 2011 21:34:04 +0100
+Subject: ALSA: HDA: Do not announce false surround in Conexant auto
+
+From: David Henningsson <david.henningsson@canonical.com>
+
+commit 89724958e5d596bb91328644c97dd80399443e87 upstream.
+
+Without this patch, one line-out and one speaker and
+Conexant's auto parser would announce (non-working) surround
+capabilities.
+
+BugLink: http://bugs.launchpad.net/bugs/721126
+Signed-off-by: David Henningsson <david.henningsson@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/hda/patch_conexant.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -3401,7 +3401,7 @@ static void cx_auto_parse_output(struct
+ }
+ }
+ spec->multiout.dac_nids = spec->private_dac_nids;
+- spec->multiout.max_channels = nums * 2;
++ spec->multiout.max_channels = spec->multiout.num_dacs * 2;
+
+ if (cfg->hp_outs > 0)
+ spec->auto_mute = 1;
--- /dev/null
+From 2c6315da6a1657a49e03970a4084dc3d1958ad70 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Wed, 16 Feb 2011 08:02:38 -0500
+Subject: hwmon: (jc42) do not allow writing to locked registers
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit 2c6315da6a1657a49e03970a4084dc3d1958ad70 upstream.
+
+On systems where the temperature sensor is actually used, the BIOS is
+likely to have locked the alarm registers. In that case, all writes
+through the corresponding sysfs files would be silently ignored.
+
+To prevent this, detect the locks and make the affected sysfs files
+read-only.
+
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ Documentation/hwmon/jc42 | 12 ++++++++----
+ drivers/hwmon/jc42.c | 33 +++++++++++++++++++++++++++++----
+ 2 files changed, 37 insertions(+), 8 deletions(-)
+
+--- a/Documentation/hwmon/jc42
++++ b/Documentation/hwmon/jc42
+@@ -86,15 +86,19 @@ limits. The chip supports only a single
+ which applies to all limits. This register can be written by writing into
+ temp1_crit_hyst. Other hysteresis attributes are read-only.
+
++If the BIOS has configured the sensor for automatic temperature management, it
++is likely that it has locked the registers, i.e., that the temperature limits
++cannot be changed.
++
+ Sysfs entries
+ -------------
+
+ temp1_input Temperature (RO)
+-temp1_min Minimum temperature (RW)
+-temp1_max Maximum temperature (RW)
+-temp1_crit Critical high temperature (RW)
++temp1_min Minimum temperature (RO or RW)
++temp1_max Maximum temperature (RO or RW)
++temp1_crit Critical high temperature (RO or RW)
+
+-temp1_crit_hyst Critical hysteresis temperature (RW)
++temp1_crit_hyst Critical hysteresis temperature (RO or RW)
+ temp1_max_hyst Maximum hysteresis temperature (RO)
+
+ temp1_min_alarm Temperature low alarm
+--- a/drivers/hwmon/jc42.c
++++ b/drivers/hwmon/jc42.c
+@@ -53,6 +53,8 @@ static const unsigned short normal_i2c[]
+
+ /* Configuration register defines */
+ #define JC42_CFG_CRIT_ONLY (1 << 2)
++#define JC42_CFG_TCRIT_LOCK (1 << 6)
++#define JC42_CFG_EVENT_LOCK (1 << 7)
+ #define JC42_CFG_SHUTDOWN (1 << 8)
+ #define JC42_CFG_HYST_SHIFT 9
+ #define JC42_CFG_HYST_MASK 0x03
+@@ -380,14 +382,14 @@ static ssize_t show_alarm(struct device
+
+ static DEVICE_ATTR(temp1_input, S_IRUGO,
+ show_temp_input, NULL);
+-static DEVICE_ATTR(temp1_crit, S_IWUSR | S_IRUGO,
++static DEVICE_ATTR(temp1_crit, S_IRUGO,
+ show_temp_crit, set_temp_crit);
+-static DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO,
++static DEVICE_ATTR(temp1_min, S_IRUGO,
+ show_temp_min, set_temp_min);
+-static DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO,
++static DEVICE_ATTR(temp1_max, S_IRUGO,
+ show_temp_max, set_temp_max);
+
+-static DEVICE_ATTR(temp1_crit_hyst, S_IWUSR | S_IRUGO,
++static DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
+ show_temp_crit_hyst, set_temp_crit_hyst);
+ static DEVICE_ATTR(temp1_max_hyst, S_IRUGO,
+ show_temp_max_hyst, NULL);
+@@ -412,8 +414,31 @@ static struct attribute *jc42_attributes
+ NULL
+ };
+
++static mode_t jc42_attribute_mode(struct kobject *kobj,
++ struct attribute *attr, int index)
++{
++ struct device *dev = container_of(kobj, struct device, kobj);
++ struct i2c_client *client = to_i2c_client(dev);
++ struct jc42_data *data = i2c_get_clientdata(client);
++ unsigned int config = data->config;
++ bool readonly;
++
++ if (attr == &dev_attr_temp1_crit.attr)
++ readonly = config & JC42_CFG_TCRIT_LOCK;
++ else if (attr == &dev_attr_temp1_min.attr ||
++ attr == &dev_attr_temp1_max.attr)
++ readonly = config & JC42_CFG_EVENT_LOCK;
++ else if (attr == &dev_attr_temp1_crit_hyst.attr)
++ readonly = config & (JC42_CFG_EVENT_LOCK | JC42_CFG_TCRIT_LOCK);
++ else
++ readonly = true;
++
++ return S_IRUGO | (readonly ? 0 : S_IWUSR);
++}
++
+ static const struct attribute_group jc42_group = {
+ .attrs = jc42_attributes,
++ .is_visible = jc42_attribute_mode,
+ };
+
+ /* Return 0 if detection is successful, -ENODEV otherwise */
--- /dev/null
+From e866729605a43a739fc56023a8530b07a93d3458 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Wed, 16 Feb 2011 08:01:49 -0500
+Subject: hwmon: (jc42) fix type mismatch
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit e866729605a43a739fc56023a8530b07a93d3458 upstream.
+
+In set_temp_crit_hyst(), make the variable 'val' have the correct
+type for strict_strtoul().
+
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ drivers/hwmon/jc42.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwmon/jc42.c
++++ b/drivers/hwmon/jc42.c
+@@ -332,7 +332,7 @@ static ssize_t set_temp_crit_hyst(struct
+ {
+ struct i2c_client *client = to_i2c_client(dev);
+ struct jc42_data *data = i2c_get_clientdata(client);
+- long val;
++ unsigned long val;
+ int diff, hyst;
+ int err;
+ int ret = count;
--- /dev/null
+From d5622f5b6c4671d1588ccc9056705366d4eb312a Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Wed, 16 Feb 2011 08:02:08 -0500
+Subject: hwmon: (jc42) more helpful documentation
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit d5622f5b6c4671d1588ccc9056705366d4eb312a upstream.
+
+The documentation lists standard numbers and chip names in excruciating
+detail, but that's all it does. To help mere mortals in deciding
+whether to enable this driver, mention what this sensor is for and in
+which systems it might be found.
+
+Also add a link to the actual JC 42.4 specification.
+
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ Documentation/hwmon/jc42 | 9 +++++++--
+ drivers/hwmon/Kconfig | 11 ++++++-----
+ 2 files changed, 13 insertions(+), 7 deletions(-)
+
+--- a/Documentation/hwmon/jc42
++++ b/Documentation/hwmon/jc42
+@@ -51,7 +51,8 @@ Supported chips:
+ * JEDEC JC 42.4 compliant temperature sensor chips
+ Prefix: 'jc42'
+ Addresses scanned: I2C 0x18 - 0x1f
+- Datasheet: -
++ Datasheet:
++ http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
+
+ Author:
+ Guenter Roeck <guenter.roeck@ericsson.com>
+@@ -60,7 +61,11 @@ Author:
+ Description
+ -----------
+
+-This driver implements support for JEDEC JC 42.4 compliant temperature sensors.
++This driver implements support for JEDEC JC 42.4 compliant temperature sensors,
++which are used on many DDR3 memory modules for mobile devices and servers. Some
++systems use the sensor to prevent memory overheating by automatically throttling
++the memory controller.
++
+ The driver auto-detects the chips listed above, but can be manually instantiated
+ to support other JC 42.4 compliant chips.
+
+--- a/drivers/hwmon/Kconfig
++++ b/drivers/hwmon/Kconfig
+@@ -445,13 +445,14 @@ config SENSORS_JZ4740
+ called jz4740-hwmon.
+
+ config SENSORS_JC42
+- tristate "JEDEC JC42.4 compliant temperature sensors"
++ tristate "JEDEC JC42.4 compliant memory module temperature sensors"
+ depends on I2C
+ help
+- If you say yes here you get support for Jedec JC42.4 compliant
+- temperature sensors. Support will include, but not be limited to,
+- ADT7408, CAT34TS02,, CAT6095, MAX6604, MCP9805, MCP98242, MCP98243,
+- MCP9843, SE97, SE98, STTS424, TSE2002B3, and TS3000B3.
++ If you say yes here, you get support for JEDEC JC42.4 compliant
++ temperature sensors, which are used on many DDR3 memory modules for
++ mobile devices and servers. Support will include, but not be limited
++ to, ADT7408, CAT34TS02, CAT6095, MAX6604, MCP9805, MCP98242, MCP98243,
++ MCP9843, SE97, SE98, STTS424(E), TSE2002B3, and TS3000B3.
+
+ This driver can also be built as a module. If so, the module
+ will be called jc42.
--- /dev/null
+From aa4790a6287818078ca968164a5f0d0870326602 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Thu, 17 Feb 2011 03:22:40 -0500
+Subject: hwmon: (k10temp) add support for AMD Family 12h/14h CPUs
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit aa4790a6287818078ca968164a5f0d0870326602 upstream.
+
+Add the PCI ID to support the internal temperature sensor of the
+AMD "Llano" and "Brazos" processor families.
+
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ Documentation/hwmon/k10temp | 8 +++++++-
+ drivers/hwmon/Kconfig | 6 +++---
+ drivers/hwmon/k10temp.c | 5 +++--
+ 3 files changed, 13 insertions(+), 6 deletions(-)
+
+--- a/Documentation/hwmon/k10temp
++++ b/Documentation/hwmon/k10temp
+@@ -9,6 +9,8 @@ Supported chips:
+ Socket S1G3: Athlon II, Sempron, Turion II
+ * AMD Family 11h processors:
+ Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
++* AMD Family 12h processors: "Llano"
++* AMD Family 14h processors: "Brazos" (C/E/G-Series)
+
+ Prefix: 'k10temp'
+ Addresses scanned: PCI space
+@@ -17,10 +19,14 @@ Supported chips:
+ http://support.amd.com/us/Processor_TechDocs/31116.pdf
+ BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors:
+ http://support.amd.com/us/Processor_TechDocs/41256.pdf
++ BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors:
++ http://support.amd.com/us/Processor_TechDocs/43170.pdf
+ Revision Guide for AMD Family 10h Processors:
+ http://support.amd.com/us/Processor_TechDocs/41322.pdf
+ Revision Guide for AMD Family 11h Processors:
+ http://support.amd.com/us/Processor_TechDocs/41788.pdf
++ Revision Guide for AMD Family 14h Models 00h-0Fh Processors:
++ http://support.amd.com/us/Processor_TechDocs/47534.pdf
+ AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks:
+ http://support.amd.com/us/Processor_TechDocs/43373.pdf
+ AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet:
+@@ -34,7 +40,7 @@ Description
+ -----------
+
+ This driver permits reading of the internal temperature sensor of AMD
+-Family 10h and 11h processors.
++Family 10h/11h/12h/14h processors.
+
+ All these processors have a sensor, but on those for Socket F or AM2+,
+ the sensor may return inconsistent values (erratum 319). The driver
+--- a/drivers/hwmon/Kconfig
++++ b/drivers/hwmon/Kconfig
+@@ -238,13 +238,13 @@ config SENSORS_K8TEMP
+ will be called k8temp.
+
+ config SENSORS_K10TEMP
+- tristate "AMD Phenom/Sempron/Turion/Opteron temperature sensor"
++ tristate "AMD Family 10h/11h/12h/14h temperature sensor"
+ depends on X86 && PCI
+ help
+ If you say yes here you get support for the temperature
+ sensor(s) inside your CPU. Supported are later revisions of
+- the AMD Family 10h and all revisions of the AMD Family 11h
+- microarchitectures.
++ the AMD Family 10h and all revisions of the AMD Family 11h,
++ 12h (Llano), and 14h (Brazos) microarchitectures.
+
+ This driver can also be built as a module. If so, the module
+ will be called k10temp.
+--- a/drivers/hwmon/k10temp.c
++++ b/drivers/hwmon/k10temp.c
+@@ -1,5 +1,5 @@
+ /*
+- * k10temp.c - AMD Family 10h/11h processor hardware monitoring
++ * k10temp.c - AMD Family 10h/11h/12h/14h processor hardware monitoring
+ *
+ * Copyright (c) 2009 Clemens Ladisch <clemens@ladisch.de>
+ *
+@@ -25,7 +25,7 @@
+ #include <linux/pci.h>
+ #include <asm/processor.h>
+
+-MODULE_DESCRIPTION("AMD Family 10h/11h CPU core temperature monitor");
++MODULE_DESCRIPTION("AMD Family 10h/11h/12h/14h CPU core temperature monitor");
+ MODULE_AUTHOR("Clemens Ladisch <clemens@ladisch.de>");
+ MODULE_LICENSE("GPL");
+
+@@ -208,6 +208,7 @@ static void __devexit k10temp_remove(str
+ static const struct pci_device_id k10temp_id_table[] = {
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_11H_NB_MISC) },
++ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
+ {}
+ };
+ MODULE_DEVICE_TABLE(pci, k10temp_id_table);
--- /dev/null
+From f065a93e168299569078bc6f52128b57f602fff3 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <JBeulich@novell.com>
+Date: Fri, 18 Feb 2011 03:18:26 -0500
+Subject: hwmon: (lm85) extend to support EMC6D103 chips
+
+From: Jan Beulich <JBeulich@novell.com>
+
+commit f065a93e168299569078bc6f52128b57f602fff3 upstream.
+
+The interface is identical EMC6D102, so all that needs to be added are
+some definitions and their uses.
+
+Registers apparently missing in EMC6D103S/EMC6D103:A2 compared to EMC6D103:A0,
+EMC6D103:A1, and EMC6D102 (according to the data sheets), but used
+unconditionally in the driver: 62[5:7], 6D[0:7], and 6E[0:7]. For that
+reason, EMC6D103S chips don't get enabled for the time being.
+
+Signed-off-by: Jan Beulich <jbeulich@novell.com>
+(Guenter Roeck: Replaced EMC6D103_A2 with EMC6D103S per EMC6D103S datasheet)
+Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/hwmon/Kconfig | 2 +-
+ drivers/hwmon/lm85.c | 23 +++++++++++++++++++++--
+ 2 files changed, 22 insertions(+), 3 deletions(-)
+
+--- a/drivers/hwmon/Kconfig
++++ b/drivers/hwmon/Kconfig
+@@ -564,7 +564,7 @@ config SENSORS_LM85
+ help
+ If you say yes here you get support for National Semiconductor LM85
+ sensor chips and clones: ADM1027, ADT7463, ADT7468, EMC6D100,
+- EMC6D101 and EMC6D102.
++ EMC6D101, EMC6D102, and EMC6D103.
+
+ This driver can also be built as a module. If so, the module
+ will be called lm85.
+--- a/drivers/hwmon/lm85.c
++++ b/drivers/hwmon/lm85.c
+@@ -41,7 +41,7 @@ static const unsigned short normal_i2c[]
+ enum chips {
+ any_chip, lm85b, lm85c,
+ adm1027, adt7463, adt7468,
+- emc6d100, emc6d102
++ emc6d100, emc6d102, emc6d103
+ };
+
+ /* The LM85 registers */
+@@ -90,6 +90,9 @@ enum chips {
+ #define LM85_VERSTEP_EMC6D100_A0 0x60
+ #define LM85_VERSTEP_EMC6D100_A1 0x61
+ #define LM85_VERSTEP_EMC6D102 0x65
++#define LM85_VERSTEP_EMC6D103_A0 0x68
++#define LM85_VERSTEP_EMC6D103_A1 0x69
++#define LM85_VERSTEP_EMC6D103S 0x6A /* Also known as EMC6D103:A2 */
+
+ #define LM85_REG_CONFIG 0x40
+
+@@ -348,6 +351,7 @@ static const struct i2c_device_id lm85_i
+ { "emc6d100", emc6d100 },
+ { "emc6d101", emc6d100 },
+ { "emc6d102", emc6d102 },
++ { "emc6d103", emc6d103 },
+ { }
+ };
+ MODULE_DEVICE_TABLE(i2c, lm85_id);
+@@ -1250,6 +1254,20 @@ static int lm85_detect(struct i2c_client
+ case LM85_VERSTEP_EMC6D102:
+ type_name = "emc6d102";
+ break;
++ case LM85_VERSTEP_EMC6D103_A0:
++ case LM85_VERSTEP_EMC6D103_A1:
++ type_name = "emc6d103";
++ break;
++ /*
++ * Registers apparently missing in EMC6D103S/EMC6D103:A2
++ * compared to EMC6D103:A0, EMC6D103:A1, and EMC6D102
++ * (according to the data sheets), but used unconditionally
++ * in the driver: 62[5:7], 6D[0:7], and 6E[0:7].
++ * So skip EMC6D103S for now.
++ case LM85_VERSTEP_EMC6D103S:
++ type_name = "emc6d103s";
++ break;
++ */
+ }
+ } else {
+ dev_dbg(&adapter->dev,
+@@ -1283,6 +1301,7 @@ static int lm85_probe(struct i2c_client
+ case adt7468:
+ case emc6d100:
+ case emc6d102:
++ case emc6d103:
+ data->freq_map = adm1027_freq_map;
+ break;
+ default:
+@@ -1468,7 +1487,7 @@ static struct lm85_data *lm85_update_dev
+ /* More alarm bits */
+ data->alarms |= lm85_read_value(client,
+ EMC6D100_REG_ALARM3) << 16;
+- } else if (data->type == emc6d102) {
++ } else if (data->type == emc6d102 || data->type == emc6d103) {
+ /* Have to read LSB bits after the MSB ones because
+ the reading of the MSB bits has frozen the
+ LSBs (backward from the ADM1027).
--- /dev/null
+From c71caf4114a0e1da3451cc92fba6a152929cd4c2 Mon Sep 17 00:00:00 2001
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+Date: Mon, 24 Jan 2011 19:01:07 +0100
+Subject: netfilter: ctnetlink: fix missing refcount increment during dumps
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+commit c71caf4114a0e1da3451cc92fba6a152929cd4c2 upstream.
+
+In 13ee6ac netfilter: fix race in conntrack between dump_table and
+destroy, we recovered spinlocks to protect the dump of the conntrack
+table according to reports from Stephen and acknowledgments on the
+issue from Eric.
+
+In that patch, the refcount bump that allows to keep a reference
+to the current ct object was removed. However, we still decrement
+the refcount for that object in the output path of
+ctnetlink_dump_table():
+
+ if (last)
+ nf_ct_put(last)
+
+Cc: Stephen Hemminger <stephen.hemminger@vyatta.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
+Signed-off-by: Patrick McHardy <kaber@trash.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/netfilter/nf_conntrack_netlink.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/netfilter/nf_conntrack_netlink.c
++++ b/net/netfilter/nf_conntrack_netlink.c
+@@ -664,6 +664,7 @@ restart:
+ if (ctnetlink_fill_info(skb, NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq,
+ IPCTNL_MSG_CT_NEW, ct) < 0) {
++ nf_conntrack_get(&ct->ct_general);
+ cb->args[1] = (unsigned long)ct;
+ goto out;
+ }
--- /dev/null
+From 13ee6ac579574a2a95e982b19920fd2495dce8cd Mon Sep 17 00:00:00 2001
+From: Stephen Hemminger <shemminger@vyatta.com>
+Date: Tue, 11 Jan 2011 23:54:42 +0100
+Subject: netfilter: fix race in conntrack between dump_table and destroy
+
+From: Stephen Hemminger <shemminger@vyatta.com>
+
+commit 13ee6ac579574a2a95e982b19920fd2495dce8cd upstream.
+
+The netlink interface to dump the connection tracking table has a race
+when entries are deleted at the same time. A customer reported a crash
+and the backtrace showed thatctnetlink_dump_table was running while a
+conntrack entry was being destroyed.
+(see https://bugzilla.vyatta.com/show_bug.cgi?id=6402).
+
+According to RCU documentation, when using hlist_nulls the reader
+must handle the case of seeing a deleted entry and not proceed
+further down the linked list. The old code would continue
+which caused the scan to walk into the free list.
+
+This patch uses locking (rather than RCU) for this operation which
+is guaranteed safe, and no longer requires getting reference while
+doing dump operation.
+
+Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/netfilter/nf_conntrack_netlink.c | 14 +++++---------
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+--- a/net/netfilter/nf_conntrack_netlink.c
++++ b/net/netfilter/nf_conntrack_netlink.c
+@@ -642,25 +642,23 @@ ctnetlink_dump_table(struct sk_buff *skb
+ struct nfgenmsg *nfmsg = nlmsg_data(cb->nlh);
+ u_int8_t l3proto = nfmsg->nfgen_family;
+
+- rcu_read_lock();
++ spin_lock_bh(&nf_conntrack_lock);
+ last = (struct nf_conn *)cb->args[1];
+ for (; cb->args[0] < net->ct.htable_size; cb->args[0]++) {
+ restart:
+- hlist_nulls_for_each_entry_rcu(h, n, &net->ct.hash[cb->args[0]],
++ hlist_nulls_for_each_entry(h, n, &net->ct.hash[cb->args[0]],
+ hnnode) {
+ if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
+ continue;
+ ct = nf_ct_tuplehash_to_ctrack(h);
+- if (!atomic_inc_not_zero(&ct->ct_general.use))
+- continue;
+ /* Dump entries of a given L3 protocol number.
+ * If it is not specified, ie. l3proto == 0,
+ * then dump everything. */
+ if (l3proto && nf_ct_l3num(ct) != l3proto)
+- goto releasect;
++ continue;
+ if (cb->args[1]) {
+ if (ct != last)
+- goto releasect;
++ continue;
+ cb->args[1] = 0;
+ }
+ if (ctnetlink_fill_info(skb, NETLINK_CB(cb->skb).pid,
+@@ -678,8 +676,6 @@ restart:
+ if (acct)
+ memset(acct, 0, sizeof(struct nf_conn_counter[IP_CT_DIR_MAX]));
+ }
+-releasect:
+- nf_ct_put(ct);
+ }
+ if (cb->args[1]) {
+ cb->args[1] = 0;
+@@ -687,7 +683,7 @@ releasect:
+ }
+ }
+ out:
+- rcu_read_unlock();
++ spin_unlock_bh(&nf_conntrack_lock);
+ if (last)
+ nf_ct_put(last);
+
workqueue-make-sure-mayday_initial_timeout-is-at-least-2-jiffies-long.patch
net-deinit-automatic-list_head.patch
iwl3945-remove-plcp-check.patch
+alsa-hda-add-position_fix-quirk-for-an-asus-device.patch
+alsa-caiaq-fix-possible-string-buffer-overflow.patch
+alsa-hda-do-not-announce-false-surround-in-conexant-auto.patch
+hwmon-lm85-extend-to-support-emc6d103-chips.patch
+x86-amd-pci-add-amd-northbridge-pci-device-id-for-cpu-families-12h-and-14h.patch
+hwmon-k10temp-add-support-for-amd-family-12h-14h-cpus.patch
+hwmon-jc42-fix-type-mismatch.patch
+hwmon-jc42-more-helpful-documentation.patch
+hwmon-jc42-do-not-allow-writing-to-locked-registers.patch
+netfilter-fix-race-in-conntrack-between-dump_table-and-destroy.patch
+netfilter-ctnetlink-fix-missing-refcount-increment-during-dumps.patch
--- /dev/null
+From ca86828ccd3128513f6d4e200b437deac95408db Mon Sep 17 00:00:00 2001
+From: Robert Richter <robert.richter@amd.com>
+Date: Thu, 6 Jan 2011 17:51:07 +0100
+Subject: x86, AMD, PCI: Add AMD northbridge PCI device id for CPU families 12h and 14h
+
+From: Robert Richter <robert.richter@amd.com>
+
+commit ca86828ccd3128513f6d4e200b437deac95408db upstream.
+
+This patch adds the PCI northbridge device id for AMD CPU
+families 12h and 14h. Both families have implemented the same
+PCI northbridge device.
+
+There are some future use cases that use this PCI device and
+we would like to clarify its naming.
+
+Signed-off-by: Robert Richter <robert.richter@amd.com>
+Cc: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
+Cc: Keir Fraser <keir@xen.org>
+Cc: Jan Beulich <JBeulich@novell.com>
+LKML-Reference: <20110106165107.GL4739@erda.amd.com>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/linux/pci_ids.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/include/linux/pci_ids.h
++++ b/include/linux/pci_ids.h
+@@ -518,6 +518,7 @@
+ #define PCI_DEVICE_ID_AMD_11H_NB_MISC 0x1303
+ #define PCI_DEVICE_ID_AMD_11H_NB_LINK 0x1304
+ #define PCI_DEVICE_ID_AMD_15H_NB_MISC 0x1603
++#define PCI_DEVICE_ID_AMD_CNB17H_F3 0x1703
+ #define PCI_DEVICE_ID_AMD_LANCE 0x2000
+ #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001
+ #define PCI_DEVICE_ID_AMD_SCSI 0x2020
projects / thirdparty / kernel / stable-queue.git / commitdiff
