RE: [PATCH 1/5] regulator: tps65090: rename driver name and regulator name
> -Original Message-
> From: Laxman Dewangan
> Sent: Saturday, October 06, 2012 8:48 PM
> To: broo...@opensource.wolfsonmicro.com; l...@ti.com;
> sa...@linux.intel.com
> Cc: Venu Byravarasu; axel@gmail.com; linux-kernel@vger.kernel.org;
> Laxman Dewangan
> Subject: [PATCH 1/5] regulator: tps65090: rename driver name and regulator
> name
>
> To make the names proper and more appropriate:
> Rename the driver name from tps65090-regulator to tps65090-pmic.
> Rename the regulators from TPS65090_ID_* to TPS65090_REGULATOR_*
>
> Signed-off-by: Laxman Dewangan
> ---
> drivers/regulator/tps65090-regulator.c |8
> include/linux/regulator/tps65090-regulator.h | 20 ++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/regulator/tps65090-regulator.c
> b/drivers/regulator/tps65090-regulator.c
> index 001ad55..96d59ad 100644
> --- a/drivers/regulator/tps65090-regulator.c
> +++ b/drivers/regulator/tps65090-regulator.c
> @@ -43,14 +43,14 @@ static struct regulator_ops tps65090_ops = {
>
> #define tps65090_REG(_id)\
> {\
> - .id = TPS65090_ID_##_id,\
> + .id = TPS65090_REGULATOR_##_id, \
> .desc = { \
> .name = tps65090_rails(_id),\
> - .id = TPS65090_ID_##_id,\
> + .id = TPS65090_REGULATOR_##_id, \
> .ops = _ops, \
> .type = REGULATOR_VOLTAGE, \
> .owner = THIS_MODULE, \
> - .enable_reg = (TPS65090_ID_##_id) + 12, \
> + .enable_reg = (TPS65090_REGULATOR_##_id) + 12, \
> .enable_mask = BIT(0), \
> }, \
> }
> @@ -126,7 +126,7 @@ static int __devexit
> tps65090_regulator_remove(struct platform_device *pdev)
>
> static struct platform_driver tps65090_regulator_driver = {
> .driver = {
> - .name = "tps65090-regulator",
> + .name = "tps65090-pmic",
As the driver itself is regulator driver, why should we rename it to pmic?
> .owner = THIS_MODULE,
> },
> .probe = tps65090_regulator_probe,
> diff --git a/include/linux/regulator/tps65090-regulator.h
> b/include/linux/regulator/tps65090-regulator.h
> index 0fa04b6..5e27d4a 100644
> --- a/include/linux/regulator/tps65090-regulator.h
> +++ b/include/linux/regulator/tps65090-regulator.h
> @@ -24,16 +24,16 @@
> #define tps65090_rails(_name) "tps65090_"#_name
>
> enum {
> - TPS65090_ID_DCDC1,
> - TPS65090_ID_DCDC2,
> - TPS65090_ID_DCDC3,
> - TPS65090_ID_FET1,
> - TPS65090_ID_FET2,
> - TPS65090_ID_FET3,
> - TPS65090_ID_FET4,
> - TPS65090_ID_FET5,
> - TPS65090_ID_FET6,
> - TPS65090_ID_FET7,
> + TPS65090_REGULATOR_DCDC1,
> + TPS65090_REGULATOR_DCDC2,
> + TPS65090_REGULATOR_DCDC3,
> + TPS65090_REGULATOR_FET1,
> + TPS65090_REGULATOR_FET2,
> + TPS65090_REGULATOR_FET3,
> + TPS65090_REGULATOR_FET4,
> + TPS65090_REGULATOR_FET5,
> + TPS65090_REGULATOR_FET6,
> + TPS65090_REGULATOR_FET7,
> };
>
> /*
> --
> 1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Drivers: hv: Add Hyper-V balloon driver
"K. Y. Srinivasan" writes: > +static int hot_add; > + > +module_param(hot_add, int, S_IRUGO); > +MODULE_PARM_DESC(hot_add, "If set attempt memory hot_add"); I think this should be a 'bool', but I can't tell, since it's not used in this patch. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] ARM: binfmt_flat: unused variable 'persistent'
On 06/10/12 00:55, Arnd Bergmann wrote: The flat_get_addr_from_rp() macro does not use the 'persistent' argument on ARM, causing a harmless compiler warning. A cast to void removes that warning. Without this patch, building at91x40_defconfig results in: fs/binfmt_flat.c: In function 'load_flat_file': fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable] Signed-off-by: Arnd Bergmann Cc: Greg Ungerer Cc: Russell King Cc: Bryan Wu Acked-by: Greg Ungerer I can pick this one up to, and push to the arm-soc tree. Regards Greg --- arch/arm/include/asm/flat.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h index 59426a4..e847d23 100644 --- a/arch/arm/include/asm/flat.h +++ b/arch/arm/include/asm/flat.h @@ -8,7 +8,7 @@ #define flat_argvp_envp_on_stack() 1 #define flat_old_ram_flag(flags)(flags) #define flat_reloc_valid(reloc, size) ((reloc) <= (size)) -#defineflat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp) +#defineflat_get_addr_from_rp(rp, relval, flags, persistent) ((void)persistent,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 -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not change worker's running cpu in cmci_rediscover().
Hi all,
Would you please help to review this patch ?
Thanks. :)
On 09/28/2012 03:54 PM, Lai Jiangshan wrote:
Add CC: Tejun Heo, Peter Zijlstra.
Hi, Tejun
This is a bug whose root cause is the same as
https://bugzilla.kernel.org/show_bug.cgi?id=47301.
Acked-by: Lai Jiangshan
thanks,
Lai
On 09/27/2012 05:19 PM, Tang Chen wrote:
1. cmci_rediscover() is only called by the CPU_POST_DEAD event handler, which
means the corresponding cpu has already dead. As a result, it won't be accessed
in the for_each_online_cpu loop.
So, we could change the if(cpu == dying) statement into a BUG_ON().
2. cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
another cpu, but the corresponding worker_pool is still on the original cpu.
In this case, the following BUG_ON in try_to_wake_up_local() will be triggered:
BUG_ON(rq != this_rq());
This will cause the kernel panic.
This patch removes the set_cpus_allowed_ptr() call, and put the cmci rediscover
jobs onto all the other cpus using system_wq. This could bring some delay for
the jobs.
The following is call trace.
[ 6155.451107] [ cut here ]
[ 6155.452019] kernel BUG at kernel/sched/core.c:1654!
..
[ 6155.452019] RIP: 0010:[] []
try_to_wake_up_local+0x115/0x130
..
[ 6155.452019] Call Trace:
[ 6155.452019] [] __schedule+0x764/0x880
[ 6155.452019] [] schedule+0x29/0x70
[ 6155.452019] [] schedule_timeout+0x235/0x2d0
[ 6155.452019] [] ? mark_held_locks+0x8d/0x140
[ 6155.452019] [] ? __lock_release+0x133/0x1a0
[ 6155.452019] [] ? _raw_spin_unlock_irq+0x30/0x50
[ 6155.452019] [] ? trace_hardirqs_on_caller+0x105/0x190
[ 6155.452019] [] wait_for_common+0x12b/0x180
[ 6155.452019] [] ? try_to_wake_up+0x2f0/0x2f0
[ 6155.452019] [] wait_for_completion+0x1d/0x20
[ 6155.452019] [] stop_one_cpu+0x8a/0xc0
[ 6155.452019] [] ? __migrate_task+0x1a0/0x1a0
[ 6155.452019] [] ? complete+0x28/0x60
[ 6155.452019] [] set_cpus_allowed_ptr+0x128/0x130
[ 6155.452019] [] cmci_rediscover+0xf5/0x140
[ 6155.452019] [] mce_cpu_callback+0x18d/0x19d
[ 6155.452019] [] notifier_call_chain+0x67/0x150
[ 6155.452019] [] __raw_notifier_call_chain+0xe/0x10
[ 6155.452019] [] __cpu_notify+0x20/0x40
[ 6155.452019] [] cpu_notify_nofail+0x15/0x30
[ 6155.452019] [] _cpu_down+0x262/0x2e0
[ 6155.452019] [] cpu_down+0x36/0x50
[ 6155.452019] [] acpi_processor_remove+0x50/0x11e
[ 6155.452019] [] acpi_device_remove+0x90/0xb2
[ 6155.452019] [] __device_release_driver+0x7c/0xf0
[ 6155.452019] [] device_release_driver+0x2f/0x50
[ 6155.452019] [] acpi_bus_remove+0x32/0x6d
[ 6155.452019] [] acpi_bus_trim+0x87/0xee
[ 6155.452019] [] acpi_bus_hot_remove_device+0x88/0x16b
[ 6155.452019] [] acpi_os_execute_deferred+0x27/0x34
[ 6155.452019] [] process_one_work+0x219/0x680
[ 6155.452019] [] ? process_one_work+0x1b8/0x680
[ 6155.452019] [] ? acpi_os_wait_events_complete+0x23/0x23
[ 6155.452019] [] worker_thread+0x12e/0x320
[ 6155.452019] [] ? manage_workers+0x110/0x110
[ 6155.452019] [] kthread+0xc6/0xd0
[ 6155.452019] [] kernel_thread_helper+0x4/0x10
[ 6155.452019] [] ? retint_restore_args+0x13/0x13
[ 6155.452019] [] ? __init_kthread_worker+0x70/0x70
[ 6155.452019] [] ? gs_change+0x13/0x13
Signed-off-by: Tang Chen
Signed-off-by: Miao Xie
---
arch/x86/kernel/cpu/mcheck/mce_intel.c | 34 +--
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 38e49bc..f7d9795 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -163,34 +163,38 @@ void cmci_clear(void)
raw_spin_unlock_irqrestore(_discover_lock, flags);
}
+static long cmci_rediscover_work_func(void *arg)
+{
+ int banks;
+
+ /* Recheck banks in case CPUs don't all have the same */
+ if (cmci_supported())
+ cmci_discover(banks, 0);
+
+ return 0;
+}
+
/*
* After a CPU went down cycle through all the others and rediscover
* Must run in process context.
*/
void cmci_rediscover(int dying)
{
- int banks;
- int cpu;
- cpumask_var_t old;
+ int cpu, banks;
if (!cmci_supported())
return;
- if (!alloc_cpumask_var(, GFP_KERNEL))
- return;
- cpumask_copy(old,>cpus_allowed);
for_each_online_cpu(cpu) {
- if (cpu == dying)
- continue;
- if (set_cpus_allowed_ptr(current, cpumask_of(cpu)))
+ BUG_ON(cpu == dying);
+
+ if (cpu == smp_processor_id()) {
+ cmci_rediscover_work_func(NULL);
continue;
- /* Recheck banks in case CPUs don't all have the same */
- if (cmci_supported())
Re: [PATCH] pwm: Get rid of HAVE_PWM
On Mon, Oct 08, 2012 at 10:45:44AM +0800, Eric Miao wrote: > On Fri, Oct 5, 2012 at 3:13 AM, Thierry Reding > wrote: > > On Thu, Oct 04, 2012 at 08:48:54PM +0200, Lars-Peter Clausen wrote: > >> On 10/04/2012 08:29 PM, Thierry Reding wrote: > >> > On Thu, Oct 04, 2012 at 05:00:23PM +0200, Lars-Peter Clausen wrote: > >> >> On 10/04/2012 08:06 AM, Thierry Reding wrote: > >> >>> [...] > >> >>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > >> >>> index 331d574..b38f23d 100644 > >> >>> --- a/arch/mips/Kconfig > >> >>> +++ b/arch/mips/Kconfig > >> >>> @@ -219,7 +219,8 @@ config MACH_JZ4740 > >> >>> select GENERIC_GPIO > >> >>> select ARCH_REQUIRE_GPIOLIB > >> >>> select SYS_HAS_EARLY_PRINTK > >> >>> - select HAVE_PWM > >> >>> + select PWM > >> >>> + select PWM_JZ4740 > >> >>> select HAVE_CLK > >> >>> select GENERIC_IRQ_CHIP > >> >> > >> >> I'm not sure if this is such a good idea, not all jz4740 based board > >> >> necessarily require PWM. > >> > > >> > This really only restores previous behaviour. But I agree that this is > >> > potentially not what we want. Maybe we should just not select this for > >> > any boards but rather leave it up to some default configuration. If so > >> > the patch can be made simpler by just removing the HAVE_PWM entries. > >> > >> At least for JZ4740 I think that is the better solution. > > > > Okay, I'll give other people the chance to comment on this. Especially > > for PXA there are many boards that use the PWM for backlight and it > > would be interesting to hear from them how they want this to be handled. > > I'd say the original intention to introduce HAVE_PWM (although PXA > makes a lot use of this, but I remember Russell was the first to propose > this), is for board config to indicate its potential usage of the PWM or > rather if PWM is available for use on the board, and then leave the > developer another config option to build or not-to-build. But with HAVE_PWM there was never a different configuration option to enable the PWM driver. All architectures that used the HAVE_PWM symbol built the driver based on its selection. The meaning seemed more like "the PWM API is available" rather than anything else. Given that, HAVE_PWM would now be replaced by just PWM since that makes the API available. Client drivers would still be able to compile properly but fail at runtime if no driver actually provided any PWM devices. Note that starting with 3.7 the API will even be available in the form of dummy implementations if PWM is not selected. > Personally I think removing HAVE_PWM will simplify the code a bit > and that's a good thing, on the other hand, how to keep a certain level > of flexibility mentioned above remains a small question. I guess with > device tree, this can be mitigated a bit. I think, given the above, that the best solution would be to not select any PWM-related symbols from boards and handle this via the board default configurations. I was just worrying that we were changing existing behaviour. On the other hand behaviour was already changed by making the drivers no longer conditional on HAVE_PWM. If nobody has any objections, my tendency would be to just not replace HAVE_PWM but just get rid of it. Of course, as I mentioned above, it would require the board default configurations to be updated and select the PWM and corresponding driver symbol in order to restore previous behaviour. Thierry pgpvbIsiWI0QI.pgp Description: PGP signature
RE: [PATCH 5/5] regulator: tps65090: add external control support for DCDC
> -Original Message-
> From: Laxman Dewangan
> Sent: Saturday, October 06, 2012 8:48 PM
> To: broo...@opensource.wolfsonmicro.com; l...@ti.com;
> sa...@linux.intel.com
> Cc: Venu Byravarasu; axel@gmail.com; linux-kernel@vger.kernel.org;
> Laxman Dewangan
> Subject: [PATCH 5/5] regulator: tps65090: add external control support for
> DCDC
>
> The TPS65090's DCDC outut can also be enable/disable through the
> external digital input signal. Add support for enable/disable
> either through register access via I2C or through external
> control inputs. The external control inputs can be driven through
> GPIOs also and hence adding support for passing the GPIO number.
>
> Signed-off-by: Laxman Dewangan
> ---
> drivers/regulator/tps65090-regulator.c | 130
> +++---
> include/linux/regulator/tps65090-regulator.h |6 +
> 2 files changed, 122 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/regulator/tps65090-regulator.c
> b/drivers/regulator/tps65090-regulator.c
> index 279154b..e3f130f 100644
> --- a/drivers/regulator/tps65090-regulator.c
> +++ b/drivers/regulator/tps65090-regulator.c
> @@ -18,6 +18,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,6 +34,18 @@ struct tps65090_regulator {
> struct regulator_dev*rdev;
> };
>
> +static inline bool is_dcdc(int id)
> +{
> + switch (id) {
> + case TPS65090_REGULATOR_DCDC1:
> + case TPS65090_REGULATOR_DCDC2:
> + case TPS65090_REGULATOR_DCDC3:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> static int tps65090_voltage_get_voltage(struct regulator_dev *rdev)
> {
> struct tps65090_regulator *ri = rdev_get_drvdata(rdev);
> @@ -54,12 +67,17 @@ static int tps65090_voltage_list_voltage(struct
> regulator_dev *rdev,
> return ri->microvolts;
> }
>
> -static struct regulator_ops tps65090_ops = {
> +static struct regulator_ops tps65090_ext_control_ops = {
Where tps65090_ext_control_ops are used?
> + .get_voltage= tps65090_voltage_get_voltage,
> + .list_voltage = tps65090_voltage_list_voltage,
> +};
> +
> +static struct regulator_ops tps65090_reg_contol_ops = {
> .get_voltage= tps65090_voltage_get_voltage,
> .list_voltage = tps65090_voltage_list_voltage,
> - .enable = regulator_enable_regmap,
> - .disable = regulator_disable_regmap,
> - .is_enabled = regulator_is_enabled_regmap,
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .is_enabled = regulator_is_enabled_regmap,
> };
>
> static struct regulator_ops tps65090_ldo_ops = {
> @@ -80,20 +98,76 @@ static struct regulator_ops tps65090_ldo_ops = {
> }
>
> static struct regulator_desc tps65090_regulator_desc[] = {
> - tps65090_REG_DESC(DCDC1, "vsys1", 0x0C, tps65090_ops),
> - tps65090_REG_DESC(DCDC2, "vsys2", 0x0D, tps65090_ops),
> - tps65090_REG_DESC(DCDC3, "vsys3", 0x0E, tps65090_ops),
> - tps65090_REG_DESC(FET1, "infet1", 0x0F, tps65090_ops),
> - tps65090_REG_DESC(FET2, "infet2", 0x10, tps65090_ops),
> - tps65090_REG_DESC(FET3, "infet3", 0x11, tps65090_ops),
> - tps65090_REG_DESC(FET4, "infet4", 0x12, tps65090_ops),
> - tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_ops),
> - tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_ops),
> - tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_ops),
> + tps65090_REG_DESC(DCDC1, "vsys1", 0x0C,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(DCDC2, "vsys2", 0x0D,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(DCDC3, "vsys3", 0x0E,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET1, "infet1", 0x0F,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET2, "infet2", 0x10,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET3, "infet3", 0x11,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET4, "infet4", 0x12,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET5, "infet5", 0x13,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET6, "infet6", 0x14,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET7, "infet7", 0x15,
> tps65090_reg_contol_ops),
> tps65090_REG_DESC(LDO1, "vsys_l1", 0,tps65090_ldo_ops),
> tps65090_REG_DESC(LDO2, "vsys_l2", 0,tps65090_ldo_ops),
> };
>
> +static int __devinit tps65090_set_ext_control(
> + struct tps65090_regulator *ri, bool enable)
> +{
> + int ret;
> + struct device *parent = ri->dev->parent;
> + unsigned int reg_en_reg = ri->desc->enable_reg;
> +
> + if (enable)
> + ret = tps65090_set_bits(parent, reg_en_reg, 1);
> + else
> + ret = tps65090_clr_bits(parent, reg_en_reg, 1);
> + if (ret < 0)
> + dev_err(ri->dev, "Error in updating reg 0x%x\n", reg_en_reg);
> + return ret;
> +}
> +
> +static int __devinit
Re: [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h
On 06/10/12 00:55, Arnd Bergmann wrote: On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate their arguments, which may lead to harmless build warnings in some code where the variables are not used otherwise. Adding a cast to void gets rid of the warning and does not make any semantic changes. Without this patch, building at91x40_defconfig results in: fs/read_write.c: In function 'rw_copy_check_uvector': fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable] Signed-off-by: Arnd Bergmann Cc: Greg Ungerer Cc: Russell King Acked-by: Greg Ungerer I can pick it up and push to the arm-soc tree. Regards Greg --- arch/arm/include/asm/uaccess.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h index 77bd79f..7e1f760 100644 --- a/arch/arm/include/asm/uaccess.h +++ b/arch/arm/include/asm/uaccess.h @@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long); #define USER_DS KERNEL_DS #define segment_eq(a,b) (1) -#define __addr_ok(addr)(1) -#define __range_ok(addr,size) (0) +#define __addr_ok(addr)((void)(addr),1) +#define __range_ok(addr,size) ((void)(addr),0) #define get_fs() (KERNEL_DS) static inline void set_fs(mm_segment_t fs) -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/5] mfd: tps65090: remove unused member of struct tps65090
> -Original Message-
> From: Laxman Dewangan
> Sent: Sunday, October 07, 2012 8:52 PM
> To: sa...@linux.intel.com
> Cc: linux-kernel@vger.kernel.org; Venu Byravarasu; Laxman Dewangan
> Subject: [PATCH 3/5] mfd: tps65090: remove unused member of struct
> tps65090
>
> Remove unused member from tps65090 data structure as
Remove unused members
> these are not used.
>
> Signed-off-by: Laxman Dewangan
> ---
> drivers/mfd/tps65090.c |6 +-
> include/linux/mfd/tps65090.h | 11 ---
> 2 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
> index f95f7f6..3cfc9dc 100644
> --- a/drivers/mfd/tps65090.c
> +++ b/drivers/mfd/tps65090.c
> @@ -269,12 +269,9 @@ static int __devinit tps65090_i2c_probe(struct
> i2c_client *client,
> return -ENOMEM;
> }
>
> - tps65090->client = client;
> tps65090->dev = >dev;
> i2c_set_clientdata(client, tps65090);
>
> - mutex_init(>lock);
> -
> if (client->irq) {
> ret = tps65090_irq_init(tps65090, client->irq, pdata-
> >irq_base);
> if (ret) {
> @@ -284,8 +281,7 @@ static int __devinit tps65090_i2c_probe(struct
> i2c_client *client,
> }
> }
>
> - tps65090->rmap = devm_regmap_init_i2c(tps65090->client,
> - _regmap_config);
> + tps65090->rmap = devm_regmap_init_i2c(client,
> _regmap_config);
Indentation missing.
> if (IS_ERR(tps65090->rmap)) {
> ret = PTR_ERR(tps65090->rmap);
> dev_err(>dev, "regmap_init failed with err: %d\n",
> ret);
> diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
> index 6bc31d8..6c57622 100644
> --- a/include/linux/mfd/tps65090.h
> +++ b/include/linux/mfd/tps65090.h
> @@ -25,26 +25,15 @@
> #include
>
> struct tps65090 {
> - struct mutexlock;
> struct device *dev;
> - struct i2c_client *client;
> struct regmap *rmap;
> struct irq_chip irq_chip;
> struct mutexirq_lock;
> int irq_base;
> - unsigned intid;
> -};
> -
> -struct tps65090_subdev_info {
> - int id;
> - const char *name;
> - void*platform_data;
> };
>
> struct tps65090_platform_data {
> int irq_base;
> - int num_subdevs;
> - struct tps65090_subdev_info *subdevs;
> };
>
> /*
> --
> 1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/5] mfd: tps65090: move register access APIs to header
> -Original Message-
> From: Laxman Dewangan
> Sent: Sunday, October 07, 2012 8:52 PM
> To: sa...@linux.intel.com
> Cc: linux-kernel@vger.kernel.org; Venu Byravarasu; Laxman Dewangan
> Subject: [PATCH 4/5] mfd: tps65090: move register access APIs to header
>
> Since tps65090 register is accessed via regmap, moving
> the register access APIs to header and making it as inline.
Why should we move function implementation to header file?
Also by making inline, doesn't the output binary size increase?
>
> Signed-off-by: Laxman Dewangan
> ---
> drivers/mfd/tps65090.c | 34 --
> include/linux/mfd/tps65090.h | 39
> +++
> 2 files changed, 35 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
> index 3cfc9dc..355a077 100644
> --- a/drivers/mfd/tps65090.c
> +++ b/drivers/mfd/tps65090.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #define NUM_INT_REG 2
> @@ -78,39 +77,6 @@ static struct mfd_cell tps65090s[] = {
> },
> };
>
> -int tps65090_write(struct device *dev, int reg, uint8_t val)
> -{
> - struct tps65090 *tps = dev_get_drvdata(dev);
> - return regmap_write(tps->rmap, reg, val);
> -}
> -EXPORT_SYMBOL_GPL(tps65090_write);
> -
> -int tps65090_read(struct device *dev, int reg, uint8_t *val)
> -{
> - struct tps65090 *tps = dev_get_drvdata(dev);
> - unsigned int temp_val;
> - int ret;
> - ret = regmap_read(tps->rmap, reg, _val);
> - if (!ret)
> - *val = temp_val;
> - return ret;
> -}
> -EXPORT_SYMBOL_GPL(tps65090_read);
> -
> -int tps65090_set_bits(struct device *dev, int reg, uint8_t bit_num)
> -{
> - struct tps65090 *tps = dev_get_drvdata(dev);
> - return regmap_update_bits(tps->rmap, reg, BIT(bit_num), ~0u);
> -}
> -EXPORT_SYMBOL_GPL(tps65090_set_bits);
> -
> -int tps65090_clr_bits(struct device *dev, int reg, uint8_t bit_num)
> -{
> - struct tps65090 *tps = dev_get_drvdata(dev);
> - return regmap_update_bits(tps->rmap, reg, BIT(bit_num), 0u);
> -}
> -EXPORT_SYMBOL_GPL(tps65090_clr_bits);
> -
> static void tps65090_irq_lock(struct irq_data *data)
> {
> struct tps65090 *tps65090 = irq_data_get_irq_chip_data(data);
> diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
> index 6c57622..1a5f916 100644
> --- a/include/linux/mfd/tps65090.h
> +++ b/include/linux/mfd/tps65090.h
> @@ -23,6 +23,7 @@
> #define __LINUX_MFD_TPS65090_H
>
> #include
> +#include
>
> struct tps65090 {
> struct device *dev;
> @@ -40,9 +41,39 @@ struct tps65090_platform_data {
> * NOTE: the functions below are not intended for use outside
> * of the TPS65090 sub-device drivers
> */
> -extern int tps65090_write(struct device *dev, int reg, uint8_t val);
> -extern int tps65090_read(struct device *dev, int reg, uint8_t *val);
> -extern int tps65090_set_bits(struct device *dev, int reg, uint8_t bit_num);
> -extern int tps65090_clr_bits(struct device *dev, int reg, uint8_t bit_num);
> +static inline int tps65090_write(struct device *dev, int reg, uint8_t val)
> +{
> + struct tps65090 *tps = dev_get_drvdata(dev);
> +
> + return regmap_write(tps->rmap, reg, val);
> +}
> +
> +static inline int tps65090_read(struct device *dev, int reg, uint8_t *val)
> +{
> + struct tps65090 *tps = dev_get_drvdata(dev);
> + unsigned int temp_val;
> + int ret;
> +
> + ret = regmap_read(tps->rmap, reg, _val);
> + if (!ret)
> + *val = temp_val;
> + return ret;
> +}
> +
> +static inline int tps65090_set_bits(struct device *dev, int reg,
> + uint8_t bit_num)
> +{
> + struct tps65090 *tps = dev_get_drvdata(dev);
> +
> + return regmap_update_bits(tps->rmap, reg, BIT(bit_num), ~0u);
> +}
> +
> +static inline int tps65090_clr_bits(struct device *dev, int reg,
> + uint8_t bit_num)
> +{
> + struct tps65090 *tps = dev_get_drvdata(dev);
> +
> + return regmap_update_bits(tps->rmap, reg, BIT(bit_num), 0u);
> +}
>
> #endif /*__LINUX_MFD_TPS65090_H */
> --
> 1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION]: hibernation issues on 3.5.4/3.5.5
Hello. I am experiencing problems with hibernation (echo disk > /sys/power/state) on both 3.5.4 and 3.5.5. Note: Problem did not exist up through 3.5.2 (I skipped 3.5.3). Upon resume from hibernation, the % loading progress indicator appears. At some point the image stops loading and the system reverts to a standard cold-boot sequence. Logs (attached below) reveal it is erroring out with "Invalid LZO uncompressed length". Many thanks for your help. ~ Andy === [2.354392] PM: Checking hibernation image partition /dev/hda2 [2.354414] PM: Hibernation image partition 3:2 present [2.354415] PM: Looking for hibernation image. [2.379577] PM: Image signature found, resuming [2.406288] PM: Marking nosave pages: [mem 0x0009f000-0x000f] [2.406294] PM: Basic memory bitmaps created [2.406295] PM: Preparing processes for restore. [2.406298] Freezing user space processes ... (elapsed 0.00 seconds) done. [2.406604] PM: Loading hibernation image. [3.162702] PM: Using 1 thread(s) for decompression. [3.162702] PM: Loading and decompressing image data (161994 pages) ... ^H^H^H^H 0%%^H^H^H^H 1%%^H^H^H^H 2%%^H^H^H^H 3%%^H^H^H^H 4%%^H^H^H^H 5%%^H^H^H^H 6%%^H^H^H^H 7%%^H^H^H^H 8%%^H^H^H^H 9%%^H^H^H^H 10%%^H^H^H^H 11%%^H^H^H^H 12%%^H^H^H^H 13%%^H^H^H^H 14%%^H^H^H^H 15%%^H^H^H^H 16%%^H^H^H^H 17%%^H^H^H^H 18%%^H^H^H^H 19%%^H^H^H^H 20%%^H^H^H^H 21%%^H^H^H^H 22%%^H^H^H^H 23%%^H^H^H^H 24%%^H^H^H^H 25%%^H^H^H^H 26%%^H^H^H^H 27%%^H^H^H^H 28%%^H^H^H^H 29%%^H^H^H^H 30%%^H^H^H^H 31%%^H^H^H^H 32%%^H^H^H^H 33%%^H^H^H^H 34%%^H^H^H^H 35%%^H^H^H^H 36%%^H^H^H^H 37%%^H^H^H^H 38%%^H^H^H^H 39%%^H^H^H^H 40%%^H^H^H^H 41%%^H^H^H^H 42%%^H^H^H^H 43%%^H^H^H^H 44%%^H^H^H^H 45%%^H^H^H^H 46%%^H^H^H^H 47%%^H^H^H^H 48%%^H^H^H^H 49%%^H^H^H^H 50%%^H^H^H^H 51%%^H^H^H^H 52%%^H^H^H^H 53%%^H^H^H^H 54%%^H^H^H^H 55%%^H^H^H^H 56%%^H^H^H^H 57%%^H^H^H^H 58%%^H^H^H^H 59%%^H^H^H^H 60%%^H^H^H^H 61%%^H^H^H^H 62%% [7.730534] PM: Invalid LZO uncompressed length [7.730743] [7.730880] PM: Read 647976 kbytes in 4.56 seconds (142.10 MB/s) [7.731616] PM: Error -1 resuming [8.224207] PM: Failed to load hibernation image, recovering. [8.279520] Restarting tasks ... done. [8.279783] PM: Basic memory bitmaps freed [8.306034] PM: Hibernation image not present or could not be loaded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock on poweroff
On Sun, Oct 07, 2012 at 09:41:28PM -0700, Paul E. McKenney wrote: > On Sun, Oct 07, 2012 at 07:50:12PM +0300, Kirill A. Shutemov wrote: > > On Sun, Oct 07, 2012 at 09:03:11AM -0700, Paul E. McKenney wrote: > > > On Sun, Oct 07, 2012 at 05:47:11AM +0300, Kirill A. Shutemov wrote: > > > > Hi Paul and all, > > > > > > > > With commit 755609a9087fa983f567dc5452b2fa7b089b591f I've got deadlock > > > > on > > > > poweroff. > > > > > > > > It guess it happens because of race for cpu_hotplug.lock: > > > > > > > > CPU A CPU B > > > > disable_nonboot_cpus() > > > > _cpu_down() > > > > cpu_hotplug_begin() > > > > mutex_lock(_hotplug.lock); > > > > __cpu_notify() > > > > padata_cpu_callback() > > > > __padata_remove_cpu() > > > > padata_replace() > > > > synchronize_rcu() > > > > rcu_gp_kthread() > > > > get_online_cpus(); > > > > mutex_lock(_hotplug.lock); > > > > > > > > Have you seen the issue before? > > > > > > This is a new one for me. Does the following (very lightly tested) > > > patch help? > > > > Works for me. Thanks. > > May I add your Tested-by? Yep. Tested-by: Kirill A. Shutemov -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the modules tree with Linus' tree
Stephen Rothwell writes:
> Hi Rusty,
>
> Today's linux-next merge of the modules tree got a conflict in
> init/Kconfig between commit 754b7b63d112 ("sections: disable const
> sections for PA-RISC v2") from Linus' tree and commit 54ddd23d78ba
> ("X.509: Add simple ASN.1 grammar compiler") from the modules tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> BTW, Rusty, that commit from the modules tree has no SOB from you even
> though you committed it.
Well, I merged that whole branch actually.
>From now on I'll be cherry-picking instead (mainly because I want to
fold in fixes anyway, and that's a bit messy).
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/13] drivers/media/tuners/qt1010.c: use macros for i2c_msg initialization
Sorry, I mean either: I2C_MSG_WRITE(priv->cfg->i2c_address, , sizeof(reg)), I2C_MSG_READ(priv->cfg->i2c_address, val, sizeof(*val)), Of course. Sorry for not having seen that. I can do that. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
Hi,
On Saturday 06 October 2012 04:00 AM, Sergei Shtylyov wrote:
Hello.
On 05-10-2012 12:07, Kishon Vijay Abraham I wrote:
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/devices.c | 72
+
1 file changed, 72 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index c8c2117..e2ba505 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
[...]
@@ -613,6 +614,76 @@ static void omap_init_vout(void)
[...]
+static void omap_init_ocp2scp(void)
+{
+struct omap_hwmod*oh;
+struct platform_device*pdev;
+intbus_id = -1, dev_cnt = 0, i;
+struct omap_ocp2scp_dev*ocp2scp_dev;
+const char*oh_name, *name;
+struct omap_ocp2scp_platform_data *pdata;
+
+oh_name = "ocp2scp_usb_phy";
+name= "omap-ocp2scp";
+
+oh = omap_hwmod_lookup(oh_name);
+if (!oh) {
+pr_err("%s: could not find omap_hwmod for %s\n", __func__,
+oh_name);
+return;
+}
+
+pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+if (!pdata) {
+pr_err("%s: No memory for ocp2scp pdata\n", __func__);
+return;
+}
+
+ocp2scp_dev = oh->dev_attr;
+dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+if (!dev_cnt) {
+pr_err("%s: No devices connected to ocp2scp\n", __func__);
+return;
Don't you leak 'pdata' here?
+}
+
+pdata->devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+* dev_cnt, GFP_KERNEL);
+if (!pdata->devices) {
+pr_err("%s: No memory for ocp2scp pdata devices\n", __func__);
+return;
+}
+
+for (i = 0; i< dev_cnt; i++, ocp2scp_dev++)
+pdata->devices[i] = ocp2scp_dev;
+
+pdata->dev_cnt= dev_cnt;
+
+pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata),
NULL,
+0, false);
+if (IS_ERR(pdev)) {
+pr_err("Could not build omap_device for %s %s\n",
+name, oh_name);
+return;
Don't you leak 'pdata' and 'pdata->devices' here?
Will re-post the patch fixing it.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/10] memory-hotplug: hot-remove physical memory
At 10/06/2012 03:06 AM, KOSAKI Motohiro Wrote: >> Known problems: >> 1. memory can't be offlined when CONFIG_MEMCG is selected. >>For example: there is a memory device on node 1. The address range >>is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10, >>and memory11 under the directory /sys/devices/system/memory/. >>If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup >>when we online pages. When we online memory8, the memory stored page >> cgroup >>is not provided by this memory device. But when we online memory9, the >> memory >>stored page cgroup may be provided by memory8. So we can't offline memory8 >>now. We should offline the memory in the reversed order. >>When the memory device is hotremoved, we will auto offline memory provided >>by this memory device. But we don't know which memory is onlined first, so >>offlining memory may fail. In such case, you should offline the memory by >>hand before hotremoving the memory device. > > Just iterate twice. 1st iterate: offline every non primary memory > block. 2nd iterate: > offline primary (i.e. first added) memory block. It may work. > OK, I will try it. Thanks Wen Congyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
At 10/08/2012 12:37 PM, Andi Kleen Wrote:
> Yasuaki Ishimatsu writes:
>> +}
>> +
>> +/*
>> + * We use 2M page, but we need to remove part of them,
>> + * so split 2M page to 4K page.
>> + */
>> +pte = alloc_low_page(_phys);
>
> What happens when the allocation fails?
>
> alloc_low_page seems to be buggy there too, it would __pa a NULL
> pointer.
Yes, it will cause kernek panicked in __pa() if CONFI_DEBUG_VIRTUAL is set.
Otherwise, it will return a NULL pointer. I will update this patch to deal
with NULL pointer.
>
>> +if (pud_large(*pud)) {
>> +if ((addr & ~PUD_MASK) == 0 && next <= end) {
>> +set_pud(pud, __pud(0));
>> +pages++;
>> +continue;
>> +}
>> +
>> +/*
>> + * We use 1G page, but we need to remove part of them,
>> + * so split 1G page to 2M page.
>> + */
>> +pmd = alloc_low_page(_phys);
>
> Same here
>
>> +__split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
>> +
>> +spin_lock(_mm.page_table_lock);
>> +pud_populate(_mm, pud, __va(pmd_phys));
>> +spin_unlock(_mm.page_table_lock);
>> +}
>> +
>> +pmd = map_low_page(pmd_offset(pud, 0));
>> +phys_pmd_remove(pmd, addr, end);
>> +unmap_low_page(pmd);
>> +__flush_tlb_all();
>> +}
>> +__flush_tlb_all();
>
> This doesn't flush the other CPUs doesn't it?
How to flush the other CPU's tlb? use on_each_cpu() to run __flush_tlb_all()
on each online cpu?
Thanks
Wen Congyang
>
> -Andi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/7] uio_pruss cleanup and platform support
On Sat, Oct 06, 2012 at 02:58:26, Porter, Matt wrote: > On Fri, Oct 05, 2012 at 04:43:56AM +, Hebbar, Gururaja wrote: > > Matt, > > > > On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote: > > > On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote: > > > > Changes since v1: > > > > - Replaced uio_pruss private SRAM API use with genalloc > > > > - Added DA850 platform device and clock support > > > > - Added DA850 L3 RAM gen_pool support > > > > - Split out DT binding > > > > > > > > This series enables uio_pruss on both DA850 and AM33xx. The driver > > > > previously was not enabled by any platform and the private SRAM API > > > > was accessing an invalid SRAM bank for use on DA850. For AM33xx, > > > > DT, pinctrl, and runtime PM support are added since AM33xx only > > > > boots via DT. > > > > > > I'm dropping AM33xx/OMAP support from v3 for this series > > > > Just for my clarification, I believe you will be taking up AM33xx/OMAP > > SRAM support later once you have completed supporting DaVinci. Right? > > There's no SRAM support for uio_pruss to be handled for AM33xx, Sorry for not being clearer. I was referring to adding SRAM support for McASP module on AM335x platform. > but I > will be posting a separate series with the DT portion and some alternate > hard reset handling implementation. I find the private OMAP reset api to > be very ugly but we might have to go with that for now. I didn't want > the OMAP hard reset portion to hold up the more important part of this > cleanup. > > -Matt > > > > since the > > > focus has turned to fixing Davinci SRAM to provide genalloc support > > > and the associated use of that in the driver. > > > > > > I'll have a separate series with AM33xx support since dealing cleanly > > > with external resets on OMAP is a bigger issue. > > > > > > -Matt > > > ___ > > > Davinci-linux-open-source mailing list > > > davinci-linux-open-sou...@linux.davincidsp.com > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > > > > > > Regards, > > Gururaja > > ___ > > Davinci-linux-open-source mailing list > > davinci-linux-open-sou...@linux.davincidsp.com > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > Regards, Gururaja -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/13] drivers/media/tuners/qt1010.c: use macros for i2c_msg initialization
On 08/10/12 16:05, Julia Lawall wrote:
> On Mon, 8 Oct 2012, Ryan Mallon wrote:
>
>> On 08/10/12 02:38, Julia Lawall wrote:
>>> From: Julia Lawall
>>>
>>> Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
>>>
>>> A length expressed as an explicit constant is also re-expressed as
>>> the size
>>> of the buffer, when this is possible.
>>>
>>> A simplified version of the semantic patch that makes this change is as
>>> follows: (http://coccinelle.lip6.fr/)
>>>
>>> //
>>> @@
>>> expression a,b,c;
>>> identifier x;
>>> @@
>>>
>>> struct i2c_msg x =
>>> - {.addr = a, .buf = b, .len = c, .flags = I2C_M_RD}
>>> + I2C_MSG_READ(a,b,c)
>>> ;
>>>
>>> @@
>>> expression a,b,c;
>>> identifier x;
>>> @@
>>>
>>> struct i2c_msg x =
>>> - {.addr = a, .buf = b, .len = c, .flags = 0}
>>> + I2C_MSG_WRITE(a,b,c)
>>> ;
>>>
>>> @@
>>> expression a,b,c,d;
>>> identifier x;
>>> @@
>>>
>>> struct i2c_msg x =
>>> - {.addr = a, .buf = b, .len = c, .flags = d}
>>> + I2C_MSG_OP(a,b,c,d)
>>> ;
>>> //
>>>
>>> Signed-off-by: Julia Lawall
>>>
>>> ---
>>> drivers/media/tuners/qt1010.c | 10 --
>>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/tuners/qt1010.c
>>> b/drivers/media/tuners/qt1010.c
>>> index bc419f8..37ff254 100644
>>> --- a/drivers/media/tuners/qt1010.c
>>> +++ b/drivers/media/tuners/qt1010.c
>>> @@ -25,10 +25,8 @@
>>> static int qt1010_readreg(struct qt1010_priv *priv, u8 reg, u8 *val)
>>> {
>>> struct i2c_msg msg[2] = {
>>> -{ .addr = priv->cfg->i2c_address,
>>> - .flags = 0, .buf = , .len = 1 },
>>> -{ .addr = priv->cfg->i2c_address,
>>> - .flags = I2C_M_RD, .buf = val, .len = 1 },
>>> +I2C_MSG_WRITE(priv->cfg->i2c_address, , sizeof(reg)),
>>> +I2C_MSG_READ(priv->cfg->i2c_address, val, 1),
>>
>> This is a bit inconsistent. For single length values we should either
>> consistently use sizeof(val) or 1. This has both.
>
> val is a pointer. It does not have size 1.
Sorry, I mean either:
I2C_MSG_WRITE(priv->cfg->i2c_address, , sizeof(reg)),
I2C_MSG_READ(priv->cfg->i2c_address, val, sizeof(*val)),
or:
I2C_MSG_WRITE(priv->cfg->i2c_address, , 1),
I2C_MSG_READ(priv->cfg->i2c_address, val, 1),
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/13] drivers/media/tuners/max2165.c: use macros for i2c_msg initialization
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia Lawall
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
The second case is simplified to use simple variables rather than arrays.
The variable b0 is dropped completely, and the variable reg that it
contains is used instead. The variable b1 is replaced by a u8-typed
variable named buf (the name used earlier in the file). The uses of b1 are
then adjusted accordingly.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = I2C_M_RD}
+ I2C_MSG_READ(a,b,c)
;
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = 0}
+ I2C_MSG_WRITE(a,b,c)
;
@@
expression a,b,c,d;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = d}
+ I2C_MSG_OP(a,b,c,d)
;
//
Signed-off-by: Julia Lawall
---
drivers/media/tuners/max2165.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/media/tuners/max2165.c b/drivers/media/tuners/max2165.c
index ba84936..6638617 100644
--- a/drivers/media/tuners/max2165.c
+++ b/drivers/media/tuners/max2165.c
@@ -47,7 +47,7 @@ static int max2165_write_reg(struct max2165_priv *priv, u8
reg, u8 data)
{
int ret;
u8 buf[] = { reg, data };
- struct i2c_msg msg = { .flags = 0, .buf = buf, .len = 2 };
+ struct i2c_msg msg = I2C_MSG_WRITE(0, buf, sizeof(buf));
msg.addr = priv->config->i2c_address;
@@ -68,11 +68,10 @@ static int max2165_read_reg(struct max2165_priv *priv, u8
reg, u8 *p_data)
int ret;
u8 dev_addr = priv->config->i2c_address;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
+ u8 buf;
struct i2c_msg msg[] = {
- { .addr = dev_addr, .flags = 0, .buf = b0, .len = 1 },
- { .addr = dev_addr, .flags = I2C_M_RD, .buf = b1, .len = 1 },
+ I2C_MSG_WRITE(dev_addr, , sizeof(reg)),
+ I2C_MSG_READ(dev_addr, , sizeof(buf)),
};
Not sure if the array changes should be done here or as a separate
patch. Some of the other patches also have cases where single index
arrays (both buffers and messages) could be converted. Should either
convert all or none of them. I think its probably best to do as a
separate series on top of this though.
OK, I will do it that way.
thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/13] drivers/media/tuners: use macros for i2c_msg initialization
As far as I can see, the comments on this are:
[0] should be just b
There should be a newline before the elements of a multi-element array
Some one-element array buffers should just be variables
sizeof(val) should be used
I will redo the patches to include the first two, but not the others.
I will send another set of patches for the third one. It seems like the
conclusion is that the buffer should always be a variable if it can, but
the message should always be an array for uniformity in the call to
i2c_transfer.
I believe that the fourth one is not correct. The variable in question is
a pointer, so sizeof would give the wrong result. If it is preferred, I
could not use sizeof for the other structure in the same code, but it
seems just a little safer to use it.
thanks,
julia
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia Lawall
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = I2C_M_RD}
+ I2C_MSG_READ(a,b,c)
;
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = 0}
+ I2C_MSG_WRITE(a,b,c)
;
@@
expression a,b,c,d;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = d}
+ I2C_MSG_OP(a,b,c,d)
;
//
Signed-off-by: Julia Lawall
---
drivers/media/tuners/fc0012.c |8 +++-
drivers/media/tuners/fc0013.c |8 +++-
drivers/media/tuners/mc44s803.c |8 +++-
drivers/media/tuners/mt2060.c | 13 +
drivers/media/tuners/mt2063.c | 23 ++-
drivers/media/tuners/mt2131.c | 13 +
drivers/media/tuners/mt2266.c | 13 +
drivers/media/tuners/mxl5005s.c |8
drivers/media/tuners/tda827x.c | 29 +++--
drivers/media/tuners/tuner-i2c.h| 12
drivers/media/tuners/tuner-simple.c |5 +
drivers/media/tuners/xc4000.c |9 +++--
drivers/media/tuners/xc5000.c |9 +++--
13 files changed, 56 insertions(+), 102 deletions(-)
diff --git a/drivers/media/tuners/fc0012.c b/drivers/media/tuners/fc0012.c
index 308135a..01dac7e 100644
--- a/drivers/media/tuners/fc0012.c
+++ b/drivers/media/tuners/fc0012.c
@@ -24,9 +24,7 @@
static int fc0012_writereg(struct fc0012_priv *priv, u8 reg, u8 val)
{
u8 buf[2] = {reg, val};
- struct i2c_msg msg = {
- .addr = priv->addr, .flags = 0, .buf = buf, .len = 2
- };
+ struct i2c_msg msg = I2C_MSG_WRITE(priv->addr, buf, sizeof(buf));
if (i2c_transfer(priv->i2c, , 1) != 1) {
err("I2C write reg failed, reg: %02x, val: %02x", reg, val);
@@ -38,8 +36,8 @@ static int fc0012_writereg(struct fc0012_priv *priv, u8 reg,
u8 val)
static int fc0012_readreg(struct fc0012_priv *priv, u8 reg, u8 *val)
{
struct i2c_msg msg[2] = {
- { .addr = priv->addr, .flags = 0, .buf = , .len = 1 },
- { .addr = priv->addr, .flags = I2C_M_RD, .buf = val, .len = 1 },
+ I2C_MSG_WRITE(priv->addr, , sizeof(reg)),
+ I2C_MSG_READ(priv->addr, val, 1),
};
if (i2c_transfer(priv->i2c, msg, 2) != 2) {
diff --git a/drivers/media/tuners/fc0013.c b/drivers/media/tuners/fc0013.c
index bd8f0f1..174f0b0 100644
--- a/drivers/media/tuners/fc0013.c
+++ b/drivers/media/tuners/fc0013.c
@@ -27,9 +27,7 @@
static int fc0013_writereg(struct fc0013_priv *priv, u8 reg, u8 val)
{
u8 buf[2] = {reg, val};
- struct i2c_msg msg = {
- .addr = priv->addr, .flags = 0, .buf = buf, .len = 2
- };
+ struct i2c_msg msg = I2C_MSG_WRITE(priv->addr, buf, sizeof(buf));
if (i2c_transfer(priv->i2c, , 1) != 1) {
err("I2C write reg failed, reg: %02x, val: %02x", reg, val);
@@ -41,8 +39,8 @@ static int fc0013_writereg(struct fc0013_priv *priv, u8 reg,
u8 val)
static int fc0013_readreg(struct fc0013_priv *priv, u8 reg, u8 *val)
{
struct i2c_msg msg[2] = {
- { .addr = priv->addr, .flags = 0, .buf = , .len = 1 },
- { .addr = priv->addr, .flags = I2C_M_RD, .buf = val, .len = 1 },
+ I2C_MSG_WRITE(priv->addr, , sizeof(reg)),
+ I2C_MSG_READ(priv->addr, val, 1),
};
if (i2c_transfer(priv->i2c, msg, 2) != 2) {
diff --git a/drivers/media/tuners/mc44s803.c b/drivers/media/tuners/mc44s803.c
index f1b7640..df47e03 100644
--- a/drivers/media/tuners/mc44s803.c
+++ b/drivers/media/tuners/mc44s803.c
@@ -37,9 +37,8 @@
static int mc44s803_writereg(struct mc44s803_priv *priv, u32 val)
{
u8 buf[3];
-
Re: [PATCH 3/13] drivers/media/tuners/qt1010.c: use macros for i2c_msg initialization
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia Lawall
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = I2C_M_RD}
+ I2C_MSG_READ(a,b,c)
;
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = 0}
+ I2C_MSG_WRITE(a,b,c)
;
@@
expression a,b,c,d;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b, .len = c, .flags = d}
+ I2C_MSG_OP(a,b,c,d)
;
//
Signed-off-by: Julia Lawall
---
drivers/media/tuners/qt1010.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/tuners/qt1010.c b/drivers/media/tuners/qt1010.c
index bc419f8..37ff254 100644
--- a/drivers/media/tuners/qt1010.c
+++ b/drivers/media/tuners/qt1010.c
@@ -25,10 +25,8 @@
static int qt1010_readreg(struct qt1010_priv *priv, u8 reg, u8 *val)
{
struct i2c_msg msg[2] = {
- { .addr = priv->cfg->i2c_address,
- .flags = 0, .buf = , .len = 1 },
- { .addr = priv->cfg->i2c_address,
- .flags = I2C_M_RD, .buf = val, .len = 1 },
+ I2C_MSG_WRITE(priv->cfg->i2c_address, , sizeof(reg)),
+ I2C_MSG_READ(priv->cfg->i2c_address, val, 1),
This is a bit inconsistent. For single length values we should either
consistently use sizeof(val) or 1. This has both.
val is a pointer. It does not have size 1.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3]mconf: Add Save button
mconf make me annoying I have to make menuconfig && exit to save
the config when I am tuning .config time by time, it is even
worse I have to search down to my desire submenu time by time.
So I add "Save" button to save our time. With "Save" button,
I can use CRTL-Z after save config, and then use "%" or fg to
resume menuconfig and go on tuning.
v2: Rewrite the most code to make it more correct
v3: Fix the behavior of conf_message_callback when exit.
Signed-off-by: Wang YanQing
---
scripts/kconfig/lxdialog/menubox.c | 17 +++---
scripts/kconfig/mconf.c| 47 --
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..f71f112 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
*
**) A bugfix for the Page-Down problem
*
- **) Formerly when I used Page Down and Page Up, the cursor would be set
+ **) Formerly when I used Page Down and Page Up, the cursor would be set
*to the first position in the menu box. Now lxdialog is a bit
*smarter and works more like other menu systems (just have a look at
*it).
@@ -160,6 +160,7 @@ static void print_buttons(WINDOW * win, int height, int
width, int selected)
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+ print_button(win, gettext(" Save "), y, x + 36, selected == 3);
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +373,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
- ? 2 : (button > 2 ? 0 : button);
+ ? 3 : (button > 3 ? 0 : button);
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +400,17 @@ do_resize:
return 2;
case 's':
case 'y':
- return 3;
- case 'n':
return 4;
- case 'm':
+ case 'n':
return 5;
- case ' ':
+ case 'm':
return 6;
- case '/':
+ case ' ':
return 7;
- case 'z':
+ case '/':
return 8;
+ case 'z':
+ return 9;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index f584a28..72c4ae6 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -274,6 +274,7 @@ static int child_count;
static int single_menu_mode;
static int show_all_options;
static int saved_x, saved_y;
+static int save_and_exit;
static void conf(struct menu *menu);
static void conf_choice(struct menu *menu);
@@ -521,6 +522,7 @@ static void conf(struct menu *menu)
struct symbol *sym;
struct menu *active_menu = NULL;
int res;
+ int yesno;
int s_scroll = 0;
while (1) {
@@ -588,6 +590,25 @@ static void conf(struct menu *menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+ if (!conf_get_changed()) {
+ break;
+ }
+
+ yesno = dialog_yesno(NULL,
+ _("Do you wish to save your "
+ "new configuration?\n"
+ " to continue."),
+ 6, 60);
+ if (yesno == 0) {
+ if (conf_write(filename)) {
+ show_textbox(NULL,
+ _("Error while writing of the
configuration.\n"
+ "Your configuration
changes were NOT saved."),
+ 6,60);
+ }
+ }
+ break;
+ case 4:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -595,24 +616,24 @@ static void conf(struct menu *menu)
Re: [PATCH 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
On Sun, 7 Oct 2012, Joe Perches wrote: On Sun, 2012-10-07 at 23:43 +0200, Julia Lawall wrote: On Sun, 7 Oct 2012, Joe Perches wrote: Are READ and WRITE the action names? They are really the important information in this case. Yes, most (all?) uses of _READ and _WRITE macros actually perform some I/O. I2C_MSG_READ_DATA? I2C_MSG_READ_INFO? I2C_MSG_READ_INIT? I2C_MSG_PREPARE_READ? Dunno, naming is hard. Maybe: I2C_INPUT_MSG I2C_OUTPUT_MSG I2C_OP_MSG The current terminology, however, is READ, not INPUT (.flags = I2C_M_RD). julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] fix x2apic defect that Linux kernel doesn't mask 8259A interrupt during the time window between changing VT-d table base address and initializing these VT-d entries(smpboot.c and apic.c )
Hi Suresh, Could you please update current status about these 2 files and patch? I am not sure if I have answered your questions , if not ,feel free to let me know. This is my first time to submit patch to LKML, so what should I do next step ? About this patch , where needs to be enhanced ? Thanks very much! -- Bob(LinBao Zhang) HP linux kernel enginner > -Original Message- > From: Zhang, Lin-Bao (Linux Kernel R) > Sent: 2012年9月21日 1:16 > To: 'Suresh Siddha' > Cc: linux-kernel@vger.kernel.org; a...@lxorguk.ukuu.org.uk; > mi...@redhat.com; Croxon, Nigel; 't...@linutronix.de'; 'h...@zytor.com'; > 'x...@kernel.org'; 'a.p.zijls...@chello.nl'; 'jarkko.sakki...@intel.com'; > 'joerg.roe...@amd.com'; 'agord...@redhat.com'; 'ying...@kernel.org'; > 'sta...@kernel.org' > Subject: RE: [PATCH] fix x2apic defect that Linux kernel doesn't mask 8259A > interrupt during the time window between changing VT-d table base address > and initializing these VT-d entries(smpboot.c and apic.c ) > > Hi suresh, > > Thanks for your reply and review this patch. > I also cc other maintainers of arch/x86/kernel/smpboot.c and > arch/x86/kernel/apic/apic.c(getting them by get_maintainer.pl script, > hopefully I have not disturbed many people , if yes ,sorry first) > > > > -Original Message- > > From: Suresh Siddha [mailto:suresh.b.sid...@intel.com] > > Sent: 2012年9月21日 6:23 > > To: Zhang, Lin-Bao (Linux Kernel R) > > Cc: linux-kernel@vger.kernel.org; a...@lxorguk.ukuu.org.uk; > > mi...@redhat.com; Croxon, Nigel > > Subject: Re: [PATCH] fix x2apic defect that Linux kernel doesn't mask > > 8259A interrupt during the time window between changing VT-d table > > base address and initializing these VT-d entries > > > > On Wed, 2012-09-12 at 07:02 +, Zhang, Lin-Bao (ESSN-MCXS-Linux > > Kernel > > R) wrote: > > > Hi all, > > > This defect can be observed when the x2apic setting in BIOS is set > > > to "auto" and the BIOS has virtual wire mode enabled on a power up. > > > This defect was found on a 2.6.32 based kernel. > > > > I assume you are able to reproduce the issue with the latest kernel aswell? > > > In fact , this is what I want to further discussion. Thanks for your comments > about 3.x on x2apic. > We can only reproduce this issue on 2.6.x kernel, including RHEL6.1/6.2/6.3 > and sles11sp1, they are all of 2.6.xx series. > In 3.x upstream series , we didn't reproduce this problem, I ever tested > upstream version : 3.0.0 , 3.0.38 , 3.1.10 ,3.3.8,3.4.4, we can't reproduce > it. > But I don't think this can prove that 3.x.x doesn't have potential problem > similar with 2.6.x . > By reviewing the 3.x kernel source , I found that 3.xx source have the same > design defect ,but we don't know why it doesn't trigger this problem as 2.6 , > maybe other part work around this issue , so welcome comments ,we need to > know the real reason. > Anyway , from 3.x.x kernel source , it still first change VT-d table base > address , > after some time, linux kernel then initialize RTEs. So during the window , > present bit must 0. > During this window slot , if a interrupt is coming , platform will check VT-d > entry 's present bit is 0 , cause non-fatal error and send NMI to OS. By > intel's > ITP we can clearly watch this error is caused : > 0x8000_0022__00F1____ -> [22] Bit 103:96: FR > Fault Reason is 22h The Present (P) field in the IRTE entry corresponding to > the > interrupt_index of the interrupt request is Clear. (Appendix A Fault Reason > Encodings) > > In fact, this error is just non-fatal , if firmware designed well, it should > depress > this error , I think after some time, VT-d entry has been initialized > successfully , > this error won't exist again. > I think the direction for kernel source to avoid this problem regardless > firmware is : > a) mask all 8259A interrupt -> b) create a new VT-d table ,and initialize all > entries (RTEs) -> c) take over BIOS's simple VT-d table by kernel's VT-d > table > base address --> d) unmask 8259A > thus linux kernel can correctly handle interrupt. I think this should be safe. > How do you think about it ? > > > > What virtual wire mode is it? > > Virtual wire mode-A (where the PIC output is connected to LINT0 of the > > Local > > APIC) doesn't go through interrupt-remapping and virtual wire mode-B > > (where the PIC output is routed through the IO-APIC RTE) will be > > completely disabled as all the BIOS setup IO-APIC RTE's are masked by > > the Linux kernel from the time we enable interrupt-remapping to the > > time IO-APIC RTE's are properly re-configured by the Linux kernel again. > > > > So I am at a loss to understand what is causing this. > > > Yeah , Virtual wire mob B need to use io-apic . > If no io-apic , this issue will never occur. > > > > > > > > The kernel code (smpboot.c, apic.c) does not mask 8259A interrupts > > > before changing and initializing the new VT-d table when x2apic > > > virtual wire mode is enable on power
Re: Deadlock on poweroff
On Sun, Oct 07, 2012 at 07:50:12PM +0300, Kirill A. Shutemov wrote: > On Sun, Oct 07, 2012 at 09:03:11AM -0700, Paul E. McKenney wrote: > > On Sun, Oct 07, 2012 at 05:47:11AM +0300, Kirill A. Shutemov wrote: > > > Hi Paul and all, > > > > > > With commit 755609a9087fa983f567dc5452b2fa7b089b591f I've got deadlock on > > > poweroff. > > > > > > It guess it happens because of race for cpu_hotplug.lock: > > > > > > CPU A CPU B > > > disable_nonboot_cpus() > > > _cpu_down() > > > cpu_hotplug_begin() > > > mutex_lock(_hotplug.lock); > > > __cpu_notify() > > > padata_cpu_callback() > > > __padata_remove_cpu() > > > padata_replace() > > > synchronize_rcu() > > > rcu_gp_kthread() > > > get_online_cpus(); > > > mutex_lock(_hotplug.lock); > > > > > > Have you seen the issue before? > > > > This is a new one for me. Does the following (very lightly tested) > > patch help? > > Works for me. Thanks. May I add your Tested-by? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
Yasuaki Ishimatsu writes:
> + }
> +
> + /*
> + * We use 2M page, but we need to remove part of them,
> + * so split 2M page to 4K page.
> + */
> + pte = alloc_low_page(_phys);
What happens when the allocation fails?
alloc_low_page seems to be buggy there too, it would __pa a NULL
pointer.
> + if (pud_large(*pud)) {
> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
> + set_pud(pud, __pud(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 1G page, but we need to remove part of them,
> + * so split 1G page to 2M page.
> + */
> + pmd = alloc_low_page(_phys);
Same here
> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
> +
> + spin_lock(_mm.page_table_lock);
> + pud_populate(_mm, pud, __va(pmd_phys));
> + spin_unlock(_mm.page_table_lock);
> + }
> +
> + pmd = map_low_page(pmd_offset(pud, 0));
> + phys_pmd_remove(pmd, addr, end);
> + unmap_low_page(pmd);
> + __flush_tlb_all();
> + }
> + __flush_tlb_all();
This doesn't flush the other CPUs doesn't it?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vfs: oops on open_by_handle_at() in linux-next
On Mon, 8 Oct 2012, Al Viro wrote: > On Sun, Oct 07, 2012 at 08:32:51PM -0700, Hugh Dickins wrote: > > Thank you, Sasha: this should fix it, and similar in other FSes. > > > > > > [PATCH] tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking > > > > Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(), > > u64 inum = fid->raw[2]; > > which is unhelpfully reported as at the end of shmem_alloc_inode(): > > > > BUG: unable to handle kernel paging request at 880061cd3000 > > IP: [] shmem_alloc_inode+0x40/0x40 > > Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC > > Call Trace: > > [] ? exportfs_decode_fh+0x79/0x2d0 > > [] do_handle_open+0x163/0x2c0 > > [] sys_open_by_handle_at+0xc/0x10 > > [] tracesys+0xe1/0xe6 > > > > Right, tmpfs is being stupid to access fid->raw[2] before validating that > > fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may > > fall at the end of a page, and the next page not be present. > > > > But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being > > careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and > > could oops in the same way: add the missing fh_len checks to those. > > TBH, I really don't like it. Fair enough. > How about putting minimal acceptable fhandle > length into export_operations instead? Hmm, but different "types" have different length constraints, and each fh_to_dentry() or fh_to_parent() handles several types. And the encode operations "encourage" using different lengths. Perhaps I'm misunderstanding you, but I don't know how to do as you propose, without multiplying the number of operations horribly, and changing all (not just these) filesystems. But hack around to your heart's content, there's no need for this patch to go in if there's a better. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vfs: oops on open_by_handle_at() in linux-next
On Sun, Oct 07, 2012 at 08:32:51PM -0700, Hugh Dickins wrote: > Thank you, Sasha: this should fix it, and similar in other FSes. > > > [PATCH] tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking > > Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(), > u64 inum = fid->raw[2]; > which is unhelpfully reported as at the end of shmem_alloc_inode(): > > BUG: unable to handle kernel paging request at 880061cd3000 > IP: [] shmem_alloc_inode+0x40/0x40 > Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC > Call Trace: > [] ? exportfs_decode_fh+0x79/0x2d0 > [] do_handle_open+0x163/0x2c0 > [] sys_open_by_handle_at+0xc/0x10 > [] tracesys+0xe1/0xe6 > > Right, tmpfs is being stupid to access fid->raw[2] before validating that > fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may > fall at the end of a page, and the next page not be present. > > But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being > careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and > could oops in the same way: add the missing fh_len checks to those. TBH, I really don't like it. How about putting minimal acceptable fhandle length into export_operations instead? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] Drivers: hv: Add Hyper-V balloon driver
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, October 07, 2012 8:45 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; > a...@canonical.com; a...@linux-foundation.org; a...@firstfloor.org > Subject: Re: [PATCH 2/2] Drivers: hv: Add Hyper-V balloon driver > > On Sun, Oct 07, 2012 at 04:59:46PM -0700, K. Y. Srinivasan wrote: > > +config HYPERV_BALLOON > > + tristate "Microsoft Hyper-V Balloon driver" > > + depends on HYPERV > > + help > > + Select this option to enable the Hyper-V Utilities. > > Your help text is wrong :( Sorry about that; I will fix it. > > > --- /dev/null > > +++ b/drivers/hv/hv_balloon.c > > @@ -0,0 +1,1043 @@ > > +/* > > + * Copyright (c) 2012, Microsoft Corporation. > > + * > > + * Author: > > + * K. Y. Srinivasan > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 as published > > + * by the Free Software Foundation. > > + * > > + * 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, GOOD TITLE > or > > + * NON INFRINGEMENT. See the GNU General Public License for more > > + * details. > > + * > > + * You should have received a copy of the GNU General Public License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 > > USA. > > Unless you promise to keep track of the FSF's office buildings for the > next 40+ years, just drop this paragraph entirely. Will do. Thanks, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] mm: Export vm_committed_as
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, October 07, 2012 8:44 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; > a...@canonical.com; a...@linux-foundation.org; a...@firstfloor.org > Subject: Re: [PATCH 1/2] mm: Export vm_committed_as > > On Sun, Oct 07, 2012 at 04:59:45PM -0700, K. Y. Srinivasan wrote: > > The policy engine on the host expects the guest to report the > > committed_as. Since this variable is not exported, > > export this symbol. > > Why are these symbols not needed by either Xen or KVM or vmware, which > I think all support the same thing, right? The basic balloon driver does not need this symbol since the basic balloon driver is not automatically driven by the host. On the Windows host we have a policy engine that drives the balloon driver based on both guest level memory pressure that the guest reports as well as other system level metrics the host maintains. We need this symbol to drive the policy engine on the host. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vfs: oops on open_by_handle_at() in linux-next
On Sun, 7 Oct 2012, Sasha Levin wrote: > > While fuzzing with trinity inside a KVM tools guest using latest linux-next, > I've stumbled on the following: > > [ 74.082463] BUG: unable to handle kernel paging request at 880061cd3000 > [ 74.087481] IP: [] shmem_alloc_inode+0x40/0x40 > [ 74.090032] PGD 4e27063 PUD 1fb7b067 PMD 1fc8a067 PTE 800061cd3160 > [ 74.090032] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 74.090032] Dumping ftrace buffer: > [ 74.090032](ftrace buffer empty) > [ 74.090032] CPU 1 > [ 74.090032] Pid: 7234, comm: trinity-child40 Tainted: GW > 3.6.0-next-20121005-sasha-1-g1eae105-dirty #34 > [ 74.090032] RIP: 0010:[] [] > shmem_alloc_inode+0x40/0x40 > [ 74.109655] RSP: 0018:8800268efd90 EFLAGS: 00010282 > [ 74.109655] RAX: 812190d0 RBX: 8800663d8a20 RCX: > > [ 74.109655] RDX: 0001 RSI: 880061cd2ff8 RDI: > 8800332a9000 > [ 74.109655] RBP: 8800268efef8 R08: 812d7450 R09: > > [ 74.109655] R10: 0001 R11: R12: > 83c48340 > [ 74.109655] R13: 0001 R14: R15: > > [ 74.127365] ircomm_tty_close() > [ 74.127345] FS: 7fbf37c56700() GS:88003360() > knlGS: > [ 74.127345] CS: 0010 DS: ES: CR0: 80050033 > [ 74.127345] CR2: 880061cd3000 CR3: 262c4000 CR4: > 000406e0 > [ 74.127345] DR0: DR1: DR2: > > [ 74.127345] DR3: DR6: 0ff0 DR7: > 0400 > [ 74.127345] Process trinity-child40 (pid: 7234, threadinfo > 8800268ee000, task 880026208000) > [ 74.127345] Stack: > [ 74.127345] 81488649 85f2e7b0 > 812d7450 > [ 74.127345] 880061cd2ff8 8800268efdc8 8117a23e > 8800268efde8 > [ 74.127345] 8117ac46 8800261d1108 880026208000 > 8800268efe88 > [ 74.127345] Call Trace: > [ 74.127345] [] ? exportfs_decode_fh+0x79/0x2d0 > [ 74.127345] [] ? dump_seek+0xf0/0xf0 > [ 74.127345] [] ? put_lock_stats.isra.16+0xe/0x40 > [ 74.127345] [] ? lock_release_holdtime+0x126/0x140 > [ 74.127345] [] ? lock_release_non_nested+0xde/0x310 > [ 74.127345] [] ? _raw_spin_unlock_irqrestore+0x84/0xb0 > [ 74.127345] [] do_handle_open+0x163/0x2c0 > [ 74.127345] [] sys_open_by_handle_at+0xc/0x10 > [ 74.127345] [] tracesys+0xe1/0xe6 > [ 74.127345] Code: 48 85 c0 74 0e 48 05 78 01 00 00 eb 0e 66 0f 1f 44 00 00 > 31 c0 66 0f 1f 44 00 00 5d c3 66 66 66 66 66 2e 0f > 1f 84 00 00 00 00 00 <8b> 46 08 48 89 f1 8b 76 04 48 c1 e0 20 48 09 f0 83 fa > 02 7e 46 > [ 74.127345] RIP [] shmem_alloc_inode+0x40/0x40 > [ 74.127345] RSP > [ 74.127345] CR2: 880061cd3000 > [ 74.127345] ---[ end trace 60d7f664788c4cb8 ]--- > > > > # addr2line -i -e vmlinux 812d792c > /usr/src/linux/fs/fhandle.c:265 > # addr2line -i -e vmlinux 812d77c3 > /usr/src/linux/fs/fhandle.c:155 > /usr/src/linux/fs/fhandle.c:205 > /usr/src/linux/fs/fhandle.c:221 > # addr2line -i -e vmlinux 81488649 > /usr/src/linux/fs/exportfs/expfs.c:385 > # addr2line -i -e vmlinux 812190d0 > /usr/src/linux/mm/shmem.c:2224 Thank you, Sasha: this should fix it, and similar in other FSes. [PATCH] tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(), u64 inum = fid->raw[2]; which is unhelpfully reported as at the end of shmem_alloc_inode(): BUG: unable to handle kernel paging request at 880061cd3000 IP: [] shmem_alloc_inode+0x40/0x40 Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC Call Trace: [] ? exportfs_decode_fh+0x79/0x2d0 [] do_handle_open+0x163/0x2c0 [] sys_open_by_handle_at+0xc/0x10 [] tracesys+0xe1/0xe6 Right, tmpfs is being stupid to access fid->raw[2] before validating that fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may fall at the end of a page, and the next page not be present. But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and could oops in the same way: add the missing fh_len checks to those. Reported-by: Sasha Levin Signed-off-by: Hugh Dickins Cc: Al Viro Cc: Sage Weil Cc: Steven Whitehouse Cc: Christoph Hellwig Cc: sta...@vger.kernel.org --- fs/ceph/export.c| 18 ++ fs/gfs2/export.c|4 fs/isofs/export.c |2 +- fs/reiserfs/inode.c |6 +- fs/xfs/xfs_export.c |3 +++ mm/shmem.c |6 -- 6 files changed, 31 insertions(+), 8 deletions(-) --- 3.6.0/fs/ceph/export.c 2012-07-21 13:58:29.0 -0700 +++ linux/fs/ceph/export.c 2012-10-07 17:52:50.846051082 -0700 @@ -99,7 +99,7 @@ static int ceph_encode_fh(struct
Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function
On Mon, Oct 8, 2012 at 10:38 AM, Eric Miao wrote: > On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann wrote: >> The sharpsl_fatal_check has not been used since Pavel Machek removed >> the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix >> resume". Nobody has complained since 2009, so it's safe to assume we >> can just remove the function. >> >> Without this patch, building corgi_defconfig results in: >> >> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning: >> 'sharpsl_fatal_check' defined but not used [-Wunused-function] >> >> Signed-off-by: Arnd Bergmann >> Cc: Pavel Machek >> Cc: Stanislav Brabec >> Cc: Eric Miao >> Cc: Haojian Zhuang > > Acked-by: Eric Miao > > Let's get it cleaned up firstly. One can always reference the history for a > sample implementation later if this is needed in the future. > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BISECTED] snd-hda-intel audio distortion in Linus' current tree
[Cc: alsa-de...@alsa-project.org; also, please cc: me explicitly as well, since I'm not subscribed to either list] On Wed, Sep 26, 2012 at 12:29 AM, Steven Noonan wrote: > Started having audio problems when trying out the latest tree > (v3.6-rc7-10-g56d27ad). When playing any kind of audio, there was > significant distortion, mostly crackling noise. I'm using a Lenovo > ThinkPad X230 (Panther Point). > > I did a git-bisect to locate the problem, and it seems this commit is to > blame: > > c20c5a841cbe47f5b7812b57bd25397497e5fbc0 is the first bad commit > commit c20c5a841cbe47f5b7812b57bd25397497e5fbc0 > Author: Seth Heasley > Date: Thu Jun 14 14:23:53 2012 -0700 > > ALSA: hda_intel: activate COMBO mode for Intel client chipsets > > This patch activates the COMBO position_fix for recent Intel > client chipsets. > COMBO mode is the recommended setting for Intel chipsets and > eliminates HD > audio warnings in dmesg. This patch has been tested on Lynx > Point, Panther > Point, and Cougar Pont. > > Signed-off-by: Seth Heasley > Signed-off-by: Takashi Iwai > > It's pretty clear-cut. If I revert this patch, my sound starts > functioning normally again. > > Any thoughts on how to proceed here? Can someone revert this, or is > there some testing that I can do? > > Here's a pretty-printed bisection log, if needed: > > # good: [28a33cbc] Linux 3.5 > # bad: [b13bc8dd] Merge tag 'staging-3.6-rc1' of git://git.kernel.or > # good: [3c4cfade] Merge git://git.kernel.org/pub/scm/linux/kernel/gi > # bad: [9fc37779] Merge tag 'usb-3.6-rc1' of git://git.kernel.org/pu > # bad: [f14121ab] Merge tag 'dt-for-3.6' of git://sources.calxeda.co > # good: [d14b7a41] Merge branch 'for-linus' of git://git.kernel.org/p > # good: [15d47763] Merge branch 'for-3.5' into for-3.6 > # bad: [dbf7b591] Merge tag 'sound-3.6' of git://git.kernel.org/pub/ > # bad: [1c76684d] ALSA: hda - add Haswell HDMI codec id > # bad: [8b8d654b] ALSA: hda - Move one-time init codes from generic_ > # good: [80c8bfbe] ALSA: HDA: Create phantom jacks for fixed inputs a > # bad: [ceaa86ba] ALSA: hda - Remove invalid init verbs for Nvidia 2 > # bad: [4b6ace9e] ALSA: hda - Add the support for VIA HDMI pin detec > # bad: [c20c5a84] ALSA: hda_intel: activate COMBO mode for Intel cli > > > - Steven > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > I can confirm that I've also hit this bug as well, and that it's still present in stable 3.6.0. Strangely enough however, this only seems to affect VLC for me; while playing audio through mplayer or any gstreamer-based players (Rhythmbox, Totem, etc.), I don't encounter any audio distortion. Possibly also related to [1]? A workaround (other than reverting this commit) is to not use COMBO mode, i.e. load snd-hda-intel with position_fix=2. Please let me know if any more information is needed. $ lspci -vvnn | grep -A8 Audio 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: Toshiba America Info Systems Device [1179:fb30] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Machine: Toshiba Satellite P850 Distro: Debian wheezy/sid ALSA 1.0.25; PulseAudio 2.0 Regards, Vincent [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-September/055161.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
If a cpu is offline, its nid will be set to -1, and cpu_to_node(cpu) will
return -1. As a result, cpumask_of_node(nid) will return NULL. In this case,
find_next_bit() in for_each_cpu will get a NULL pointer and cause panic.
Here is a call trace:
[ 609.824017] Call Trace:
[ 609.824017]
[ 609.824017] [] select_fallback_rq+0x71/0x190
[ 609.824017] [] ? try_to_wake_up+0x2e/0x2f0
[ 609.824017] [] try_to_wake_up+0x2cb/0x2f0
[ 609.824017] [] ? __run_hrtimer+0x78/0x320
[ 609.824017] [] wake_up_process+0x15/0x20
[ 609.824017] [] hrtimer_wakeup+0x22/0x30
[ 609.824017] [] __run_hrtimer+0x83/0x320
[ 609.824017] [] ? update_rmtp+0x80/0x80
[ 609.824017] [] hrtimer_interrupt+0x106/0x280
[ 609.824017] [] ? sd_free_ctl_entry+0x68/0x70
[ 609.824017] [] smp_apic_timer_interrupt+0x69/0x99
[ 609.824017] [] apic_timer_interrupt+0x6f/0x80
There is a hrtimer process sleeping, whose cpu has already been offlined.
When it is waken up, it tries to find another cpu to run, and get a -1 nid.
As a result, cpumask_of_node(-1) returns NULL, and causes ernel panic.
This patch fixes this problem by judging if the nid is -1.
If nid is not -1, a cpu on the same node will be picked.
Else, a online cpu on another node will be picked.
Signed-off-by: Tang Chen
---
kernel/sched/core.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 66b36ab..e76dce9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1263,18 +1263,24 @@ EXPORT_SYMBOL_GPL(kick_process);
*/
static int select_fallback_rq(int cpu, struct task_struct *p)
{
- const struct cpumask *nodemask = cpumask_of_node(cpu_to_node(cpu));
+ int nid = cpu_to_node(cpu);
+ const struct cpumask *nodemask = NULL;
enum { cpuset, possible, fail } state = cpuset;
int dest_cpu;
- /* Look for allowed, online CPU in same node. */
- for_each_cpu(dest_cpu, nodemask) {
- if (!cpu_online(dest_cpu))
- continue;
- if (!cpu_active(dest_cpu))
- continue;
- if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
- return dest_cpu;
+ /* If the cpu has been offlined, its nid was set to -1. */
+ if (nid != -1) {
+ nodemask = cpumask_of_node(nid);
+
+ /* Look for allowed, online CPU in same node. */
+ for_each_cpu(dest_cpu, nodemask) {
+ if (!cpu_online(dest_cpu))
+ continue;
+ if (!cpu_active(dest_cpu))
+ continue;
+ if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
+ return dest_cpu;
+ }
}
for (;;) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2]mconf: Add Save button
mconf make me annoying I have to make menuconfig && exit to
save the config when I am tuning .config time by time, it
is even worse I have to search down to my desire submenu
time by time. So I add "Save" button to save our time. With
"Save" button, I can use CRTL-Z after save config, and then
use "%" or fg to resume menuconfig and go on tuning.
Changes v1-v2:
* Rewrite the most code to make it more correct
Signed-off-by: Wang YanQing
---
scripts/kconfig/lxdialog/menubox.c | 17
scripts/kconfig/mconf.c| 40 --
2 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..f71f112 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
*
**) A bugfix for the Page-Down problem
*
- **) Formerly when I used Page Down and Page Up, the cursor would be set
+ **) Formerly when I used Page Down and Page Up, the cursor would be set
*to the first position in the menu box. Now lxdialog is a bit
*smarter and works more like other menu systems (just have a look at
*it).
@@ -160,6 +160,7 @@ static void print_buttons(WINDOW * win, int height, int
width, int selected)
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+ print_button(win, gettext(" Save "), y, x + 36, selected == 3);
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +373,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
- ? 2 : (button > 2 ? 0 : button);
+ ? 3 : (button > 3 ? 0 : button);
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +400,17 @@ do_resize:
return 2;
case 's':
case 'y':
- return 3;
- case 'n':
return 4;
- case 'm':
+ case 'n':
return 5;
- case ' ':
+ case 'm':
return 6;
- case '/':
+ case ' ':
return 7;
- case 'z':
+ case '/':
return 8;
+ case 'z':
+ return 9;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index f584a28..100b52a 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -521,6 +521,7 @@ static void conf(struct menu *menu)
struct symbol *sym;
struct menu *active_menu = NULL;
int res;
+ int yesno;
int s_scroll = 0;
while (1) {
@@ -588,6 +589,25 @@ static void conf(struct menu *menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+ if (!conf_get_changed()) {
+ break;
+ }
+
+ yesno = dialog_yesno(NULL,
+ _("Do you wish to save your "
+ "new configuration?\n"
+ " to continue."),
+ 6, 60);
+ if (yesno == 0) {
+ if (conf_write(filename)) {
+ show_textbox(NULL,
+ _("Error while writing of the
configuration.\n"
+ "Your configuration
changes were NOT saved."),
+ 6,60);
+ }
+ }
+ break;
+ case 4:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -595,24 +615,24 @@ static void conf(struct menu *menu)
show_textbox(NULL, setmod_text, 6, 74);
}
break;
- case 4:
+ case 5:
if (item_is_tag('t'))
sym_set_tristate_value(sym, no);
Re: [PATCH] pwm: Get rid of HAVE_PWM
On Fri, Oct 5, 2012 at 3:13 AM, Thierry Reding wrote: > On Thu, Oct 04, 2012 at 08:48:54PM +0200, Lars-Peter Clausen wrote: >> On 10/04/2012 08:29 PM, Thierry Reding wrote: >> > On Thu, Oct 04, 2012 at 05:00:23PM +0200, Lars-Peter Clausen wrote: >> >> On 10/04/2012 08:06 AM, Thierry Reding wrote: >> >>> [...] >> >>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig >> >>> index 331d574..b38f23d 100644 >> >>> --- a/arch/mips/Kconfig >> >>> +++ b/arch/mips/Kconfig >> >>> @@ -219,7 +219,8 @@ config MACH_JZ4740 >> >>> select GENERIC_GPIO >> >>> select ARCH_REQUIRE_GPIOLIB >> >>> select SYS_HAS_EARLY_PRINTK >> >>> - select HAVE_PWM >> >>> + select PWM >> >>> + select PWM_JZ4740 >> >>> select HAVE_CLK >> >>> select GENERIC_IRQ_CHIP >> >> >> >> I'm not sure if this is such a good idea, not all jz4740 based board >> >> necessarily require PWM. >> > >> > This really only restores previous behaviour. But I agree that this is >> > potentially not what we want. Maybe we should just not select this for >> > any boards but rather leave it up to some default configuration. If so >> > the patch can be made simpler by just removing the HAVE_PWM entries. >> >> At least for JZ4740 I think that is the better solution. > > Okay, I'll give other people the chance to comment on this. Especially > for PXA there are many boards that use the PWM for backlight and it > would be interesting to hear from them how they want this to be handled. I'd say the original intention to introduce HAVE_PWM (although PXA makes a lot use of this, but I remember Russell was the first to propose this), is for board config to indicate its potential usage of the PWM or rather if PWM is available for use on the board, and then leave the developer another config option to build or not-to-build. Personally I think removing HAVE_PWM will simplify the code a bit and that's a good thing, on the other hand, how to keep a certain level of flexibility mentioned above remains a small question. I guess with device tree, this can be mitigated a bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()
From: Wei Yongjun
Remove the pointless NULL dereference above the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
---
v1 -> v2: drop the NULL dereference
---
drivers/misc/ti-st/st_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
index 46937b1..b90a224 100644
--- a/drivers/misc/ti-st/st_core.c
+++ b/drivers/misc/ti-st/st_core.c
@@ -511,7 +511,6 @@ long st_register(struct st_proto_s *new_proto)
unsigned long flags = 0;
st_kim_ref(_gdata, 0);
- pr_info("%s(%d) ", __func__, new_proto->chnl_id);
if (st_gdata == NULL || new_proto == NULL || new_proto->recv == NULL
|| new_proto->reg_complete_cb == NULL) {
pr_err("gdata/new_proto/recv or reg_complete_cb not ready");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function
On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann wrote:
> The sharpsl_fatal_check has not been used since Pavel Machek removed
> the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
> resume". Nobody has complained since 2009, so it's safe to assume we
> can just remove the function.
>
> Without this patch, building corgi_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning:
> 'sharpsl_fatal_check' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann
> Cc: Pavel Machek
> Cc: Stanislav Brabec
> Cc: Eric Miao
> Cc: Haojian Zhuang
Acked-by: Eric Miao
Let's get it cleaned up firstly. One can always reference the history for a
sample implementation later if this is needed in the future.
> ---
> arch/arm/mach-pxa/sharpsl_pm.c | 48
>
> 1 file changed, 48 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index bdf4cb8..6c9658f 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -55,7 +55,6 @@
> #ifdef CONFIG_PM
> static int sharpsl_off_charge_battery(void);
> static int sharpsl_check_battery_voltage(void);
> -static int sharpsl_fatal_check(void);
> #endif
> static int sharpsl_check_battery_temp(void);
> static int sharpsl_ac_check(void);
> @@ -686,53 +685,6 @@ static int corgi_pxa_pm_enter(suspend_state_t state)
> return 0;
> }
>
> -/*
> - * Check for fatal battery errors
> - * Fatal returns -1
> - */
> -static int sharpsl_fatal_check(void)
> -{
> - int buff[5], temp, i, acin;
> -
> - dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check entered\n");
> -
> - /* Check AC-Adapter */
> - acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);
> -
> - if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> - sharpsl_pm.machinfo->charge(0);
> - udelay(100);
> - sharpsl_pm.machinfo->discharge(1); /* enable discharge */
> - mdelay(SHARPSL_WAIT_DISCHARGE_ON);
> - }
> -
> - if (sharpsl_pm.machinfo->discharge1)
> - sharpsl_pm.machinfo->discharge1(1);
> -
> - /* Check battery : check inserting battery ? */
> - for (i = 0; i < 5; i++) {
> - buff[i] =
> sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);
> - mdelay(SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT);
> - }
> -
> - if (sharpsl_pm.machinfo->discharge1)
> - sharpsl_pm.machinfo->discharge1(0);
> -
> - if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> - udelay(100);
> - sharpsl_pm.machinfo->charge(1);
> - sharpsl_pm.machinfo->discharge(0);
> - }
> -
> - temp = get_select_val(buff);
> - dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge
> voltage: %d, no discharge: %ld\n", acin, temp,
> sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT));
> -
> - if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) ||
> - (!acin && (temp <
> sharpsl_pm.machinfo->fatal_noacin_volt)))
> - return -1;
> - return 0;
> -}
> -
> static int sharpsl_off_charge_error(void)
> {
> dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n");
> --
> 1.7.10
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Module xattr signatures
Mimi Zohar writes: > On Fri, 2012-10-05 at 17:42 +0300, Kasatkin, Dmitry wrote: >> Hello, >> >> On Fri, Oct 5, 2012 at 4:47 AM, Rusty Russell wrote: >> > >> > Hi all, >> > >> > Had a talk with Mimi, and IMA still wants xattr signatures on >> > modules like they have for other files with EVM. With Kees' patches now >> > merged into my modules-wip branch (warning, rebases frequently), this >> > should be pretty simple. Dmitry? >> > >> >> Yes, there is no difference for IMA/EVM what type of file has a >> signature to verify. >> It just reads the signature from the xattr. With the module hook it >> will just do the same >> for modules as well. It is independent of appended signature verification. >> The format of signatures is different at the moment. > >> > The question of whether this falls back to appended signatures >> > if there's no xattr support, or whether we fix cpio depends on whether >> > someone is prepared to do the latter. As Mimi points out, AIX, bsd, >> > solaris all have versions of cpio that support extended attributes, as >> > does the bsdcpio Debian package, for example. >> > >> >> As I already said in one of my early mails, I am not sure at all if >> IMA really needs to verify a signature, >> if primary mechanism is to use appended signature. > > Which is the preferred method is exactly the point. That depends on your > use case. For systems with IMA-appraisal already enabled, there would > not be any reason for the appended signature verification. > > Now, with the MODULE_CHECK hook, systems could define an IMA-appraisal > policy to appraise just kernel modules. > > The remaining issue is how to deal with filesystems that don't have > extended attribute support. As we've already had this discussion, lets > summarize the different options: > > - don't support them > > Not very friendly. > > - modify the new syscall to pass the signature and signature length > > Kees nixed this idea. > > - fall back to appended signature verification > > In addition to David Howell's version of the appended signature > verification, I would like having the existing EVM/IMA-appraisal > signature format, based on Dmitry's proposed kernel module patches, as > another option. Or: - Reduce the set of filesystems which don't support xattrs to the empty set ;) Which I prefer... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the thermal tree
Hi,
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Monday, October 08, 2012 8:02 AM
> To: Zhang, Rui
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Amit
> Daniel Kachhap; Wu, Fengguang; Andrew Morton
> Subject: linux-next: build failure after merge of the thermal tree
> Importance: High
>
> Hi Zhang,
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared
> (first use in this function)
>
> Caused by commit 023614183768 ("thermal: add generic cpufreq cooling
> implementation") interacting with commit 125c4c706b68 ("idr: rename
> MAX_LEVEL to MAX_IDR_LEVEL") which very recently entered Linus' tree.
>
> I have applied the following fix patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 8 Oct 2012 10:56:56 +1100
> Subject: [PATCH] thermal: fix for for MAX_ID_MASK to MAX_IDR_MASK
> rename
>
> Signed-off-by: Stephen Rothwell
The patch looks good to me, thanks for the fix.
-rui
> ---
> drivers/thermal/cpu_cooling.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c
> b/drivers/thermal/cpu_cooling.c index 9050c1b..cc1c930 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -86,7 +86,7 @@ again:
> else if (unlikely(err))
> return err;
>
> - *id = *id & MAX_ID_MASK;
> + *id = *id & MAX_IDR_MASK;
> return 0;
> }
>
> --
> 1.7.10.280.gaa39
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
On 08/10/12 12:56, Mauro Carvalho Chehab wrote:
> Em Sun, 07 Oct 2012 14:51:58 -0700
> Joe Perches escreveu:
>
>> On Sun, 2012-10-07 at 23:43 +0200, Julia Lawall wrote:
>>> On Sun, 7 Oct 2012, Joe Perches wrote:
> Are READ and WRITE the action names? They are really the important
> information in this case.
Yes, most (all?) uses of _READ and _WRITE macros actually
perform some I/O.
>>>
>>> I2C_MSG_READ_DATA?
>>> I2C_MSG_READ_INFO?
>>> I2C_MSG_READ_INIT?
>>> I2C_MSG_PREPARE_READ?
>>
>> Dunno, naming is hard. Maybe:
>>
>> I2C_INPUT_MSG
>> I2C_OUTPUT_MSG
>> I2C_OP_MSG
>
> READ/WRITE sounds better, IMHO, as it will generally match with the
> function names (they're generally named like foo_i2c_read or foo_reg_read).
> I think none of them uses input or output. Btw, with I2C buses, a
> register read is coded as a write ops, that sets the register's sub-address,
> followed by a read ops from that (and subsequent) registers.
>
> I'm afraid that using INPUT/OUTPUT will sound confusing.
>
> So, IMHO, I2C_READ_MSG and I2C_WRITE_MSG sounds better.
>
> Btw, as the WRITE + READ operation is very common (I think it is
> much more common than a simple READ msg), it could make sense to have
> just one macro for it, like:
>
> INIT_I2C_READ_SUBADDR() that would take both write and read values.
>
> I also don't like the I2C_MSG_OP. The operations there are always
> read or write.
>
> So, IMHO, the better would be to code the read and write message init message
> as something similar to:
>
> #define DECLARE_I2C_MSG_READ(_msg, _addr, _buf, _len, _flags)
> \
> struct i2c_msg _msg[1] = {
> \
> {.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) |
> I2C_M_RD }\
> }
>
> #define DECLARE_I2C_MSG_WRITE(_msg, _addr, _buf, _len, _flags)
> \
> struct i2c_msg _msg[1] = {
> \
> {.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) &
> ~I2C_M_RD } \
> }
>
> #define DECLARE_I2C_MSG_READ_SUBADDR(_msg, _addr, _subaddr,
> _sublen,_subflags, _buf,_len, _flags) \
> struct i2c_msg _msg[2] = {
> \
> {.addr = _addr, .buf = _subbuf, .len = _sublen, .flags =
> (_subflags) & ~I2C_M_RD } \
> {.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) |
> I2C_M_RD }\
> }
I think this is probably more confusing, not less. The macro takes 8
arguments, and in many cases will wrap onto two or more lines. The large
number of arguments also makes it difficult for a casual reader to
determine exactly what it does. In comparison:
I2C_MSG_WRITE(info->i2c_addr, , 1);
I2C_MSG_READ(info->i2c_addr, buf, sizeof(buf));
is fairly self-explanatory, especially for someone familiar with i2c,
without having to look up the macro definitions.
> Notes:
>
> 1) in the case of DECLARE_I2C_MSG_READ_SUBADDR(), I'm almost sure that, in
> all cases, the
> first message will always have buffer size equal to 1. If so, you can
> simplify the number
> of arguments there.
>
> 2) It could make sense to have, in fact, two versions for each, one with
> _FLAGS and another one
> without. On most cases, the one without flags are used.
>
> 3) I bet that most of the cases where 2 messages are used, the first message
> has length equal
> to one, and it uses a fixed u8 constant with the I2C sub-address. So, maybe
> it would be nice
> to have a variant for this case.
That ends up with a whole bunch of variants of the macro for something
which should be very simple. The proposal has three macros, and the
I2C_MSG_OP macro is only required for a one or two corner cases where
non-standard flags are used.
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux/compiler.h: Add __must_hold macro for functions called with a lock held
linux/compiler.h has macros to denote functions that acquire or release locks, but not to denote functions called with a lock held that return with the lock still held. Add a __must_hold macro to cover that case. Signed-off-by: Josh Triplett Reported-by: Ed Cashin Tested-by: Ed Cashin --- include/linux/compiler.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index f430e41..b121554 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -10,6 +10,7 @@ # define __force __attribute__((force)) # define __nocast __attribute__((nocast)) # define __iomem __attribute__((noderef, address_space(2))) +# define __must_hold(x)__attribute__((context(x,1,1))) # define __acquires(x) __attribute__((context(x,0,1))) # define __releases(x) __attribute__((context(x,1,0))) # define __acquire(x) __context__(x,1) @@ -33,6 +34,7 @@ extern void __chk_io_ptr(const volatile void __iomem *); # define __chk_user_ptr(x) (void)0 # define __chk_io_ptr(x) (void)0 # define __builtin_warning(x, y...) (1) +# define __must_hold(x) # define __acquires(x) # define __releases(x) # define __acquire(x) (void)0 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.6.1
Threadirqs still not working here (and never did). Email me if you want to sort it out. Peace Be With You. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
Em Sun, 07 Oct 2012 14:51:58 -0700
Joe Perches escreveu:
> On Sun, 2012-10-07 at 23:43 +0200, Julia Lawall wrote:
> > On Sun, 7 Oct 2012, Joe Perches wrote:
> > >> Are READ and WRITE the action names? They are really the important
> > >> information in this case.
> > >
> > > Yes, most (all?) uses of _READ and _WRITE macros actually
> > > perform some I/O.
> >
> > I2C_MSG_READ_DATA?
> > I2C_MSG_READ_INFO?
> > I2C_MSG_READ_INIT?
> > I2C_MSG_PREPARE_READ?
>
> Dunno, naming is hard. Maybe:
>
> I2C_INPUT_MSG
> I2C_OUTPUT_MSG
> I2C_OP_MSG
READ/WRITE sounds better, IMHO, as it will generally match with the
function names (they're generally named like foo_i2c_read or foo_reg_read).
I think none of them uses input or output. Btw, with I2C buses, a
register read is coded as a write ops, that sets the register's sub-address,
followed by a read ops from that (and subsequent) registers.
I'm afraid that using INPUT/OUTPUT will sound confusing.
So, IMHO, I2C_READ_MSG and I2C_WRITE_MSG sounds better.
Btw, as the WRITE + READ operation is very common (I think it is
much more common than a simple READ msg), it could make sense to have
just one macro for it, like:
INIT_I2C_READ_SUBADDR() that would take both write and read values.
I also don't like the I2C_MSG_OP. The operations there are always
read or write.
So, IMHO, the better would be to code the read and write message init message
as something similar to:
#define DECLARE_I2C_MSG_READ(_msg, _addr, _buf, _len, _flags)
\
struct i2c_msg _msg[1] = {
\
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) |
I2C_M_RD }\
}
#define DECLARE_I2C_MSG_WRITE(_msg, _addr, _buf, _len, _flags)
\
struct i2c_msg _msg[1] = {
\
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) &
~I2C_M_RD } \
}
#define DECLARE_I2C_MSG_READ_SUBADDR(_msg, _addr, _subaddr, _sublen,_subflags,
_buf,_len, _flags) \
struct i2c_msg _msg[2] = {
\
{.addr = _addr, .buf = _subbuf, .len = _sublen, .flags =
(_subflags) & ~I2C_M_RD } \
{.addr = _addr, .buf = _buf, .len = _len, .flags = (_flags) |
I2C_M_RD }\
}
Notes:
1) in the case of DECLARE_I2C_MSG_READ_SUBADDR(), I'm almost sure that, in all
cases, the
first message will always have buffer size equal to 1. If so, you can simplify
the number
of arguments there.
2) It could make sense to have, in fact, two versions for each, one with _FLAGS
and another one
without. On most cases, the one without flags are used.
3) I bet that most of the cases where 2 messages are used, the first message
has length equal
to one, and it uses a fixed u8 constant with the I2C sub-address. So, maybe it
would be nice
to have a variant for this case.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] vlan: don't deliver frames for unknown vlans to protocols
6a32e4f9dd9219261f8856f817e6655114cfec2f made the vlan code skip marking
vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
there was an rx_handler, as the rx_handler could cause the frame to be received
on a different (virtual) vlan-capable interface where that vlan might be
configured.
As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
frames for unknown vlans to be delivered to the protocol stack as if they had
been received untagged.
For example, if an ipv6 router advertisement that's tagged for a locally not
configured vlan is received on an interface with macvlan interfaces attached,
macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
macvlan interfaces, which caused it to be passed to the protocol stack, leading
to ipv6 addresses for the announced prefix being configured even though those
are completely unusable on the underlying interface.
The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
rx_handler, if there is one, sees the frame unchanged, but afterwards,
before the frame is delivered to the protocol stack, it gets marked whether
there is an rx_handler or not.
Signed-off-by: Florian Zumbiehl
---
NOTE: This was tested on 3.5.4, but massaged to apply on a recent stable
head--in any case this should be carefully reviewed by someone who knows the
code well, in case that wasn't obvious anyhow.
This version completely avoids any new state that could need to be spilled
to RAM, and instead re-checks existence and non-zeroness of the tag. What
do you think?
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index a810987..561e130 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -82,6 +82,8 @@ static inline int is_vlan_dev(struct net_device *dev)
}
#define vlan_tx_tag_present(__skb) ((__skb)->vlan_tci & VLAN_TAG_PRESENT)
+#define vlan_tx_nonzero_tag_present(__skb) \
+ (vlan_tx_tag_present(__skb) && ((__skb)->vlan_tci & VLAN_VID_MASK))
#define vlan_tx_tag_get(__skb) ((__skb)->vlan_tci & ~VLAN_TAG_PRESENT)
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
@@ -91,7 +93,7 @@ extern struct net_device *__vlan_find_dev_deep(struct
net_device *real_dev,
extern struct net_device *vlan_dev_real_dev(const struct net_device *dev);
extern u16 vlan_dev_vlan_id(const struct net_device *dev);
-extern bool vlan_do_receive(struct sk_buff **skb, bool last_handler);
+extern bool vlan_do_receive(struct sk_buff **skb);
extern struct sk_buff *vlan_untag(struct sk_buff *skb);
extern int vlan_vid_add(struct net_device *dev, unsigned short vid);
@@ -120,10 +122,8 @@ static inline u16 vlan_dev_vlan_id(const struct net_device
*dev)
return 0;
}
-static inline bool vlan_do_receive(struct sk_buff **skb, bool last_handler)
+static inline bool vlan_do_receive(struct sk_buff **skb)
{
- if (((*skb)->vlan_tci & VLAN_VID_MASK) && last_handler)
- (*skb)->pkt_type = PACKET_OTHERHOST;
return false;
}
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 8ca533c..f981d37 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -5,7 +5,7 @@
#include
#include "vlan.h"
-bool vlan_do_receive(struct sk_buff **skbp, bool last_handler)
+bool vlan_do_receive(struct sk_buff **skbp)
{
struct sk_buff *skb = *skbp;
u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
@@ -13,14 +13,8 @@ bool vlan_do_receive(struct sk_buff **skbp, bool
last_handler)
struct vlan_pcpu_stats *rx_stats;
vlan_dev = vlan_find_dev(skb->dev, vlan_id);
- if (!vlan_dev) {
- /* Only the last call to vlan_do_receive() should change
-* pkt_type to PACKET_OTHERHOST
-*/
- if (vlan_id && last_handler)
- skb->pkt_type = PACKET_OTHERHOST;
+ if (!vlan_dev)
return false;
- }
skb = *skbp = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
diff --git a/net/core/dev.c b/net/core/dev.c
index 8398836..c580708 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3273,18 +3273,18 @@ ncls:
&& !skb_pfmemalloc_protocol(skb))
goto drop;
- rx_handler = rcu_dereference(skb->dev->rx_handler);
if (vlan_tx_tag_present(skb)) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
- if (vlan_do_receive(, !rx_handler))
+ if (vlan_do_receive())
goto another_round;
else if (unlikely(!skb))
goto unlock;
}
+ rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
@@ -3304,6 +3304,9 @@ ncls:
}
Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs
On Mon, Oct 08, 2012 at 02:41:31AM +0200, Christoph Anton Mitterer wrote: > I just wondered because I remembered David Shaw (one of the main > developers from gpg) to imply[0] some time ago, that an "evil" entropy > source would actually be a problem: I've looked at his message, I didn't see any justification for his concern/assertion. So I can't really comment on it since he didn't give any reason for his belief. > Some notes though (guess you're the maintainer anyway): > 1) With respect to the sources of entropy... would it make sense for the > kernel to follow ideas from haveged[1]. > I mean we all now that especially disk-less server systems have problems > with the current sources. > Or is that intended to be kept in userspace? We've made a lot of changes in how we gather entropy recently, so that we're gathering a lot more entropy even on disk-less server systems. We are using the time stamp counter, so in some ways we are using a scheme which isn't that far off from haveged. Historically, /dev/random was created back before high resolution counters were not always available on all CPU's, and so we depended on interrupts being unpredictable. What haveged does instead is to depend on cycle counters, and count on some amount of uncertainty to cause differences in the expected cycle counter when performing a known fixed workload. What we are now doing is depending on the cycle counter on interrupts which are will be at least as unpredictable and probably more so, than haveged's fixed workload. That's because we have an avantage of having access to the interrupt timing information, which is something haveged doesn't have, since it is a userspace solution. So I think what we have right now in /dev/random is better than what haveged has as a userspace-only collection algorithm. > 2) At some places, the documentation mentiones that SHA is used... any > sense in "upgrading" to stronger/more secure (especially as it says the > hash is used to protect the internal state of the pool) and faster > algos? We're not using SHA has a traditional cryptographic hash; so the weaknesses caused by being able to find collisions in somewhat faster than brute force aren't a problem. We are hashing 4k bits of input to produce 80 bits of output (we take the 160 bits output of SHA-1 and xor them togethre to fold what we expose to the outside world to only 80 bits). So there will always be collisions --- the pigeon hole princple states that with 2**4096 possible inputs, and only 2**80 possible outputs, there will be definitely be collisions where multiple inputs result in the same hash. The trick is being able to find all of the possible collisions --- and then being able to figure out which one was really the one that represents the state of the entropy pool at a particular point in time. This is a very different sort of analysis than simply being able to find two known inputs that result in the same output. So I'm not particularly worried at this point. The other thing to note is that the possible alternatives to SHA-1 (i.e., SHA-2 and SHA-3) are actually slower, not faster. So we would be giving up performance if we were to use them. > 3) Some places note that things are not so cryptographically strong... > which sounds a bit worrying... There is a specific tradeoff going in these places. For example, there are certain TCP hijacking attacks where so long as we can prevent the attacker from being able to guess the next TCP sequence number in less than say, five or ten minutes, we are fine. We don't need to protect this "secret" for more than a very limited amount of time. In addiiton, networking performance is very important. If it took several seconds to establish a TCP conneciton --- that would be bad; consider what that would do for a web server! The bottom line is that strength is not the only thing that we have to engineer for. If we did that for airplanes, for example, they would never fly or require so much fuel as to be economically impractical. Good engineering is to understand what strength is require, adding a appropriate safety margin, and then saying, *enough*. > 4) Were "newer" developments in PRNGs already taken into account? E.g. > the Mersenne Twister (which is AFAIK however not cryptographically > secure; at least in it's native form) The problems solved by the Mersenne Twister are quite different from the problems we are trying to solve in a cryptographic random number generator. PRNG's and CRNG's are very different animals. You might as well ask a basketball coach if they have taken into account the latest scocer strategies... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 174/262] x86, avx: dont use avx instructions with "noxsave" boot param
On Mon, 2012-10-08 at 07:55 +0800, H. Peter Anvin wrote: > Userland should use a different query mechanism. On the other hand, > it will not hurt either. On pre-xsave kernels AVX is a non-option. [...] OK, having looked at what the SDM says I agree that there shouldn't be a problem for userland. Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp signature.asc Description: This is a digitally signed message part
Re: [PATCH] regmap: silence GCC warning
On Sat, Oct 06, 2012 at 11:57:36AM +0200, Paul Bolle wrote: > 2) I hope to send in a second path shortly, changing 'num' to size_t. My > main doubt is whether its problematic that the loop index in > regmap_volatile_range() uses unsigned int too. If 'num' would exceed > UINT_MAX, that loop would never finish, wouldn't it? But is that > actually possible? Are there machines with that many registers? It's possible, of course - people can give whatever random numbers they like to registers. It's not particularly likely, though, so probably as well not to worry about it until it's actually a problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote: > On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote: > > > > I think Kconfig is mostly what distro would like to use the thing is > > > the Kconfig text needs to be there upfront when its merged, not two > > > months later, since then it too late for a distro to notice. > > > > > > I'd bet most distros would read the warnings, but in a lot of cases > > > the warning don't exist until its too late. > > > > In the case of CONFIG_RCU_USER_QS you are quite right, the warning > > should have been there from the beginning and was not. I suppose you > > could argue that the warning was not sufficiently harsh in the case of > > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored: > > Maybe if we had a universally agreed upon tag for kconfig, like > "distro recommendation: N" that would make things obvious, and also allow > those of us unfortunate enough to maintain distro kernels to have something > to easily grep for. This would also catch the case when you eventually > (hopefully) > flip from an N to a Y. > > There will likely still be some distros that will decide they know better > (and I'm pretty sure eventually I'll find reason to do so myself), but it at > least > gives the feature maintainer the "I told you so" clause. > > Something we do quite often for our in-development kernels is enable something > that's shiny, new and unproven, and then when we branch for a release, we turn > it back off. It would be great if a lot of this kind of thing could be more > automated. One approach would be to have CONFIG_DISTRO, so that experimental features could use "depends on !DISTRO", but also to have multiple "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually use the following clause: depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT A normal distro would define DISTRO, a distro looking to provide bleeding-edge HPC or real-time features would also define DISTRO_BLEEDING_HPC or DISTRO_BLEEDING_RT, respectively. Does that make sense, or am I being overly naive? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: r8712u: fix potential NULL pointer dereference in r871x_wps_start()
On 10/07/2012 07:43 PM, Wei Yongjun wrote: From: Wei Yongjun The dereference should be moved below the NULL test. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun --- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Larry Finger Thanks, Larry diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c index c9a6a7f..3a64790 100644 --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c @@ -2110,10 +2110,10 @@ static int r871x_wps_start(struct net_device *dev, struct iw_point *pdata = >data; u32 u32wps_start = 0; - if (copy_from_user((void *)_start, pdata->pointer, 4)) - return -EFAULT; if ((padapter->bDriverStopped) || (pdata == NULL)) return -EINVAL; + if (copy_from_user((void *)_start, pdata->pointer, 4)) + return -EFAULT; if (u32wps_start == 0) u32wps_start = *extra; if (u32wps_start == 1) /* WPS Start */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RESEND PATCH v4 0/2] ACPI: DBGP/DBG2 early console support for LPIA.
> go ahead and take the series in tip 3.8, Peter, thanks.
>
> I looked over this series a while back and my feedback was that it should be
> disabled by default and enabled by bootparam -- like other earlyprink -- else
> an
> issue here would render a system un-bootable. I see that LV has addressed
> that in the latest version.
> LV,
> have you addressed the feedback from Konrad?
I missed the mail from Konrad. Thanks for your reminder.
I'll find it and update my patches according to his suggestion.
Best regards/Lv Zheng
N�r��yb�X��ǧv�^�)Þº{.n�+{zX����ܨ}ï¿½ï¿½ï¿½Æ z�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jÇ«y�m��@A�a���
0��h���i
linux-next: manual merge of the ia64 tree with the asm-generic tree
Hi all,
Today's linux-next merge of the ia64 tree got a conflict in
arch/ia64/include/asm/Kbuild between commit e7a570ff7dff ("asm-generic:
Add default clkdev.h") from the asm-generic tree and commit f68301fee715
("UAPI: (Scripted) Disintegrate arch/ia64/include/asm") from the ia64
tree.
I fixed it up (see below - I am not sure if this is the correct fix) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/ia64/include/asm/Kbuild
index 58f3d14,e69de29..000
--- a/arch/ia64/include/asm/Kbuild
+++ b/arch/ia64/include/asm/Kbuild
@@@ -1,16 -1,0 +1,1 @@@
- include include/asm-generic/Kbuild.asm
-
- header-y += break.h
- header-y += cmpxchg.h
- header-y += fpu.h
- header-y += gcc_intrin.h
- header-y += ia64regs.h
- header-y += intel_intrin.h
- header-y += intrinsics.h
- header-y += perfmon.h
- header-y += perfmon_default_smpl.h
- header-y += ptrace_offsets.h
- header-y += rse.h
- header-y += ucontext.h
- header-y += ustack.h
+generic-y += clkdev.h
pgp6u6qpiwnJW.pgp
Description: PGP signature
linux-next: manual merge of the modules tree with Linus' tree
Hi Rusty,
Today's linux-next merge of the modules tree got a conflict in
init/Kconfig between commit 754b7b63d112 ("sections: disable const
sections for PA-RISC v2") from Linus' tree and commit 54ddd23d78ba
("X.509: Add simple ASN.1 grammar compiler") from the modules tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
BTW, Rusty, that commit from the modules tree has no SOB from you even
though you committed it.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc init/Kconfig
index ed6334d,abc6e63..000
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -1582,10 -1672,12 +1642,18 @@@ config PADAT
depends on SMP
bool
+# Can be selected by architectures with broken toolchains
+# that get confused by correct const<->read_only section
+# mappings
+config BROKEN_RODATA
+ bool
+
+ config ASN1
+ tristate
+ help
+ Build a simple ASN.1 grammar compiler that produces a bytecode output
+ that can be interpreted by the ASN.1 stream decoder and used to
+ inform it as to what tags are to be expected in a stream and what
+ functions to call on what tags.
+
source "kernel/Kconfig.locks"
pgpb8FmbzRfdo.pgp
Description: PGP signature
Re: [PATCH] drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()
On Mon, Oct 08, 2012 at 08:41:36AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference should be moved below the NULL test.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/misc/ti-st/st_core.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> index 46937b1..ee341ea 100644
> --- a/drivers/misc/ti-st/st_core.c
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -511,13 +511,14 @@ long st_register(struct st_proto_s *new_proto)
> unsigned long flags = 0;
>
> st_kim_ref(_gdata, 0);
> - pr_info("%s(%d) ", __func__, new_proto->chnl_id);
> if (st_gdata == NULL || new_proto == NULL || new_proto->recv == NULL
> || new_proto->reg_complete_cb == NULL) {
> pr_err("gdata/new_proto/recv or reg_complete_cb not ready");
> return -EINVAL;
> }
>
> + pr_info("%s(%d) ", __func__, new_proto->chnl_id);
Why print this at all? Can't you just drop it now?
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Drivers: hv: Add Hyper-V balloon driver
On Sun, Oct 07, 2012 at 04:59:46PM -0700, K. Y. Srinivasan wrote: > +config HYPERV_BALLOON > + tristate "Microsoft Hyper-V Balloon driver" > + depends on HYPERV > + help > + Select this option to enable the Hyper-V Utilities. Your help text is wrong :( > --- /dev/null > +++ b/drivers/hv/hv_balloon.c > @@ -0,0 +1,1043 @@ > +/* > + * Copyright (c) 2012, Microsoft Corporation. > + * > + * Author: > + * K. Y. Srinivasan > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > + * by the Free Software Foundation. > + * > + * 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, GOOD TITLE or > + * NON INFRINGEMENT. See the GNU General Public License for more > + * details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Unless you promise to keep track of the FSF's office buildings for the next 40+ years, just drop this paragraph entirely. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm: Export vm_committed_as
On Sun, Oct 07, 2012 at 04:59:45PM -0700, K. Y. Srinivasan wrote: > The policy engine on the host expects the guest to report the > committed_as. Since this variable is not exported, > export this symbol. Why are these symbols not needed by either Xen or KVM or vmware, which I think all support the same thing, right? > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -87,6 +87,7 @@ int sysctl_max_map_count __read_mostly = > DEFAULT_MAX_MAP_COUNT; > * other variables. It can be updated by several CPUs frequently. > */ > struct percpu_counter vm_committed_as cacheline_aligned_in_smp; > +EXPORT_SYMBOL(vm_committed_as); > > /* > * Check that a process has enough memory to allocate a new virtual > diff --git a/mm/nommu.c b/mm/nommu.c > index 45131b4..3914b7e 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -68,6 +68,7 @@ atomic_long_t mmap_pages_allocated; > > EXPORT_SYMBOL(mem_map); > EXPORT_SYMBOL(num_physpages); > +EXPORT_SYMBOL(vm_committed_as); EXPORT_SYMBOL_GPL() for these new ones? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: r8712u: fix potential NULL pointer dereference in r871x_wps_start()
From: Wei Yongjun The dereference should be moved below the NULL test. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun --- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c index c9a6a7f..3a64790 100644 --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c @@ -2110,10 +2110,10 @@ static int r871x_wps_start(struct net_device *dev, struct iw_point *pdata = >data; u32 u32wps_start = 0; - if (copy_from_user((void *)_start, pdata->pointer, 4)) - return -EFAULT; if ((padapter->bDriverStopped) || (pdata == NULL)) return -EINVAL; + if (copy_from_user((void *)_start, pdata->pointer, 4)) + return -EFAULT; if (u32wps_start == 0) u32wps_start = *extra; if (u32wps_start == 1) /* WPS Start */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs
Hi Ted. Thanks for your prompt reply. On Thu, 2012-10-04 at 18:49 -0400, Theodore Ts'o wrote: > It is impossible by design. Or specifically, /dev/random was designed > so that it can be world-writeable, and an attacker can feed in any > kind of input he or she wants, and it will not allow the attacker to > know anything more about the state of the entropy pool than he or she > knew before they started mixing inputs in. I just wondered because I remembered David Shaw (one of the main developers from gpg) to imply[0] some time ago, that an "evil" entropy source would actually be a problem: > Not completely useless given the Linux random design, but > certainly an evil source of entropy would be a serious problem. " > There are comments that go into more detail about the design in > drivers/char/random.c. I had a short glance at it,... but I guess it goes a bit above my understanding of entropy theory... well at least without without putting some effort into it. Some notes though (guess you're the maintainer anyway): 1) With respect to the sources of entropy... would it make sense for the kernel to follow ideas from haveged[1]. I mean we all now that especially disk-less server systems have problems with the current sources. Or is that intended to be kept in userspace? 2) At some places, the documentation mentiones that SHA is used... any sense in "upgrading" to stronger/more secure (especially as it says the hash is used to protect the internal state of the pool) and faster algos? 3) Some places note that things are not so cryptographically strong... which sounds a bit worrying... 4) Were "newer" developments in PRNGs already taken into account? E.g. the Mersenne Twister (which is AFAIK however not cryptographically secure; at least in it's native form) Thanks again, Chris. [0] http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037301.html [1] http://www.issihosts.com/haveged/ [2] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html smime.p7s Description: S/MIME cryptographic signature
[PATCH] drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()
From: Wei Yongjun
The dereference should be moved below the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
---
drivers/misc/ti-st/st_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
index 46937b1..ee341ea 100644
--- a/drivers/misc/ti-st/st_core.c
+++ b/drivers/misc/ti-st/st_core.c
@@ -511,13 +511,14 @@ long st_register(struct st_proto_s *new_proto)
unsigned long flags = 0;
st_kim_ref(_gdata, 0);
- pr_info("%s(%d) ", __func__, new_proto->chnl_id);
if (st_gdata == NULL || new_proto == NULL || new_proto->recv == NULL
|| new_proto->reg_complete_cb == NULL) {
pr_err("gdata/new_proto/recv or reg_complete_cb not ready");
return -EINVAL;
}
+ pr_info("%s(%d) ", __func__, new_proto->chnl_id);
+
if (new_proto->chnl_id >= ST_MAX_CHANNELS) {
pr_err("chnl_id %d not supported", new_proto->chnl_id);
return -EPROTONOSUPPORT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm for 3.7-rc1 (part 2)
Hi Linus, This is the follow-up pull, 3 pieces a) exynos next stuff, was delayed but looks okay to me, one patch in v4l bits but it was acked by v4l person. b) UAPI disintegration bits c) intel fixes - DP fixes, hang fixes, other misc fixes. Dave. The following changes since commit 0b8e74c6f44094189dbe78baf4101acc7570c6af: Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2012-10-07 17:49:05 +0900) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-next for you to fetch changes up to 1f31c69dac71bebc0f00bc8534a6345782045501: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-10-07 21:13:54 +1000) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (2): drm/i915: Fix set_caching locking drm/i915: Fix GT_MODE default value Chris Wilson (3): drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Try harder to complete DP training pattern 1 Daniel Vetter (2): drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: don't frob the vblank ts in finish_page_flip Dave Airlie (3): Merge branch 'disintegrate-drm' of git://git.infradead.org/users/dhowells/linux-headers into drm-next Merge branch 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next David Howells (1): UAPI: (Scripted) Disintegrate include/drm Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Inki Dae (16): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: separated subdrv_probe function into two parts. drm/exynos: separeated fimd_power_on into some parts. drm/exynos: fixed duplicated mode setting. drm/exynos: add wait_for_vblank callback interface. drm/exynos: make sure that hardware overlay for fimd is disabled drm/exynos: make sure that hardware overlay for hdmi is disabled drm/exynos: check NV12M format specific to Exynos properly drm/exynos: update crtc to plane safely drm/exynos: Disable plane when released drm/exynos: add pid to g2d_runqueue_node drm/exynos: fix duplicated mutex lock issue drm/exynos: check crtc's dpms mode at page flip drm/exynos: check crtc's dpms mode at SetCrtc drm/exynos: support drm_wait_vblank feature for VIDI drm/exynos: fix display power call issue. Jani Nikula (1): drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag Jesse Barnes (1): drm/i915: set swizzling to none on VLV Joonyoung Shim (2): drm/exynos: fix to calculate CRTC shown via screen drm/exynos: fix kcalloc size of g2d cmdlist node Leela Krishna Amudala (1): drm/exynos: add platform_device_id table and driver data for drm fimd Mika Kuoppala (1): drm/i915: print warning if vmi915_gem_fault error is not handled Rahul Sharma (9): drm: exynos: remove drm hdmi platform data struct drm: exynos: hdmi: add support for exynos5 ddc drm: exynos: hdmi: add support for exynos5 hdmiphy drm: exynos: hdmi: add support for platform variants for mixer drm: exynos: hdmi: add support to disable video processor in mixer drm: exynos: hdmi: add support for exynos5 mixer drm: exynos: hdmi: replace is_v13 with version check in hdmi drm: exynos: hdmi: add support for exynos5 hdmi drm: exynos: hdmi: remove drm common hdmi platform data struct Sachin Kamat (1): drm/exynos: Fix potential NULL pointer dereference Tomasz Stanislawski (5): media: s5p-hdmi: add HPD GPIO to platform data drm: exynos: hdmi: support for platform variants drm: exynos: hdmi: fix interrupt handling drm: exynos: hdmi: use s5p-hdmi platform data drm: exynos: hdmi: turn off HPD interrupt in HDMI chip drivers/gpu/drm/drm_edid.c|3 +- drivers/gpu/drm/exynos/exynos_ddc.c | 22 +- drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 +- drivers/gpu/drm/exynos/exynos_drm_connector.h |4 + drivers/gpu/drm/exynos/exynos_drm_core.c | 100 ++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 116 ++-
linux-next: manual merge of the sound tree with the v4l-dvb tree
Hi Takashi,
Today's linux-next merge of the sound tree got a conflict in
arch/arm/mach-davinci/include/mach/da8xx.h between commit 154d54a8ce99
("[media] ARM: davinci: da850: Add SoC related definitions for VPIF")
from the v4l-dvb tree and commit 896f66b7de29 ("ASoC/ARM: Davinci: McASP:
split asp header into platform and audio specific") from the sound tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-davinci/include/mach/da8xx.h
index 13d2295,c74a6ab..000
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@@ -16,18 -16,15 +16,18 @@@
#include
#include
#include
+ #include
+#include
#include
#include
- #include
-#include
-#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
+
+#include
extern void __iomem *da8xx_syscfg0_base;
extern void __iomem *da8xx_syscfg1_base;
pgpvPpl7WI9cR.pgp
Description: PGP signature
Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect
On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote: > 2012/10/6 PaX Team : > > sadly, this is not true at all, for multiple reasons: > > > .. snip ... > > > > cheers, > > PaX Team > > > > So can I summarize your position as that there is no merit at all in > the ability to inhibit future permissions of existing mappings? i believe i answered this in the previous mail already: > there's certainly a point (i've been doing it for 12 years now), but to > make an mprotect flag into an actual security feature, it had better pass > simple tests, such as non-circumventability. any method relying on > userland playing nice is already suspect of being the wrong way and right > now i don't see how PROT_FINAL could be used for actual security. so if PROT_FINAL wants to be useful, you'd have to present a case of how it does something useful *while* an exploited userland cannot get around it. in fact i think i already told you that presenting your own use case in more detail (read: source code, policy, etc) would be a great step in 'selling the idea'. the fact that you seem to be reluctant to follow up on this leaves me somewhat uneasy as it may be the sign of a proprietary vendor's trying to push some code into mainline that nobody else has a clear idea how it'd benefit the rest of us. you see, you're asking for a change in a system call, which is a very important boundary for kernel developers as they'll have to maintain it indefinitely. so the burden is on you to prove that either this is the only way to implement a useful feature or at least it is the optimal way as opposed to other approaches. i suggested you ways to both attack the initially presented concept and also how it may be improved, but i got no answers to them yet. cheers, PaX Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: It seems that /usr/bin/time program reports a wrong value for MaxRSS.
On Sun, 7 Oct 2012, Kamran Amini wrote: > On Sun, Oct 7, 2012 at 1:18 AM, Hugh Dickins wrote: > > On Thu, 4 Oct 2012, Kamran Amini wrote: > >> > >> It seems that /usr/bin/time program reports a wrong value for MaxRSS. > >> The report shows MaxRSS, about 4 times the > >> actual allocated memory by a process and its children. MaxRSS (Maximum > >> Resident Set Size) is assumed to be maximum > >> allocated memory by a process and its children. This bug report talks > >> about this problem. More descriptions are provided in > >> time-problem.tar.gz file attached to this mail. > > > > You are right. > > > > Well, time-problem.tar.gz goes into more detail than I had time > > to read, so I cannot promise that everything you say is right. > > > > But you're right that /usr/bin/time is reporting MaxRSS 4 times too much > > on x86, and many other architectures. It expects rusage.ru_maxrss to be > > a count of pages, so mistakenly uses to ptok() upon it; whereas the Linux > > kernel supplies that number already in kilobytes (as "man 2 getrusage" > > makes clear). > > > > I see this was mentioned when 2.6.32's commit 1f10206cf8e9 "getrusage: > > fill ru_maxrss value" started putting the number there instead of zero: > > > > Make ->ru_maxrss value in struct rusage filled accordingly to rss > > hiwater > > mark. This struct is filled as a parameter to getrusage syscall. > > ->ru_maxrss value is set to KBs which is the way it is done in BSD > > systems. /usr/bin/time (gnu time) application converts ->ru_maxrss to > > KBs > > which seems to be incorrect behavior. Maintainer of this util was > > notified by me with the patch which corrects it and cc'ed. > > > > It looks as if we were naive to expect a change in /usr/bin/time then: > > so far as I can see, time has stood still at time-1.7 ever since 1996. > > Its README does say: > > > > Mail suggestions and bug reports for GNU time to > > bug-gnu-ut...@prep.ai.mit.edu. Please include the version of > > `time', which you can get by running `time --version', and the > > operating system and C compiler you used. > > > > Please do so, if you have a chance, or let me know if you cannot and > > I'll do so: though I suspect the mail address is out-of-date by now, > > and that it should say bug-gnu-ut...@gnu.org. > > > > You might also like to raise a bug with the distros you care about: > > maybe some already apply their own fix, or will do before time-1.8. > > > > But it does look as if you're the first in three years to notice and > > care! So don't be surprised if it's not a high priority for anyone. > > > > And I don't think you need attach a .tar.gz: just explain in a few > > lines that Linux 2.6.32 and later fill ru_maxrss, but in kilobytes > > not pages: so /usr/bin/time displays 4 times the right number when > > it multiplies that up with ptok(). (I don't have a BSD system to > > confirm whether it's indeed wrong for BSD too.) > > > > Thanks, > > Hugh > > Thanks for the reply. > > I'm sorry. > I should have mentioned more details in my last email and I should Please don't drown me in so many words, we don't need more details! > have changed my subject to "It seems that wait4() system call fills > rusage.ru_maxrss with wrong value". > > Actually, we have read time's source code and there is no bug in it. Not necessarily a bug, but line 395 of time-1.7/time.c says fprintf (fp, "%lu", ptok ((UL) resp->ru.ru_maxrss)); and the comment on ptok (pages) has already mentioned that Note: Some machines express getrusage statistics in terms of K, others in terms of pages. */ > The time uses wait4() system call and k_getrusage() function in > kernel/sys.c, line 1765 makes that 4 coefficient. > >r->ru_maxrss = maxrss * (PAGE_SIZE / 1024); /* convert pages to KBs */ > > Comment says that this operation will convert the maxrss into KBs. > But we think it has been converted to KBs previously. It has not been converted to KBs previously; but /usr/bin/time mistakenly "converts it to KBs" a second time afterwards. The Linux kernel has chosen to report ru_maxrss in KBs, following BSD. I have not loaded up a BSD system to check, but I have now checked the FreeBSD getrusage(2) manpage online, and indeed that documents ru_maxrss as in kilobytes. So when Jiri Pirko made Linux kernel 2.6.32 fill ru_maxrss with something better than 0, he chose to follow BSD by doing it in KBs (a better, more portable, unit than number of pages anyway); and simultaneously alerted the time-1.7 maintainer (he doesn't mention who, and I didn't actually see the name in his mail's Cc list) that the BSD value was already shown wrongly, and the Linux value about to be shown wrongly. He and we thought it easier to keep BSD and Linux in synch, but no fix to the time package has appeared. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org
linux-next: build failure after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/cpu_cooling.c: In function 'get_idr':
drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first use
in this function)
Caused by commit 023614183768 ("thermal: add generic cpufreq cooling
implementation") interacting with commit 125c4c706b68 ("idr: rename
MAX_LEVEL to MAX_IDR_LEVEL") which very recently entered Linus' tree.
I have applied the following fix patch for today:
From: Stephen Rothwell
Date: Mon, 8 Oct 2012 10:56:56 +1100
Subject: [PATCH] thermal: fix for for MAX_ID_MASK to MAX_IDR_MASK rename
Signed-off-by: Stephen Rothwell
---
drivers/thermal/cpu_cooling.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 9050c1b..cc1c930 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -86,7 +86,7 @@ again:
else if (unlikely(err))
return err;
- *id = *id & MAX_ID_MASK;
+ *id = *id & MAX_IDR_MASK;
return 0;
}
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpPN49zvnBYD.pgp
Description: PGP signature
Re: [ 174/262] x86, avx: dont use avx instructions with "noxsave" boot param
Userland should use a different query mechanism. On the other hand, it will
not hurt either. On pre-xsave kernels AVX is a non-option.
Ben Hutchings wrote:
>On Fri, 2012-09-28 at 11:51 -0700, Greg Kroah-Hartman wrote:
>> From: Greg KH
>>
>> 3.5-stable review patch. If anyone has any objections, please let me
>know.
>>
>> --
>>
>> From: Suresh Siddha
>>
>> commit c6fd893da927c6cefb2ece22402765379921a834 upstream.
>>
>> Clear AVX, AVX2 features along with clearing XSAVE feature bits,
>> as part of the parsing "noxsave" parameter.
>>
>> Fixes the kernel boot panic with "noxsave" boot parameter.
>>
>> We could have checked cpu_has_osxsave along with cpu_has_avx etc, but
>Peter
>> mentioned clearing the feature bits will be better for uses like
>> static_cpu_has() etc.
>
>This was marked as needed for 3.5 only - presumably because the kernel
>wasn't using AVX before this - but don't we also need to clear these
>bits even in earlier versions so userland knows not to use it?
>
>Ben.
>
>> Signed-off-by: Suresh Siddha
>> Link:
>http://lkml.kernel.org/r/1343755754.2041.2.ca...@sbsiddha-desk.sc.intel.com
>> Signed-off-by: H. Peter Anvin
>> Signed-off-by: Greg Kroah-Hartman
>>
>> ---
>> arch/x86/kernel/cpu/common.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -144,6 +144,8 @@ static int __init x86_xsave_setup(char *
>> {
>> setup_clear_cpu_cap(X86_FEATURE_XSAVE);
>> setup_clear_cpu_cap(X86_FEATURE_XSAVEOPT);
>> +setup_clear_cpu_cap(X86_FEATURE_AVX);
>> +setup_clear_cpu_cap(X86_FEATURE_AVX2);
>> return 1;
>> }
>> __setup("noxsave", x86_xsave_setup);
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the acpi tree with Linus' tree
Hi Len,
Today's linux-next merge of the acpi tree got a conflict in
include/acpi/acpixf.h between commit d8dc91b753b8 ("Merge branch
'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux")
from Linus' tree and commit 558dc6f9ee2a ("Merge branch 'upstream' into
next") from the acpi tree (which, as I pointed out, fixed the merge
conflict incorrectly).
I just used the version from Linus' tree. Len, please fix up your "next"
branch.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgplYHTBB8Kan.pgp
Description: PGP signature
[ 018/108] dmaengine: at_hdmac: fix comment in atc_prep_slave_sg()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolas Ferre
commit c618a9be0e8c0f36baee2560860a0118a428fb26 upstream.
s/dma_memcpy/slave_sg/ and it is sg length that we are
talking about.
Signed-off-by: Nicolas Ferre
Signed-off-by: Vinod Koul
Signed-off-by: Ben Hutchings
---
drivers/dma/at_hdmac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 3934fcc..6c09e18 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -661,7 +661,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
flags);
if (unlikely(!atslave || !sg_len)) {
- dev_dbg(chan2dev(chan), "prep_dma_memcpy: length is zero!\n");
+ dev_dbg(chan2dev(chan), "prep_slave_sg: sg length is zero!\n");
return NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 019/108] dmaengine: at_hdmac: check that each sg data length is non-null
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolas Ferre
commit c456797681db814f4f5b36909e8e94047bf53d9c upstream.
Avoid the construction of a malformed DMA request sent to
the DMA controller.
Log message is for debug only because this condition is unlikely to
append and may only trigger at driver development time.
Signed-off-by: Nicolas Ferre
Signed-off-by: Vinod Koul
Signed-off-by: Ben Hutchings
---
drivers/dma/at_hdmac.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 6c09e18..7ab6e26 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -689,6 +689,11 @@ atc_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
mem = sg_dma_address(sg);
len = sg_dma_len(sg);
+ if (unlikely(!len)) {
+ dev_dbg(chan2dev(chan),
+ "prep_slave_sg: sg(%d) data length is
zero\n", i);
+ goto err;
+ }
mem_width = 2;
if (unlikely(mem & 3 || len & 3))
mem_width = 0;
@@ -724,6 +729,11 @@ atc_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
mem = sg_dma_address(sg);
len = sg_dma_len(sg);
+ if (unlikely(!len)) {
+ dev_dbg(chan2dev(chan),
+ "prep_slave_sg: sg(%d) data length is
zero\n", i);
+ goto err;
+ }
mem_width = 2;
if (unlikely(mem & 3 || len & 3))
mem_width = 0;
@@ -757,6 +767,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
err_desc_get:
dev_err(chan2dev(chan), "not enough descriptors available\n");
+err:
atc_desc_put(atchan, first);
return NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 013/108] sched: Fix ancient race in do_exit()
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Yasunori Goto commit b5740f4b2cb3503b436925eb2242bc3d75cd3dfe upstream. try_to_wake_up() has a problem which may change status from TASK_DEAD to TASK_RUNNING in race condition with SMI or guest environment of virtual machine. As a result, exited task is scheduled() again and panic occurs. Here is the sequence how it occurs: --+- | CPU A | CPU B --+- TASK A calls exit() do_exit() exit_mm() down_read(mm->mmap_sem); rwsem_down_failed_common() set TASK_UNINTERRUPTIBLE set waiter.task <= task A list_add to sem->wait_list : raw_spin_unlock_irq() (I/O interruption occured) __rwsem_do_wake(mmap_sem) list_del(>list); waiter->task = NULL wake_up_process(task A) try_to_wake_up() (task is still TASK_UNINTERRUPTIBLE) p->on_rq is still 1.) ttwu_do_wakeup() (*A) : (I/O interruption handler finished) if (!waiter.task) schedule() is not called due to waiter.task is NULL. tsk->state = TASK_RUNNING : check_preempt_curr(); : task->state = TASK_DEAD (*B) <---set TASK_RUNNING (*C) schedule() (exit task is running again) BUG_ON() is called! The execution time between (*A) and (*B) is usually very short, because the interruption is disabled, and setting TASK_RUNNING at (*C) must be executed before setting TASK_DEAD. HOWEVER, if SMI is interrupted between (*A) and (*B), (*C) is able to execute AFTER setting TASK_DEAD! Then, exited task is scheduled again, and BUG_ON() is called If the system works on guest system of virtual machine, the time between (*A) and (*B) may be also long due to scheduling of hypervisor, and same phenomenon can occur. By this patch, do_exit() waits for releasing task->pi_lock which is used in try_to_wake_up(). It guarantees the task becomes TASK_DEAD after waking up. Signed-off-by: Yasunori Goto Acked-by: Oleg Nesterov Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Link: http://lkml.kernel.org/r/20120117174031.3118.e1e9c...@jp.fujitsu.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings --- kernel/exit.c | 16 1 file changed, 16 insertions(+) --- a/kernel/exit.c +++ b/kernel/exit.c @@ -1019,6 +1019,22 @@ NORET_TYPE void do_exit(long code) preempt_disable(); exit_rcu(); + + /* +* The setting of TASK_RUNNING by try_to_wake_up() may be delayed +* when the following two conditions become true. +* - There is race condition of mmap_sem (It is acquired by +* exit_mm()), and +* - SMI occurs before setting TASK_RUNINNG. +* (or hypervisor of virtual machine switches to other guest) +* As a result, we may become TASK_RUNNING after becoming TASK_DEAD +* +* To avoid it, we have to wait for releasing tsk->pi_lock which +* is held by try_to_wake_up() +*/ + smp_mb(); + raw_spin_unlock_wait(>pi_lock); + /* causes final put_task_struct in finish_task_switch(). */ tsk->state = TASK_DEAD; schedule(); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 012/108] cpufreq/powernow-k8: workqueue user shouldnt migrate the kworker to another CPU
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 upstream.
powernowk8_target() runs off a per-cpu work item and if the
cpufreq_policy->cpu is different from the current one, it migrates the
kworker to the target CPU by manipulating current->cpus_allowed. The
function migrates the kworker back to the original CPU but this is
still broken. Workqueue concurrency management requires the kworkers
to stay on the same CPU and powernowk8_target() ends up triggerring
BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
fidvid_mutex and sleeps.
It is unclear why this bug is being reported now. Duncan says it
appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool
instead of @gcwq or @cpu where applicable" which is an non-functional
change. Given that the reproduce case sometimes took upto days to
trigger, it's easy to be misled while bisecting. Maybe something made
contention on fidvid_mutex more likely? I don't know.
This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
isn't the same as the current one. The code assumes that
cpufreq_policy->cpu is kept online by the caller, which Rafael tells
me is the case.
stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using
system_wq") should be applied before this; otherwise, the
behavior could be horrible.
Signed-off-by: Tejun Heo
Reported-by: Duncan <1i5t5.dun...@cox.net>
Tested-by: Duncan <1i5t5.dun...@cox.net>
Cc: Rafael J. Wysocki
Cc: Andreas Herrmann
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
Signed-off-by: Ben Hutchings
---
drivers/cpufreq/powernow-k8.c | 63 ++---
1 file changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index c0e8164..1a40935 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include/* for current / set_cpus_allowed() */
#include
#include
@@ -1139,16 +1138,23 @@ static int transition_frequency_pstate(struct
powernow_k8_data *data,
return res;
}
-/* Driver entry point to switch to the target frequency */
-static int powernowk8_target(struct cpufreq_policy *pol,
- unsigned targfreq, unsigned relation)
+struct powernowk8_target_arg {
+ struct cpufreq_policy *pol;
+ unsignedtargfreq;
+ unsignedrelation;
+};
+
+static long powernowk8_target_fn(void *arg)
{
- cpumask_var_t oldmask;
+ struct powernowk8_target_arg *pta = arg;
+ struct cpufreq_policy *pol = pta->pol;
+ unsigned targfreq = pta->targfreq;
+ unsigned relation = pta->relation;
struct powernow_k8_data *data = per_cpu(powernow_data, pol->cpu);
u32 checkfid;
u32 checkvid;
unsigned int newstate;
- int ret = -EIO;
+ int ret;
if (!data)
return -EINVAL;
@@ -1156,29 +1162,16 @@ static int powernowk8_target(struct cpufreq_policy *pol,
checkfid = data->currfid;
checkvid = data->currvid;
- /* only run on specific CPU from here on. */
- /* This is poor form: use a workqueue or smp_call_function_single */
- if (!alloc_cpumask_var(, GFP_KERNEL))
- return -ENOMEM;
-
- cpumask_copy(oldmask, tsk_cpus_allowed(current));
- set_cpus_allowed_ptr(current, cpumask_of(pol->cpu));
-
- if (smp_processor_id() != pol->cpu) {
- printk(KERN_ERR PFX "limiting to cpu %u failed\n", pol->cpu);
- goto err_out;
- }
-
if (pending_bit_stuck()) {
printk(KERN_ERR PFX "failing targ, change pending bit set\n");
- goto err_out;
+ return -EIO;
}
pr_debug("targ: cpu %d, %d kHz, min %d, max %d, relation %d\n",
pol->cpu, targfreq, pol->min, pol->max, relation);
if (query_current_values_with_pending_wait(data))
- goto err_out;
+ return -EIO;
if (cpu_family != CPU_HW_PSTATE) {
pr_debug("targ: curr fid 0x%x, vid 0x%x\n",
@@ -1196,7 +1189,7 @@ static int powernowk8_target(struct cpufreq_policy *pol,
if (cpufreq_frequency_table_target(pol, data->powernow_table,
targfreq, relation, ))
- goto err_out;
+ return -EIO;
mutex_lock(_mutex);
@@ -1209,9 +1202,8 @@ static int powernowk8_target(struct cpufreq_policy *pol,
ret = transition_frequency_fidvid(data, newstate);
if (ret) {
printk(KERN_ERR PFX "transition frequency failed\n");
- ret = 1;
mutex_unlock(_mutex);
- goto
[ 001/108] target: Fix ->data_length re-assignment bug with SCSI overflow
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit 4c054ba63ad47ef244cfcfa1cea38134620a5bae upstream.
This patch fixes a long-standing bug with SCSI overflow handling
where se_cmd->data_length was incorrectly being re-assigned to
the larger CDB extracted allocation length, resulting in a number
of fabric level errors that would end up causing a session reset
in most cases. So instead now:
- Only re-assign se_cmd->data_length durining UNDERFLOW (to use the
smaller value)
- Use existing se_cmd->data_length for OVERFLOW (to use the smaller
value)
This fix has been tested with the following CDB to generate an
SCSI overflow:
sg_raw -r512 /dev/sdc 28 0 0 0 0 0 0 0 9 0
Tested using iscsi-target, tcm_qla2xxx, loopback and tcm_vhost fabric
ports. Here is a bit more detail on each case:
- iscsi-target: Bug with open-iscsi with overflow, sg_raw returns
-3584 bytes of data.
- tcm_qla2xxx: Working as expected, returnins 512 bytes of data
- loopback: sg_raw returns CHECK_CONDITION, from overflow rejection
in transport_generic_map_mem_to_cmd()
- tcm_vhost: Same as loopback
Reported-by: Roland Dreier
Cc: Roland Dreier
Cc: Christoph Hellwig
Cc: Boaz Harrosh
Signed-off-by: Nicholas Bellinger
Signed-off-by: Ben Hutchings
---
drivers/target/target_core_transport.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3039,15 +3039,20 @@ static int transport_generic_cmd_sequenc
/* Returns CHECK_CONDITION + INVALID_CDB_FIELD */
goto out_invalid_cdb_field;
}
-
+ /*
+* For the overflow case keep the existing fabric provided
+* ->data_length. Otherwise for the underflow case, reset
+* ->data_length to the smaller SCSI expected data transfer
+* length.
+*/
if (size > cmd->data_length) {
cmd->se_cmd_flags |= SCF_OVERFLOW_BIT;
cmd->residual_count = (size - cmd->data_length);
} else {
cmd->se_cmd_flags |= SCF_UNDERFLOW_BIT;
cmd->residual_count = (cmd->data_length - size);
+ cmd->data_length = size;
}
- cmd->data_length = size;
}
/* reject any command that we don't have a handler for */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][GPIO] Add IRQ edge setter to gpiolib
Hi Grant, Thomas, do you see any potential problems with this patch? It adds sysfs interface to change / set-up trigger edge from the kernel (currently not possible). BR, Drasko On Fri, Oct 5, 2012 at 3:16 PM, Drasko DRASKOVIC wrote: > On Fri, Oct 5, 2012 at 2:40 PM, Linus Walleij > wrote: >> On Fri, Oct 5, 2012 at 2:20 PM, Drasko DRASKOVIC >> Why not put the above text into the patch commit blurb? > > OK, I can add this easily. Makes sense. > > >> If I understand correctly the below more or less exports >> struct irq_chip to userspace, >> trying to hide it by instead exposing a property of the >> containing struct gpio_chip and it worries me. > > No, it should not. It operates only on already exported gpiochip > (similar to gpio_export_link()). > It just helps exported GPIO be configured in "interrupt" and not in > "normal" mode. > >> >> One possible comment is that you shouldn't >> add this to gpiolib, if you want to mess around with the >> irq_chip you should create sysfs entries for the irq_chip >> per se, then we can have a symbolic link from the >> gpio_chip to its irq_chip in sysfs, and you can follow that >> to change trigger flanks, right? > > I did not found any correlation between kernel space irq_chip and > gpiolib's internal stuctures describing interrupt. > > This patch implementation seems like reasonable solution to me, but > still leaves possibility for someone to configure GPIO interrupt mode > internally (within driver) different than it is declared lately to > sysfs by calling my function... > > Otherwise, a pointer to an edge set-up kernel function can be added to > the gpio_chip structure, but I think it will be slightly more > complicated, and will fall back to the same thing. > >> >> Part of me doesn't like it when userspace is messing >> around with this kind of thing. Why can't this be set >> up from the kernel itself by some jam table? >> >> I can understand it if this is some lab board with GPIO >> or so, if it's some embedded GPIO controller within >> a laptop or something it surely should be in kernelspace. > > Yes, it is intended for embedded devices, where most (if not all) of > GPIO configuration should be done by the kernel, but also this > configuration should be appropriately exported to sysfs, so that > user-space applications could start using it right after the boot. > > >> So please detail your usecase a bit... what is the code >> daemon etc in userspace poking around at these pins? >> What is is doing and why? > > Right now, sysfs exposes interface like this for GPIO IRQ type configuration : > > # cat /sys/class/gpio/gpioX/edge > none > # echo rising > /sys/class/gpio/gpioX/edge > > This example puts GPIO pin X into "interrupt" mode, and declares it's > "type" i.e. that it triggers on rising edge. > > In the world of embedded, system configuratio which tells which GPIO > pins should be configured in "interrupt" mode (and what is their > trigger type) is kept in some format usually known only to the kernel > driver. We have no need to export this format to the user space, so > that rc scripts for example would know to parse GPIO configuration and > execute operations I mentioned above. > > To avoid that this is done from the user space, a function accesible > to kernel is needed. > > BR, > Drasko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 095/108] net: small bug on rxhash calculation
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Chema Gonzalez
[ Upstream commit 6862234238e84648c305526af2edd98badcad1e0 ]
In the current rxhash calculation function, while the
sorting of the ports/addrs is coherent (you get the
same rxhash for packets sharing the same 4-tuple, in
both directions), ports and addrs are sorted
independently. This implies packets from a connection
between the same addresses but crossed ports hash to
the same rxhash.
For example, traffic between A=S:l and B=L:s is hashed
(in both directions) from {L, S, {s, l}}. The same
rxhash is obtained for packets between C=S:s and D=L:l.
This patch ensures that you either swap both addrs and ports,
or you swap none. Traffic between A and B, and traffic
between C and D, get their rxhash from different sources
({L, S, {l, s}} for A<->B, and {L, S, {s, l}} for C<->D)
The patch is co-written with Eric Dumazet
Signed-off-by: Chema Gonzalez
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/core/dev.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 832ba6d..a4a0c5a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2686,16 +2686,17 @@ ipv6:
nhoff += poff;
if (pskb_may_pull(skb, nhoff + 4)) {
ports.v32 = * (__force u32 *) (skb->data + nhoff);
- if (ports.v16[1] < ports.v16[0])
- swap(ports.v16[0], ports.v16[1]);
skb->l4_rxhash = 1;
}
}
/* get a consistent hash (same value on both flow directions) */
- if (addr2 < addr1)
+ if (addr2 < addr1 ||
+ (addr2 == addr1 &&
+ports.v16[1] < ports.v16[0])) {
swap(addr1, addr2);
-
+ swap(ports.v16[0], ports.v16[1]);
+ }
hash = jhash_3words(addr1, addr2, ports.v32, hashrnd);
if (!hash)
hash = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 016/108] brcmfmac: fix big endian bug in i-scan.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Hante Meuleman
commit ed205b361956c96e0d8c09a8c9135a6a79cd9541 upstream.
ssid len is 32 bit and needs endian conversion for big endian systems.
Signed-off-by: Hante Meuleman
Signed-off-by: Arend van Spriel
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index c36e923..50b5553 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -500,8 +500,10 @@ static void wl_iscan_prep(struct brcmf_scan_params_le
*params_le,
params_le->active_time = cpu_to_le32(-1);
params_le->passive_time = cpu_to_le32(-1);
params_le->home_time = cpu_to_le32(-1);
- if (ssid && ssid->SSID_len)
- memcpy(_le->ssid_le, ssid, sizeof(struct brcmf_ssid));
+ if (ssid && ssid->SSID_len) {
+ params_le->ssid_le.SSID_len = cpu_to_le32(ssid->SSID_len);
+ memcpy(_le->ssid_le.SSID, ssid->SSID, ssid->SSID_len);
+ }
}
static s32
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 014/108] hpwdt: Fix kdump issue in hpwdt
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Toshi Kani commit 308b135e4fcc00c80c07e0e04e7afa8edf78583c upstream. kdump can be interrupted by watchdog timer when the timer is left activated on the crash kernel. Changed the hpwdt driver to disable watchdog timer at boot-time. This assures that watchdog timer is disabled until /dev/watchdog is opened, and prevents watchdog timer to be left running on the crash kernel. Signed-off-by: Toshi Kani Tested-by: Lisa Mitchell Signed-off-by: Thomas Mingarelli Signed-off-by: Wim Van Sebroeck Signed-off-by: Ben Hutchings --- drivers/watchdog/hpwdt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c index 1eff743..ae60406 100644 --- a/drivers/watchdog/hpwdt.c +++ b/drivers/watchdog/hpwdt.c @@ -814,6 +814,9 @@ static int __devinit hpwdt_init_one(struct pci_dev *dev, hpwdt_timer_reg = pci_mem_addr + 0x70; hpwdt_timer_con = pci_mem_addr + 0x72; + /* Make sure that timer is disabled until /dev/watchdog is opened */ + hpwdt_stop(); + /* Make sure that we have a valid soft_margin */ if (hpwdt_change_timer(soft_margin)) hpwdt_change_timer(DEFAULT_MARGIN); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 017/108] brcmfmac: Fix big endian host configuration data.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Hante Meuleman
commit e020a83d0942a5aceac35986500c9834efc8707d upstream.
Fixes big endian host configuration parameters.
Reviewed-by: Arend Van Spriel
Signed-off-by: Hante Meuleman
Signed-off-by: Arend van Spriel
Signed-off-by: John W. Linville
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 26
1 file changed, 16 insertions(+), 10 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
@@ -775,8 +775,11 @@ static void brcmf_c_arp_offload_set(stru
{
char iovbuf[32];
int retcode;
+ __le32 arp_mode_le;
- brcmf_c_mkiovar("arp_ol", (char *)_mode, 4, iovbuf, sizeof(iovbuf));
+ arp_mode_le = cpu_to_le32(arp_mode);
+ brcmf_c_mkiovar("arp_ol", (char *)_mode_le, 4, iovbuf,
+ sizeof(iovbuf));
retcode = brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR,
iovbuf, sizeof(iovbuf));
retcode = retcode >= 0 ? 0 : retcode;
@@ -792,8 +795,11 @@ static void brcmf_c_arp_offload_enable(s
{
char iovbuf[32];
int retcode;
+ __le32 arp_enable_le;
- brcmf_c_mkiovar("arpoe", (char *)_enable, 4,
+ arp_enable_le = cpu_to_le32(arp_enable);
+
+ brcmf_c_mkiovar("arpoe", (char *)_enable_le, 4,
iovbuf, sizeof(iovbuf));
retcode = brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR,
iovbuf, sizeof(iovbuf));
@@ -814,10 +820,10 @@ int brcmf_c_preinit_dcmds(struct brcmf_p
char buf[128], *ptr;
u32 dongle_align = BRCMF_SDALIGN;
u32 glom = 0;
- u32 roaming = 1;
- uint bcn_timeout = 3;
- int scan_assoc_time = 40;
- int scan_unassoc_time = 40;
+ __le32 roaming_le = cpu_to_le32(1);
+ __le32 bcn_timeout_le = cpu_to_le32(3);
+ __le32 scan_assoc_time_le = cpu_to_le32(40);
+ __le32 scan_unassoc_time_le = cpu_to_le32(40);
int i;
brcmf_os_proto_block(drvr);
@@ -852,14 +858,14 @@ int brcmf_c_preinit_dcmds(struct brcmf_p
/* Setup timeout if Beacons are lost and roam is off to report
link down */
- brcmf_c_mkiovar("bcn_timeout", (char *)_timeout, 4, iovbuf,
+ brcmf_c_mkiovar("bcn_timeout", (char *)_timeout_le, 4, iovbuf,
sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
/* Enable/Disable build-in roaming to allowed ext supplicant to take
of romaing */
- brcmf_c_mkiovar("roam_off", (char *), 4,
+ brcmf_c_mkiovar("roam_off", (char *)_le, 4,
iovbuf, sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
@@ -874,9 +880,9 @@ int brcmf_c_preinit_dcmds(struct brcmf_p
sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_SCAN_CHANNEL_TIME,
-(char *)_assoc_time, sizeof(scan_assoc_time));
+(char *)_assoc_time_le, sizeof(scan_assoc_time_le));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_SCAN_UNASSOC_TIME,
-(char *)_unassoc_time, sizeof(scan_unassoc_time));
+(char *)_unassoc_time_le, sizeof(scan_unassoc_time_le));
/* Set and enable ARP offload feature */
brcmf_c_arp_offload_set(drvr, BRCMF_ARPOL_MODE);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 104/108] tg3: Fix TSO CAP for 5704 devs w / ASF enabled
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Matt Carlson
[ Upstream commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db ]
On the earliest TSO capable devices, TSO was accomplished through
firmware. The TSO cannot coexist with ASF management firmware though.
The tg3 driver determines whether or not ASF is enabled by calling
tg3_get_eeprom_hw_cfg(), which checks a particular bit of NIC memory.
Commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d, entitled "tg3: Move
TSO_CAPABLE assignment", accidentally moved the code that determines
TSO capabilities earlier than the call to tg3_get_eeprom_hw_cfg(). As a
consequence, the driver was attempting to determine TSO capabilities
before it had all the data it needed to make the decision.
This patch fixes the problem by revisiting and reevaluating the decision
after tg3_get_eeprom_hw_cfg() is called.
Signed-off-by: Matt Carlson
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/broadcom/tg3.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index 6b258d9..01bc102 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14013,9 +14013,13 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
if (tg3_flag(tp, HW_TSO_1) ||
tg3_flag(tp, HW_TSO_2) ||
tg3_flag(tp, HW_TSO_3) ||
- (tp->fw_needed && !tg3_flag(tp, ENABLE_ASF)))
+ tp->fw_needed) {
+ /* For firmware TSO, assume ASF is disabled.
+* We'll disable TSO later if we discover ASF
+* is enabled in tg3_get_eeprom_hw_cfg().
+*/
tg3_flag_set(tp, TSO_CAPABLE);
- else {
+ } else {
tg3_flag_clear(tp, TSO_CAPABLE);
tg3_flag_clear(tp, TSO_BUG);
tp->fw_needed = NULL;
@@ -14290,6 +14294,12 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
*/
tg3_get_eeprom_hw_cfg(tp);
+ if (tp->fw_needed && tg3_flag(tp, ENABLE_ASF)) {
+ tg3_flag_clear(tp, TSO_CAPABLE);
+ tg3_flag_clear(tp, TSO_BUG);
+ tp->fw_needed = NULL;
+ }
+
if (tg3_flag(tp, ENABLE_APE)) {
/* Allow reads and writes to the
* APE register and memory space.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 102/108] net: do not disable sg for packets requiring no checksum
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Ed Cashin
[ Upstream commit c0d680e577ff171e7b37dbdb1b1bf5451e851f04 ]
A change in a series of VLAN-related changes appears to have
inadvertently disabled the use of the scatter gather feature of
network cards for transmission of non-IP ethernet protocols like ATA
over Ethernet (AoE). Below is a reference to the commit that
introduces a "harmonize_features" function that turns off scatter
gather when the NIC does not support hardware checksumming for the
ethernet protocol of an sk buff.
commit f01a5236bd4b140198fbcc550f085e8361fd73fa
Author: Jesse Gross
Date: Sun Jan 9 06:23:31 2011 +
net offloading: Generalize netif_get_vlan_features().
The can_checksum_protocol function is not equipped to consider a
protocol that does not require checksumming. Calling it for a
protocol that requires no checksum is inappropriate.
The patch below has harmonize_features call can_checksum_protocol when
the protocol needs a checksum, so that the network layer is not forced
to perform unnecessary skb linearization on the transmission of AoE
packets. Unnecessary linearization results in decreased performance
and increased memory pressure, as reported here:
http://www.spinics.net/lists/linux-mm/msg15184.html
The problem has probably not been widely experienced yet, because
only recently has the kernel.org-distributed aoe driver acquired the
ability to use payloads of over a page in size, with the patchset
recently included in the mm tree:
https://lkml.org/lkml/2012/8/28/140
The coraid.com-distributed aoe driver already could use payloads of
greater than a page in size, but its users generally do not use the
newest kernels.
Signed-off-by: Ed Cashin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/core/dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a4a0c5a..6cecd40 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2108,7 +2108,8 @@ static bool can_checksum_protocol(unsigned long features,
__be16 protocol)
static u32 harmonize_features(struct sk_buff *skb, __be16 protocol, u32
features)
{
- if (!can_checksum_protocol(features, protocol)) {
+ if (skb->ip_summed != CHECKSUM_NONE &&
+ !can_checksum_protocol(features, protocol)) {
features &= ~NETIF_F_ALL_CSUM;
features &= ~NETIF_F_SG;
} else if (illegal_highdma(skb->dev, skb)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 015/108] rtlwifi: rtl8192ce: Log message that B_CUT device may not work
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 022e1d0680c7b4366017393417b8758be5abcee8 upstream.
There are a number of problems that occur for the latest version
of the Realtek RTL8188CE device with the in-kernel driver. These
include selection of the wrong firmware, and system lockup. A full
fix is known, but is too invasive for inclusion in stable. This patch
fixes the problem with loading the wrong firmware, and logs a message
that the device may not work for kernels 3.6 and older.
Signed-off-by: Larry Finger
Cc: Anisse Astier
Cc: Li Chaoming
Tested-by: Anisse Astier
Signed-off-by: John W. Linville
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
@@ -117,6 +117,7 @@
#define CHIP_VER_B BIT(4)
#define CHIP_92C_BITMASK BIT(0)
+#define CHIP_UNKNOWN BIT(7)
#define CHIP_92C_1T2R 0x03
#define CHIP_92C 0x01
#define CHIP_88C 0x00
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1001,8 +1001,16 @@ static enum version_8192c _rtl92ce_read_
version = (value32 & TYPE_ID) ? VERSION_A_CHIP_92C :
VERSION_A_CHIP_88C;
} else {
- version = (value32 & TYPE_ID) ? VERSION_B_CHIP_92C :
- VERSION_B_CHIP_88C;
+ version = (enum version_8192c) (CHIP_VER_B |
+ ((value32 & TYPE_ID) ? CHIP_92C_BITMASK : 0) |
+ ((value32 & VENDOR_ID) ? CHIP_VENDOR_UMC : 0));
+ if ((!IS_CHIP_VENDOR_UMC(version)) && (value32 &
+CHIP_VER_RTL_MASK)) {
+ version = (enum version_8192c)(version |
+ value32 & CHIP_VER_RTL_MASK) == BIT(12))
+ ? CHIP_VENDOR_UMC_B_CUT : CHIP_UNKNOWN) |
+ CHIP_VENDOR_UMC));
+ }
}
switch (version) {
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -165,12 +165,14 @@ int rtl92c_init_sw_vars(struct ieee80211
/* request fw */
if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
- !IS_92C_SERIAL(rtlhal->version))
+ !IS_92C_SERIAL(rtlhal->version)) {
fw_name = "rtlwifi/rtl8192cfwU.bin";
- else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
+ } else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version)) {
fw_name = "rtlwifi/rtl8192cfwU_B.bin";
- else
+ pr_info("** This B_CUT device may not work with kernels 3.6
and earlier\n");
+ } else {
fw_name = rtlpriv->cfg->fw_name;
+ }
err = request_firmware(, fw_name, rtlpriv->io.dev);
if (err) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 008/108] memory hotplug: fix section info double registration bug
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: qiuxishi
commit f14851af0ebb32745c6c5a2e400aa0549f9d20df upstream.
There may be a bug when registering section info. For example, on my
Itanium platform, the pfn range of node0 includes the other nodes, so
other nodes' section info will be double registered, and memmap's page
count will equal to 3.
node0: start_pfn=0x100,spanned_pfn=0x20fb00, present_pfn=0x7f8a3, =>
0x000100-0x20fc00
node1: start_pfn=0x8, spanned_pfn=0x8, present_pfn=0x8, =>
0x08-0x10
node2: start_pfn=0x10, spanned_pfn=0x8, present_pfn=0x8, =>
0x10-0x18
node3: start_pfn=0x18, spanned_pfn=0x8, present_pfn=0x8, =>
0x18-0x20
free_all_bootmem_node()
register_page_bootmem_info_node()
register_page_bootmem_info_section()
When hot remove memory, we can't free the memmap's page because
page_count() is 2 after put_page_bootmem().
sparse_remove_one_section()
free_section_usemap()
free_map_bootmem()
put_page_bootmem()
[a...@linux-foundation.org: add code comment]
Signed-off-by: Xishi Qiu
Signed-off-by: Jiang Liu
Acked-by: Mel Gorman
Cc: "Luck, Tony"
Cc: Yasuaki Ishimatsu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
mm/memory_hotplug.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 3ad25f9..6a5b90d 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -126,9 +126,6 @@ static void register_page_bootmem_info_section(unsigned
long start_pfn)
struct mem_section *ms;
struct page *page, *memmap;
- if (!pfn_valid(start_pfn))
- return;
-
section_nr = pfn_to_section_nr(start_pfn);
ms = __nr_to_section(section_nr);
@@ -187,9 +184,16 @@ void register_page_bootmem_info_node(struct pglist_data
*pgdat)
end_pfn = pfn + pgdat->node_spanned_pages;
/* register_section info */
- for (; pfn < end_pfn; pfn += PAGES_PER_SECTION)
- register_page_bootmem_info_section(pfn);
-
+ for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ /*
+* Some platforms can assign the same pfn to multiple nodes - on
+* node0 as well as nodeN. To avoid registering a pfn against
+* multiple nodes we check that this pfn does not already
+* reside in some other node.
+*/
+ if (pfn_valid(pfn) && (pfn_to_nid(pfn) == node))
+ register_page_bootmem_info_section(pfn);
+ }
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 006/108] drivers/rtc/rtc-twl.c: ensure all interrupts are disabled during probe
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Kevin Hilman commit 8dcebaa9a0ae8a0487f4342f3d56d2cb1c980860 upstream. On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Signed-off-by: Kevin Hilman Cc: Felipe Balbi Tested-by: Steve Sakoman Cc: Alessandro Zummo Tested-by: Shubhrajyoti Datta Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -462,6 +462,11 @@ static int __devinit twl_rtc_probe(struc goto out1; } + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret < 0) + dev_warn(>dev, "unable to disable interrupt\n"); + /* init cached IRQ enable bits */ ret = twl_rtc_read_u8(_irq_bits, REG_RTC_INTERRUPTS_REG); if (ret < 0) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 107/108] Bluetooth: add support for atheros 0489:e057
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Peng Chen
commit 2096ae6ca647302d50a68aa36cb66a00e7dfac70 upstream.
Add support for the AR3012 chip found on Fioxconn.
usb-devices shows:
T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 44 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e057 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Peng Chen
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 10308cd..11f36e5 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -79,6 +79,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
+ { USB_DEVICE(0x0489, 0xe057) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -104,6 +105,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index da6aa39..cef3bac 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -134,6 +134,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 098/108] ipv6: raw: fix icmpv6_filter()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 1b05c4b50edbddbdde715c4a7350629819f6655e ]
icmpv6_filter() should not modify its input, or else its caller
would need to recompute ipv6_hdr() if skb->head is reallocated.
Use skb_header_pointer() instead of pskb_may_pull() and
change the prototype to make clear both sk and skb are const.
Also, if icmpv6 header cannot be found, do not deliver the packet,
as we do in IPv4.
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/raw.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 361ebf3..6e6c2c4 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -107,21 +107,20 @@ found:
* 0 - deliver
* 1 - block
*/
-static __inline__ int icmpv6_filter(struct sock *sk, struct sk_buff *skb)
+static int icmpv6_filter(const struct sock *sk, const struct sk_buff *skb)
{
- struct icmp6hdr *icmph;
- struct raw6_sock *rp = raw6_sk(sk);
-
- if (pskb_may_pull(skb, sizeof(struct icmp6hdr))) {
- __u32 *data = >filter.data[0];
- int bit_nr;
+ struct icmp6hdr *_hdr;
+ const struct icmp6hdr *hdr;
- icmph = (struct icmp6hdr *) skb->data;
- bit_nr = icmph->icmp6_type;
+ hdr = skb_header_pointer(skb, skb_transport_offset(skb),
+sizeof(_hdr), &_hdr);
+ if (hdr) {
+ const __u32 *data = _sk(sk)->filter.data[0];
+ unsigned int type = hdr->icmp6_type;
- return (data[bit_nr >> 5] & (1 << (bit_nr & 31))) != 0;
+ return (data[type >> 5] & (1U << (type & 31))) != 0;
}
- return 0;
+ return 1;
}
#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 099/108] ipv6: mip6: fix mip6_mh_filter()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 96af69ea2a83d292238bdba20e4508ee967cf8cb ]
mip6_mh_filter() should not modify its input, or else its caller
would need to recompute ipv6_hdr() if skb->head is reallocated.
Use skb_header_pointer() instead of pskb_may_pull()
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/mip6.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/net/ipv6/mip6.c b/net/ipv6/mip6.c
index 43242e6..42853c4 100644
--- a/net/ipv6/mip6.c
+++ b/net/ipv6/mip6.c
@@ -84,28 +84,30 @@ static int mip6_mh_len(int type)
static int mip6_mh_filter(struct sock *sk, struct sk_buff *skb)
{
- struct ip6_mh *mh;
+ struct ip6_mh _hdr;
+ const struct ip6_mh *mh;
- if (!pskb_may_pull(skb, (skb_transport_offset(skb)) + 8) ||
- !pskb_may_pull(skb, (skb_transport_offset(skb) +
-((skb_transport_header(skb)[1] + 1) << 3
+ mh = skb_header_pointer(skb, skb_transport_offset(skb),
+ sizeof(_hdr), &_hdr);
+ if (!mh)
return -1;
- mh = (struct ip6_mh *)skb_transport_header(skb);
+ if (((mh->ip6mh_hdrlen + 1) << 3) > skb->len)
+ return -1;
if (mh->ip6mh_hdrlen < mip6_mh_len(mh->ip6mh_type)) {
LIMIT_NETDEBUG(KERN_DEBUG "mip6: MH message too short: %d vs
>=%d\n",
mh->ip6mh_hdrlen, mip6_mh_len(mh->ip6mh_type));
- mip6_param_prob(skb, 0, ((>ip6mh_hdrlen) -
-skb_network_header(skb)));
+ mip6_param_prob(skb, 0, offsetof(struct ip6_mh, ip6mh_hdrlen) +
+ skb_network_header_len(skb));
return -1;
}
if (mh->ip6mh_proto != IPPROTO_NONE) {
LIMIT_NETDEBUG(KERN_DEBUG "mip6: MH invalid payload proto =
%d\n",
mh->ip6mh_proto);
- mip6_param_prob(skb, 0, ((>ip6mh_proto) -
-skb_network_header(skb)));
+ mip6_param_prob(skb, 0, offsetof(struct ip6_mh, ip6mh_proto) +
+ skb_network_header_len(skb));
return -1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 097/108] ipv4: raw: fix icmp_filter()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit ab43ed8b7490cb387782423ecf74aeee7237e591 ]
icmp_filter() should not modify its input, or else its caller
would need to recompute ip_hdr() if skb->head is reallocated.
Use skb_header_pointer() instead of pskb_may_pull() and
change the prototype to make clear both sk and skb are const.
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/raw.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 007e2eb..e1d4f30 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -131,18 +131,20 @@ found:
* 0 - deliver
* 1 - block
*/
-static __inline__ int icmp_filter(struct sock *sk, struct sk_buff *skb)
+static int icmp_filter(const struct sock *sk, const struct sk_buff *skb)
{
- int type;
+ struct icmphdr _hdr;
+ const struct icmphdr *hdr;
- if (!pskb_may_pull(skb, sizeof(struct icmphdr)))
+ hdr = skb_header_pointer(skb, skb_transport_offset(skb),
+sizeof(_hdr), &_hdr);
+ if (!hdr)
return 1;
- type = icmp_hdr(skb)->type;
- if (type < 32) {
+ if (hdr->type < 32) {
__u32 data = raw_sk(sk)->filter.data;
- return ((1 << type) & data) != 0;
+ return ((1U << hdr->type) & data) != 0;
}
/* Do not block unknown ICMP types */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 094/108] pppoe: drop PPPOX_ZOMBIEs in pppoe_release
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Xiaodong Xu
[ Upstream commit 2b018d57ff18e5405823e5cb59651a5b4d946d7b ]
When PPPOE is running over a virtual ethernet interface (e.g., a
bonding interface) and the user tries to delete the interface in case
the PPPOE state is ZOMBIE, the kernel will loop forever while
unregistering net_device for the reference count is not decreased to
zero which should have been done with dev_put().
Signed-off-by: Xiaodong Xu
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ppp/pppoe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index bc9a4bb..1161584 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -576,7 +576,7 @@ static int pppoe_release(struct socket *sock)
po = pppox_sk(sk);
- if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
+ if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
dev_put(po->pppoe_dev);
po->pppoe_dev = NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 089/108] sierra_net: Endianess bug fix.
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Lennart Sorensen [ Upstream commit 2120c52da6fe741454a60644018ad2a6abd957ac ] I discovered I couldn't get sierra_net to work on a powerpc. Turns out the firmware attribute check assumes the system is little endian and hence fails because the attributes is a 16 bit value. Signed-off-by: Len Sorensen Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/usb/sierra_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c index 864448b..e773250 100644 --- a/drivers/net/usb/sierra_net.c +++ b/drivers/net/usb/sierra_net.c @@ -678,7 +678,7 @@ static int sierra_net_get_fw_attr(struct usbnet *dev, u16 *datap) return -EIO; } - *datap = *attrdata; + *datap = le16_to_cpu(*attrdata); kfree(attrdata); return result; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 009/108] cciss: fix handling of protocol error
3.2-stable review patch. If anyone has any objections, please let me know. -- From: "Stephen M. Cameron" commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream. If a command completes with a status of CMD_PROTOCOL_ERR, this information should be conveyed to the SCSI mid layer, not dropped on the floor. Unlike a similar bug in the hpsa driver, this bug only affects tape drives and CD and DVD ROM drives in the cciss driver, and to induce it, you have to disconnect (or damage) a cable, so it is not a very likely scenario (which would explain why the bug has gone undetected for the last 10 years.) Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings --- drivers/block/cciss_scsi.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c index 38aa6dd..da33111 100644 --- a/drivers/block/cciss_scsi.c +++ b/drivers/block/cciss_scsi.c @@ -795,6 +795,7 @@ static void complete_scsi_command(CommandList_struct *c, int timeout, } break; case CMD_PROTOCOL_ERR: + cmd->result = DID_ERROR << 16; dev_warn(>pdev->dev, "%p has protocol error\n", c); break; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 096/108] net: guard tcp_set_keepalive() to tcp sockets
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 3e10986d1d698140747fcfc2761ec9cb64c1d582 ] Its possible to use RAW sockets to get a crash in tcp_set_keepalive() / sk_reset_timer() Fix is to make sure socket is a SOCK_STREAM one. Reported-by: Dave Jones Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/core/sock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/sock.c b/net/core/sock.c index 018fd41..1e8a882 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -593,7 +593,8 @@ set_rcvbuf: case SO_KEEPALIVE: #ifdef CONFIG_INET - if (sk->sk_protocol == IPPROTO_TCP) + if (sk->sk_protocol == IPPROTO_TCP && + sk->sk_type == SOCK_STREAM) tcp_set_keepalive(sk, valbool); #endif sock_valbool_flag(sk, SOCK_KEEPOPEN, valbool); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 108/108] Bluetooth: Add support for Sony Vaio T-Series
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Yevgeniy Melnichuk
commit bc21fde2d549d1cb1ebef04016eb7affa43bb5c1 upstream.
Add Sony Vaio T-Series Bluetooth Module( 0x489:0xE036) to
the blacklist of btusb module and add it to the ath3k module.
output of cat /sys/kernel/debug/usb/devices
T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e036 Rev= 0.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Yevgeniy Melnichuk
Signed-off-by: Mohammed Shafi Shajakhan
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 11f36e5..fc2de55 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -86,6 +86,7 @@ static struct usb_device_id ath3k_table[] = {
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C) },
+ { USB_DEVICE(0x0489, 0xE036) },
{ } /* Terminating entry */
};
@@ -109,6 +110,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xE036), .driver_info = BTUSB_ATH3012 },
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index cef3bac..2fe7776 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -141,6 +141,7 @@ static struct usb_device_id blacklist_table[] = {
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe036), .driver_info = BTUSB_ATH3012 },
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2035), .driver_info = BTUSB_WRONG_SCO_MTU },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 085/108] ixp4xx_hss: fix build failure due to missing linux/module.h inclusion
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Florian Fainelli [ Upstream commit 0b836ddde177bdd5790ade83772860940bd481ea ] Commit 36a1211970193ce215de50ed1e4e1272bc814df1 (netprio_cgroup.h: dont include module.h from other includes) made the following build error on ixp4xx_hss pop up: CC [M] drivers/net/wan/ixp4xx_hss.o drivers/net/wan/ixp4xx_hss.c:1412:20: error: expected ';', ',' or ')' before string constant drivers/net/wan/ixp4xx_hss.c:1413:25: error: expected ';', ',' or ')' before string constant drivers/net/wan/ixp4xx_hss.c:1414:21: error: expected ';', ',' or ')' before string constant drivers/net/wan/ixp4xx_hss.c:1415:19: error: expected ';', ',' or ')' before string constant make[8]: *** [drivers/net/wan/ixp4xx_hss.o] Error 1 This was previously hidden because ixp4xx_hss includes linux/hdlc.h which includes linux/netdevice.h which includes linux/netprio_cgroup.h which used to include linux/module.h. The real issue was actually present since the initial commit that added this driver since it uses macros from linux/module.h without including this file. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/wan/ixp4xx_hss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c index aaaca9a..3f575af 100644 --- a/drivers/net/wan/ixp4xx_hss.c +++ b/drivers/net/wan/ixp4xx_hss.c @@ -10,6 +10,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 105/108] Bluetooth: Support AR3011 in Acer Iconia Tab W500
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Vasut
commit 6eda541d12116b4772baa09d3e8d7b0389df4289 upstream.
Acer used this chip connected via USB:
Bus 005 Device 005: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize064
idVendor 0x0cf3 Atheros Communications, Inc.
idProduct 0x3005 AR3011 Bluetooth
bcdDevice0.01
iManufacturer 0
iProduct0
iSerial 0
bNumConfigurations 1
Signed-off-by: Marek Vasut
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: Marcel Holtmann
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |1 +
drivers/bluetooth/btusb.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index ad591bd..f0f6202 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -63,6 +63,7 @@ static struct usb_device_id ath3k_table[] = {
/* Atheros AR3011 with sflash firmware*/
{ USB_DEVICE(0x0CF3, 0x3002) },
+ { USB_DEVICE(0x0CF3, 0xE019) },
{ USB_DEVICE(0x13d3, 0x3304) },
{ USB_DEVICE(0x0930, 0x0215) },
{ USB_DEVICE(0x0489, 0xE03D) },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c9463af8..ff3eabc 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -125,6 +125,7 @@ static struct usb_device_id blacklist_table[] = {
/* Atheros 3011 with sflash firmware */
{ USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0cf3, 0xe019), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 086/108] netxen: check for root bus in netxen_mask_aer_correctable
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Nikolay Aleksandrov [ Upstream commit e4d1aa40e363ed3e0486aeeeb0d173f7f822737e ] Add a check if pdev->bus->self == NULL (root bus). When attaching a netxen NIC to a VM it can be on the root bus and the guest would crash in netxen_mask_aer_correctable() because of a NULL pointer dereference if CONFIG_PCIEAER is present. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c index 8cf3173..da5204d 100644 --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c @@ -1351,6 +1351,10 @@ static void netxen_mask_aer_correctable(struct netxen_adapter *adapter) struct pci_dev *root = pdev->bus->self; u32 aer_pos; + /* root bus? */ + if (!root) + return; + if (adapter->ahw.board_type != NETXEN_BRDTYPE_P3_4_GB_MM && adapter->ahw.board_type != NETXEN_BRDTYPE_P3_10G_TP) return; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 007/108] mm/page_alloc: fix the page address of higher pages buddy calculation
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Li Haifeng
commit 0ba8f2d59304dfe69b59c034de723ad80f7ab9ac upstream.
The heuristic method for buddy has been introduced since commit
43506fad21ca ("mm/page_alloc.c: simplify calculation of combined index
of adjacent buddy lists"). But the page address of higher page's buddy
was wrongly calculated, which will lead page_is_buddy to fail for ever.
IOW, the heuristic method would be disabled with the wrong page address
of higher page's buddy.
Calculating the page address of higher page's buddy should be based
higher_page with the offset between index of higher page and index of
higher page's buddy.
Signed-off-by: Haifeng Li
Signed-off-by: Gavin Shan
Reviewed-by: Michal Hocko
Cc: KyongHo Cho
Cc: Mel Gorman
Cc: Minchan Kim
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c66fb87..c13ea75 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -584,7 +584,7 @@ static inline void __free_one_page(struct page *page,
combined_idx = buddy_idx & page_idx;
higher_page = page + (combined_idx - page_idx);
buddy_idx = __find_buddy_index(combined_idx, order + 1);
- higher_buddy = page + (buddy_idx - combined_idx);
+ higher_buddy = higher_page + (buddy_idx - combined_idx);
if (page_is_buddy(higher_page, higher_buddy, order + 1)) {
list_add_tail(>lru,
>free_area[order].free_list[migratetype]);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 084/108] net: ethernet: davinci_cpdma: decrease the desc count when cleaning up the remaining packets
3.2-stable review patch. If anyone has any objections, please let me know. -- From: htbegin [ Upstream commit ffb5ba90017505a19e238e986e6d33f09e4df765 ] chan->count is used by rx channel. If the desc count is not updated by the clean up loop in cpdma_chan_stop, the value written to the rxfree register in cpdma_chan_start will be incorrect. Signed-off-by: Tao Hou Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/ti/davinci_cpdma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c index c97d2f5..bfc3b0d 100644 --- a/drivers/net/ethernet/ti/davinci_cpdma.c +++ b/drivers/net/ethernet/ti/davinci_cpdma.c @@ -851,6 +851,7 @@ int cpdma_chan_stop(struct cpdma_chan *chan) next_dma = desc_read(desc, hw_next); chan->head = desc_from_phys(pool, next_dma); + chan->count--; chan->stats.teardown_dequeue++; /* issue callback without locks held */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Drivers: hv: Add Hyper-V balloon driver
Add the basic balloon driver. Windows hosts dynamically manage the guest
memory allocation via a combination memory hot add and ballooning. Memory
hot add is used to grow the guest memory upto the maximum memory that can be
allocatted to the guest. Ballooning is used to both shrink as well as expand
up to the max memory. Supporting hot add needs additional support from the
host. We will support hot add when this support is available. For now,
by setting the VM startup memory to the VM max memory, we can use
ballooning alone to dynamically manage memory allocation amongst
competing guests on a given host.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/hv/Kconfig |6 +
drivers/hv/Makefile |1 +
drivers/hv/hv_balloon.c | 1043 +++
3 files changed, 1050 insertions(+), 0 deletions(-)
create mode 100644 drivers/hv/hv_balloon.c
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 70f5dde..75af1d4 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -13,4 +13,10 @@ config HYPERV_UTILS
help
Select this option to enable the Hyper-V Utilities.
+config HYPERV_BALLOON
+ tristate "Microsoft Hyper-V Balloon driver"
+ depends on HYPERV
+ help
+ Select this option to enable the Hyper-V Utilities.
+
endmenu
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index a23938b..e6abfa0 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_HYPERV) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
+obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
hv_vmbus-y := vmbus_drv.o \
hv.o connection.o channel.o \
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
new file mode 100644
index 000..e543524
--- /dev/null
+++ b/drivers/hv/hv_balloon.c
@@ -0,0 +1,1043 @@
+/*
+ * Copyright (c) 2012, Microsoft Corporation.
+ *
+ * Author:
+ * K. Y. Srinivasan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * 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, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * We begin with definitions supporting the Dynamic Memory protocol
+ * with the host.
+ *
+ * Begin protocol definitions.
+ */
+
+
+
+/*
+ * Protocol versions. The low word is the minor version, the high word the
major
+ * version.
+ *
+ * History:
+ * Initial version 1.0
+ * Changed to 0.1 on 2009/03/25
+ * Changes to 0.2 on 2009/05/14
+ * Changes to 0.3 on 2009/12/03
+ * Changed to 1.0 on 2011/04/05
+ */
+
+#define DYNMEM_MAKE_VERSION(Major, Minor) ((__u32)(((Major) << 16) | (Minor)))
+#define DYNMEM_MAJOR_VERSION(Version) ((__u32)(Version) >> 16)
+#define DYNMEM_MINOR_VERSION(Version) ((__u32)(Version) & 0xff)
+
+enum {
+ DYNMEM_PROTOCOL_VERSION_1 = DYNMEM_MAKE_VERSION(0, 3),
+ DYNMEM_PROTOCOL_VERSION_2 = DYNMEM_MAKE_VERSION(1, 0),
+
+ DYNMEM_PROTOCOL_VERSION_WIN7 = DYNMEM_PROTOCOL_VERSION_1,
+ DYNMEM_PROTOCOL_VERSION_WIN8 = DYNMEM_PROTOCOL_VERSION_2,
+
+ DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN8
+};
+
+
+
+/*
+ * Message Types
+ */
+
+enum dm_message_type {
+ /*
+* Version 0.3
+*/
+ DM_ERROR= 0,
+ DM_VERSION_REQUEST = 1,
+ DM_VERSION_RESPONSE = 2,
+ DM_CAPABILITIES_REPORT = 3,
+ DM_CAPABILITIES_RESPONSE= 4,
+ DM_STATUS_REPORT= 5,
+ DM_BALLOON_REQUEST = 6,
+ DM_BALLOON_RESPONSE = 7,
+ DM_UNBALLOON_REQUEST= 8,
+ DM_UNBALLOON_RESPONSE = 9,
+ DM_MEM_HOT_ADD_REQUEST = 10,
+ DM_MEM_HOT_ADD_RESPONSE = 11,
+ DM_VERSION_03_MAX = 11,
+ /*
+* Version 1.0.
+*/
+ DM_INFO_MESSAGE = 12,
+ DM_VERSION_1_MAX= 12
+};
+
+
+/*
+ * Structures defining the dynamic memory management
+ * protocol.
+ */
+
+union dm_version {
+ struct {
+ __u16 minor_version;
+ __u16 major_version;
+ };
+ __u32 version;
+} __packed;
+
+
+union dm_caps {
+
[PATCH 1/2] mm: Export vm_committed_as
The policy engine on the host expects the guest to report the committed_as. Since this variable is not exported, export this symbol. Signed-off-by: K. Y. Srinivasan --- mm/mmap.c |1 + mm/nommu.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 2d94235..01439d4 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -87,6 +87,7 @@ int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT; * other variables. It can be updated by several CPUs frequently. */ struct percpu_counter vm_committed_as cacheline_aligned_in_smp; +EXPORT_SYMBOL(vm_committed_as); /* * Check that a process has enough memory to allocate a new virtual diff --git a/mm/nommu.c b/mm/nommu.c index 45131b4..3914b7e 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -68,6 +68,7 @@ atomic_long_t mmap_pages_allocated; EXPORT_SYMBOL(mem_map); EXPORT_SYMBOL(num_physpages); +EXPORT_SYMBOL(vm_committed_as); /* list of mapped, potentially shareable regions */ static struct kmem_cache *vm_region_jar; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 088/108] pkt_sched: fix virtual-start-time update in QFQ
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Paolo Valente
[ Upstream commit 71261956973ba9e0637848a5adb4a5819b4bae83 ]
If the old timestamps of a class, say cl, are stale when the class
becomes active, then QFQ may assign to cl a much higher start time
than the maximum value allowed. This may happen when QFQ assigns to
the start time of cl the finish time of a group whose classes are
characterized by a higher value of the ratio
max_class_pkt/weight_of_the_class with respect to that of
cl. Inserting a class with a too high start time into the bucket list
corrupts the data structure and may eventually lead to crashes.
This patch limits the maximum start time assigned to a class.
Signed-off-by: Paolo Valente
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/sched/sch_qfq.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 7b03254..ca0fb48 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -829,7 +829,10 @@ static void qfq_update_start(struct qfq_sched *q, struct
qfq_class *cl)
if (mask) {
struct qfq_group *next = qfq_ffs(q, mask);
if (qfq_gt(roundedF, next->F)) {
- cl->S = next->F;
+ if (qfq_gt(limit, next->F))
+ cl->S = next->F;
+ else /* preserve timestamp correctness */
+ cl->S = limit;
return;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 103/108] aoe: assert AoE packets marked as requiring no checksum
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Ed Cashin [ Upstream commit 8babe8cc6570ed896b7b596337eb8fe730c3ff45 ] In order for the network layer to see that AoE requires no checksumming in a generic way, the packets must be marked as requiring no checksum, so we make this requirement explicit with the assertion. Signed-off-by: Ed Cashin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/block/aoe/aoecmd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c index de0435e..887f68f 100644 --- a/drivers/block/aoe/aoecmd.c +++ b/drivers/block/aoe/aoecmd.c @@ -35,6 +35,7 @@ new_skb(ulong len) skb_reset_mac_header(skb); skb_reset_network_header(skb); skb->protocol = __constant_htons(ETH_P_AOE); + skb_checksum_none_assert(skb); } return skb; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 004/108] mm/ia64: fix a memory block size bug
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Jianguo Wu
commit 05cf96398e1b6502f9e191291b715c7463c9d5dd upstream.
I found following definition in include/linux/memory.h, in my IA64
platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE
will be 0.
#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
Because MIN_MEMORY_BLOCK_SIZE is int type and length of 32bits,
so MIN_MEMORY_BLOCK_SIZE(1 << 32) will will equal to 0.
Actually when SECTION_SIZE_BITS >= 31, MIN_MEMORY_BLOCK_SIZE will be wrong.
This will cause wrong system memory infomation in sysfs.
I think it should be:
#define MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS)
And "echo offline > memory0/state" will cause following call trace:
kernel BUG at mm/memory_hotplug.c:885!
sh[6455]: bugcheck! 0 [1]
Pid: 6455, CPU 0, comm: sh
psr : 101008526030 ifs : 8fa4 ip : []
Not tainted (3.6.0-rc1)
ip is at offline_pages+0x210/0xee0
Call Trace:
show_stack+0x80/0xa0
show_regs+0x640/0x920
die+0x190/0x2c0
die_if_kernel+0x50/0x80
ia64_bad_break+0x3d0/0x6e0
ia64_native_leave_kernel+0x0/0x270
offline_pages+0x210/0xee0
alloc_pages_current+0x180/0x2a0
Signed-off-by: Jianguo Wu
Signed-off-by: Jiang Liu
Cc: "Luck, Tony"
Reviewed-by: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
include/linux/memory.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/memory.h b/include/linux/memory.h
index 1ac7f6e..ff9a9f8 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -19,7 +19,7 @@
#include
#include
-#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
+#define MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS)
struct memory_block {
unsigned long start_section_nr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
