Re: [PATCH] tty: Fix ptmx open without closed slave.
On Wed, Jan 16, 2013 at 11:48:38AM +0400, Ilya Zykov wrote: > > > > > Ok, I have a ton of patches from you, lots of different threads, patches > > with the same subject, and I don't know what one Alan agreed to. > > > > So, can you please resend what Alan and you agree should be applied to > > the tree? > > > > > I think only two important: > [PATCH v4] tty: Add driver unthrottle in ioctl(...,TCFLSH,..). > > [PATCH] tty: Correct tty buffer flush. > With Alan's ACK from 04.12.2012 for kernel <= 3.7 > > But for kernel 3.8 I resent this 05.12.2012 > [PATCH -next 0/2] tty: Correct tty buffer flush. > [PATCH -next 1/2] tty: Correct tty buffer flush. > [PATCH -next 2/2] tty: Correct tty buffer flush. > The last I resent with new description after Jiri's remark. How can you have more than one patch with the same subject? Please resend all patches that you wish to see applied, with proper Subject: lines and acks, if you have gotten them. thanks, 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 v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Wednesday 16 of January 2013 11:15:43 Vivek Gautam wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
>
> Changes from v4:
> - Added gpio line for VBUS of USB2.0 on snow board.
>
> .../devicetree/bindings/usb/exynos-usb.txt | 25
> arch/arm/boot/dts/exynos5250-smdk5250.dts
> |4 +++ arch/arm/boot/dts/exynos5250-snow.dts |4
> +++ arch/arm/boot/dts/exynos5250.dtsi |6 4
> files changed, 39 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt new file mode
> 100644
> index 000..e8bbb47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -0,0 +1,25 @@
> +Samsung Exynos SoC USB controller
> +
> +The USB devices interface with USB controllers on Exynos SOCs.
> +The device node has following properties.
> +
> +EHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
> + EHCI controller in host mode.
> + - reg: physical base address of the controller and length of memory
> mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Optional properties:
> + - samsung,vbus-gpio: if present, specifies the GPIO that
> + needs to be pulled up for the bus to be powered.
> +
> +Example:
> +
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts index 942d576..7363e14
> 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -204,4 +204,8 @@
> samsung,mfc-r = <0x4300 0x80>;
> samsung,mfc-l = <0x5100 0x80>;
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts index 17dd951..47b6b84 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -40,4 +40,8 @@
> < 5 2 3 0>, < 6 2 3 0>;
> };
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = < 1 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index 30485de..2cbe53e 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,12 @@
> #size-cells = <0>;
> };
>
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <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 v4 4/4] ARM: Exynos5250: Enabling dwc3-exynos driver
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:32 Vivek Gautam wrote:
> Adding DWC3 device tree node for Exynos5250 needed to
> parse device tree data.
> Also enabling XHCI support on exynos5250.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 14
> ++ arch/arm/boot/dts/exynos5250.dtsi |
> 6 ++ arch/arm/mach-exynos/Kconfig |1 +
> 3 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
> f66fcdd..d660410 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -38,3 +38,17 @@ Example:
> reg = <0x1212 0x100>;
> interrupts = <0 71 0>;
> };
> +
> +DWC3
> +Required properties:
> + - compatible: should be "samsung,exynos5250-dwc3" for USB 3.0 DWC3
> controller. + - reg: physical base address of the controller and length
> of memory mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> + usb@1200 {
> + compatible = "samsung,exynos5250-dwc3";
> + reg = <0x1200 0x1>;
> + interrupts = <0 72 0>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index ebb0907..a747524 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,12 @@
> #size-cells = <0>;
> };
>
> + usb@1200 {
> + compatible = "samsung,exynos5250-dwc3";
> + reg = <0x1200 0x1>;
> + interrupts = <0 72 0>;
> + };
> +
> usb@1211 {
> compatible = "samsung,exynos4210-ehci";
> reg = <0x1211 0x100>;
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index d26c9f9..e62fd20 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -428,6 +428,7 @@ config MACH_EXYNOS5_DT
> depends on ARCH_EXYNOS5
> select ARM_AMBA
> select USE_OF
> + select USB_ARCH_HAS_XHCI
> help
> Machine support for Samsung EXYNOS5 machine with device tree
> enabled. Select this if a fdt blob is available for the EXYNOS5 SoC
> based board.
--
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 v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos
Hi Vivek,
Don't you need also some clkdev lookup entry to make the clock available
in the driver?
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
> Adding necessary device clock to exynos5 needed for
> the DWC3 controller.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/mach-exynos/clock-exynos5.c | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
> b/arch/arm/mach-exynos/clock-exynos5.c index 0208c3a..13af020 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
> .enable = exynos5_clk_ip_fsys_ctrl ,
> .ctrlbit= (1 << 18),
> }, {
> + .name = "usbdrd30",
> + .parent = _clk_aclk_200.clk,
> + .enable = exynos5_clk_ip_fsys_ctrl,
> + .ctrlbit= (1 << 19),
> + }, {
> .name = "usbotg",
> .enable = exynos5_clk_ip_fsys_ctrl,
> .ctrlbit= (1 << 7),
> @@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group
> = { .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
> };
>
> +struct clk *exynos5_clkset_usbdrd30_list[] = {
> + [0] = _clk_mout_mpll.clk,
> + [1] = _clk_mout_cpll.clk,
> +};
> +
> +struct clksrc_sources exynos5_clkset_usbdrd30 = {
> + .sources= exynos5_clkset_usbdrd30_list,
> + .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
> +};
> +
> /* Possible clock sources for aclk_266_gscl_sub Mux */
> static struct clk *clk_src_gscl_266_list[] = {
> [0] = _ext_xtal_mux,
> @@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
> .parent = _clk_mout_cpll.clk,
> },
> .reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3
},
> + }, {
> + .clk= {
> + .name = "sclk_usbdrd30",
> + .enable = exynos5_clksrc_mask_fsys_ctrl,
> + .ctrlbit= (1 << 28),
> + },
> + .sources = _clkset_usbdrd30,
> + .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size =
1 },
> + .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
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: [PATCH] tty: Fix ptmx open without closed slave.
> > Ok, I have a ton of patches from you, lots of different threads, patches > with the same subject, and I don't know what one Alan agreed to. > > So, can you please resend what Alan and you agree should be applied to > the tree? > I think only two important: [PATCH v4] tty: Add driver unthrottle in ioctl(...,TCFLSH,..). [PATCH] tty: Correct tty buffer flush. With Alan's ACK from 04.12.2012 for kernel <= 3.7 But for kernel 3.8 I resent this 05.12.2012 [PATCH -next 0/2] tty: Correct tty buffer flush. [PATCH -next 1/2] tty: Correct tty buffer flush. [PATCH -next 2/2] tty: Correct tty buffer flush. The last I resent with new description after Jiri's remark. If need I can resent. -- 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: [GIT PULL] extcon for v3.9
On 01/16/2013 04:28 PM, Greg KH wrote: > On Wed, Jan 16, 2013 at 03:06:53PM +0900, Chanwoo Choi wrote: >> Hi Greg, >> >> This is the extcon pull request for v3.9. >> >> I don't send separate pull request of extcon about bugfixes patch. >> I'd like to apply this patch-set to your next branch for v3.9. >> >> Please pull extcon with following updates. >> >> Update to max77693/max8997 extcon driver: >> - Using MHL_TA cable for charging. >> - Support JIG cable. >> - Support Dock-Audio device for playing music and button of device. >> - Support Dock-Smart device for desktop mode with mouse/keyboard. >> - Set default UART/USB path on probe(). >> - Check the state/type of cable after completing initialization. >> - Code clean to remove duplicate code and bug fix related to sequence of >> interrupt. >> - Fix irq_flag of max8997/max77693 driver. >> >> Update to arizona extcon driver: >> - Headphone measurements. >> - Alternative detection mechanism for non-default system designs. >> - Microphone clamp integration. >> - Support for additional detection pin. >> - MICBIAS rise time configuration. >> >> Best regards, >> Chanwoo Choi >> >> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: >> >> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git >> tags/extcon-for-3.9 > > Pulled and pushed out, thanks. > Thank you for pulling and comment. Best Regards, Chanwoo Choi -- 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 v4 2/4] ARM: Exynos5250: Enabling ohci-exynos driver
Hi Vivek,
On Tuesday 15 of January 2013 19:08:30 Vivek Gautam wrote:
> Adding OHCI device tree node for Exynos5250 along with
> the device base address.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 15
> +++ arch/arm/boot/dts/exynos5250.dtsi |
> 6 ++ 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
> e8bbb47..f66fcdd 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -23,3 +23,18 @@ Example:
> interrupts = <0 71 0>;
> samsung,vbus-gpio = < 6 1 3 3>;
> };
> +
> +OHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
> + OHCI companion controller in host mode.
> + - reg: physical base address of the controller and length of memory
> mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> + usb@1212 {
> + compatible = "samsung,exynos4210-ohci";
> + reg = <0x1212 0x100>;
> + interrupts = <0 71 0>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index 2cbe53e..ebb0907 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -281,6 +281,12 @@
> interrupts = <0 71 0>;
> };
>
> + usb@1212 {
> + compatible = "samsung,exynos4210-ohci";
> + reg = <0x1212 0x100>;
> + interrupts = <0 71 0>;
For Samsung platforms we decided per board enabling of nodes and so this
node should also contain:
status = "disabled";
while in dts file of board using ohci there would be an overriding entry:
usb@1212 {
status = "okay";
};
I know that Exynos5250 has not been yet converted into this convention,
but using it when adding new devices will simplify the process.
Best regards,
Tomasz
--
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 v3 05/22] sched: remove domain iterations in fork/exec/wake
On 01/16/2013 01:43 PM, Alex Shi wrote:
> - /* while loop will break here if sd == NULL */
>>>
>>> I agree that this should be a major optimization. I just can't figure
>>> out why the existing recursive search for an idle cpu switches to the
>>> new cpu near the end and then starts a search for an idle cpu in the new
>>> cpu's domain. Is this to handle some exotic sched domain configurations?
>>> If so, they probably wouldn't work with your optimizations.
>>
>> Let me explain my understanding of why the recursive search is the way
>> it is.
>>
>> _ sd0
>> | |
>> | ___sd1__ ___sd2__|
>> | || || |
>> | | sgx| | sga | |
>> | | sgy| | sgb | |
>> | || || |
>> |_|
>>
>> What the current recursive search is doing is (assuming we start with
>> sd0-the top level sched domain whose flags are rightly set). we find
>> that sd1 is the idlest group,and a cpux1 in sgx is the idlest cpu.
>>
>> We could have ideally stopped the search here.But the problem with this
>> is that there is a possibility that sgx is more loaded than sgy; meaning
>> the cpus in sgx are heavily imbalanced;say there are two cpus cpux1 and
>> cpux2 in sgx,where cpux2 is heavily loaded and cpux1 has recently gotten
>> idle and load balancing has not come to its rescue yet.According to the
>> search above, cpux1 is idle,but is *not the right candidate for
>> scheduling forked task,it is the right candidate for relieving the load
>> from cpux2* due to cache locality etc.
>
> The problem still exists on the current code. It still goes to cpux1.
> and then goes up to sgx to seek idlest group ... idlest cpu, and back to
> cpux1 again. nothing help.
>
>
to resolve the problem, I has tried to walk domains from top down. but testing
show aim9/hackbench performance is not good on our SNB EP. and no change on
other platforms.
---
@@ -3351,51 +3363,33 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
- while (sd) {
+ for_each_lower_domain(sd) {
int load_idx = sd->forkexec_idx;
- struct sched_group *group;
- int weight;
-
- if (!(sd->flags & sd_flag)) {
- sd = sd->child;
- continue;
- }
+ int local = 0;
if (sd_flag & SD_BALANCE_WAKE)
load_idx = sd->wake_idx;
- group = find_idlest_group(sd, p, cpu, load_idx);
- if (!group) {
- sd = sd->child;
- continue;
- }
-
- new_cpu = find_idlest_cpu(group, p, cpu);
- if (new_cpu == -1 || new_cpu == cpu) {
- /* Now try balancing at a lower domain level of cpu */
- sd = sd->child;
+ group = find_idlest_group(sd, p, cpu, load_idx, );
+ if (local)
continue;
- }
+ if (!group)
+ goto unlock;
- /* Now try balancing at a lower domain level of new_cpu */
- cpu = new_cpu;
- weight = sd->span_weight;
- sd = NULL;
- for_each_domain(cpu, tmp) {
- if (weight <= tmp->span_weight)
- break;
- if (tmp->flags & sd_flag)
+ /* go down from non-local group */
+ for_each_domain(group_first_cpu(group), tmp)
+ if (cpumask_equal(sched_domain_span(tmp),
+ sched_group_cpus(group))) {
sd = tmp;
- }
- /* while loop will break here if sd == NULL */
+ break;
+ }
}
+ if (group)
+ new_cpu = find_idlest_cpu(group, p, cpu);
unlock:
rcu_read_unlock();
--
Thanks Alex
--
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] sysfs: sysfs_update_group always fails and generates a WARNING CALL-trace
Sorry. I'm a fresh. This is my first patch commit. And still now *mutt*
does not configured properly.
I will study howto and commit patch again. Sorry.
---
On Wed, Jan 16, 2013 at 03:04:25PM +0800, yanyg wrote:
@sysfs_update_group@ always fails and borns a WARNING CALL-trace
if the group exists. BUT still now, no *reference* of this routine at all.
I don't understand.
OK, sysfs routine @sysfs_update_group@ *never* works properly
>From fe40df7d716658a1fbdab79768628c81d4363428 Mon Sep 17 00:00:00 2001
From: yanyg
Date: Wed, 16 Jan 2013 11:25:15 +0800
Subject: [PATCH] sysfs-fixes:
@sysfs_update_group@ always fail and generates WARNING CALL trace.
fix @internal_create_group@ to avoid it.
Why did you embed the patch here, with the words above it? I would have
to edit it to apply it :(
It's also not in a format I can apply (no signed-off-by: line.)
So sorry.
---
fs/sysfs/group.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 2df555c..51fcf62 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -60,7 +60,7 @@ static int internal_create_group(struct kobject *kobj, int
update,
const struct attribute_group *grp)
{
struct sysfs_dirent *sd;
- int error;
+ int error, do_put = 0;
BUG_ON(!kobj || (!update && !kobj->sd));
@@ -73,9 +73,14 @@ static int internal_create_group(struct kobject *kobj, int update,
return -EINVAL;
}
if (grp->name) {
- error = sysfs_create_subdir(kobj, grp->name, );
- if (error)
- return error;
+ sd = sysfs_get_dirent(kobj->sd, NULL, grp->name);
+ if (sd) {
+ do_put = 1;
+ } else {
+ error = sysfs_create_subdir(kobj, grp->name, );
+ if (error)
+ return error;
+ }
} else
sd = kobj->sd;
sysfs_get(sd);
@@ -85,6 +90,7 @@ static int internal_create_group(struct kobject *kobj, int
update,
sysfs_remove_subdir(sd);
}
sysfs_put(sd);
+ if (do_put) sysfs_put(sd);
Always run your patches through scripts/checkpatch.pl and fix the
problems it tells you about.
What code in the kernel is hitting this today?
I write a simply virtual block device driver which calls
@sysfs_update_group@ to updates attributes and modes, it fails.
YOU can reproduce the bug by append @sysfs_update_group@ at below any of
@sysfs_create_group@ call.
thanks,
greg k-h
So too sorry for my silly.
yanyg02
--
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] thermal: sysfs: Add a new sysfs node emul_temp
Hi, Amit,
On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
> This patch adds support to set the emulated temperature method in
> thermal zone (sensor). After setting this feature thermal zone must
> report this temperature and not the actual temperature. The actual
> implementation of this emulated temperature is based on sensor
> capability or platform specific. This is useful in debugging different
> temperature threshold and its associated cooling action. Writing 0 on
> this node should disable emulation.
Question:
will this bring hardware issue? Say, critical temperature reached while
in emulation mode?
As this is for debug purpose, I'd prefer to have a seperate Kconfig
option for this feature.
> Signed-off-by: Amit Daniel Kachhap
> ---
> Documentation/thermal/sysfs-api.txt | 14 ++
> drivers/thermal/thermal_sys.c | 26 ++
> include/linux/thermal.h |1 +
> 3 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> index 88c0233..e8f2ee4 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
> .get_trip_type: get the type of certain trip point.
> .get_trip_temp: get the temperature above which the certain trip point
> will be fired.
> + .set_emul_temp: set the emulation temperature which helps in debugging
> + different threshold temperature points.
>
> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>
> @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered:
> |---trip_point_[0-*]_temp: Trip point temperature
> |---trip_point_[0-*]_type: Trip point type
> |---trip_point_[0-*]_hyst: Hysteresis value for this trip point
> +|---emul_temp: Emulated temperature set node
>
> Thermal cooling device sys I/F, created once it's registered:
> /sys/class/thermal/cooling_device[0-*]:
> @@ -252,6 +255,17 @@ passive
> Valid values: 0 (disabled) or greater than 1000
> RW, Optional
>
> +emul_temp
> + Interface to set the emulated temperature method in thermal zone
> + (sensor). After setting this feature thermal zone must report
> + this temperature and not the actual temperature. The actual
> + implementation of this emulated temperature is platform specific.
can we have a pure software temperature emulation method?
say, the generic thermal layer caches the emulated temperature value,
and hook it in update_temperature()?
This is also useful for testing in polling mode, and it does not require
platform specific callback support. I mean thermal_ops->set_emul_temp is
optional, but thermal emulation is always available for all platforms.
thanks,
rui
> + This is useful in debugging different temperature threshold and its
> + associated cooling action. Writing 0 on this node should disable
> + emulation.
> + Unit: millidegree Celsius
> + WO, Optional
> +
> *
> * Cooling device attributes *
> *
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 8c8ce80..ecdfc7d 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct device_attribute
> *devattr, char *buf)
> return sprintf(buf, "%s\n", tz->governor->name);
> }
>
> +static ssize_t
> +emul_temp_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct thermal_zone_device *tz = to_thermal_zone(dev);
> + int ret;
> + unsigned long temperature;
> +
> + if (!tz->ops->set_emul_temp)
> + return -EPERM;
> +
> + if (kstrtoul(buf, 10, ))
> + return -EINVAL;
> +
> + ret = tz->ops->set_emul_temp(tz, temperature);
> +
> + return ret ? ret : count;
> +}
> +
> static DEVICE_ATTR(type, 0444, type_show, NULL);
> static DEVICE_ATTR(temp, 0444, temp_show, NULL);
> static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
> static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
> static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
> +static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
>
> /* sys I/F for cooling device */
> #define to_cooling_device(_dev) \
> @@ -1592,6 +1612,12 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
> goto unregister;
> }
>
> + if (ops->set_emul_temp) {
> + result = device_create_file(>device, _attr_emul_temp);
> + if (result)
> + goto unregister;
> + }
> +
> /* Create policy attribute */
>
Re: [PATCH] printk: Avoid softlockups in console_unlock()
On Tue, 15 Jan 2013 18:58:34 +0100 Jan Kara wrote: > A CPU can be caught in console_unlock() for a long time (tens of seconds are > reported by our customers) when other CPUs are using printk heavily and serial > console makes printing slow. This triggers softlockup warnings because > interrupts are disabled for the whole time console_unlock() runs (e.g. > vprintk() calls console_unlock() with interrupts disabled). It should trigger the NMI watchdog in that case? > We fix the issue by printing at most 1 KB of messages (unless we are in an > early boot stage or oops is happening) in one console_unlock() call. The rest > of the buffer will be printed either by further callers to printk() or by a > queued work. Complex. Did you try just putting a touch_nmi_watchdog() in the loop? -- 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 v3 17/22] sched: packing small tasks in wake/exec balancing
On 01/15/2013 01:00 AM, Morten Rasmussen wrote: >>> Why multiply rq->util by nr_running? >>> > > >>> > > Let's take an example where rq->util = 50, nr_running = 2, and putil = >>> > > 10. In this case the value of putil doesn't really matter as vacancy >>> > > would be negative anyway since FULL_UTIL - rq->util * nr_running is -1. >>> > > However, with rq->util = 50 there should be plenty of spare cpu time to >>> > > take another task. >> > >> > for this example, the util is not full maybe due to it was just wake up, >> > it still is possible like to run full time. So, I try to give it the >> > large guess load. > I don't see why rq->util should be treated different depending on the > number of tasks causing the load. rq->util = 50 means that the cpu is > busy about 50% of the time no matter how many tasks contibute to that > load. > > If nr_running = 1 instead in my example, you would consider the cpu > vacant if putil = 6, but if nr_running > 1 you would not. Why should the > two scenarios be treated differently? > >>> > > >>> > > Also, why multiply putil by 8? rq->util must be very close to 0 for >>> > > vacancy to be positive if putil is close to 12 (12.5%). >> > >> > just want to pack small util tasks, since packing is possible to hurt >> > performance. > I agree that packing may affect performance. But why don't you reduce > FULL_UTIL instead of multiplying by 8? With current expression you will > not pack a 10% task if rq->util = 20 and nr_running = 1, but you would > pack a 6% task even if rq->util = 50 and the resulting cpu load is much > higher. > Yes, the threshold has no strong theory or experiment support. I had tried cyclitest which Vicent used, the case's load avg is too small to be caught. so just use half of Vicent value as 12.5%. If you has more reasonable value, let me know. As to nr_running engaged as multiple mode. it's base on 2 reasons. 1, load avg/util need 345ms to accumulate as 100%. so, if a tasks is cost full cpu time, it still has 345ms with rq->util < 1. 2, if there are more tasks, like 2 tasks running on one cpu, it's possible to has capacity to burn 200% cpu time, while the biggest rq->util is still 100%. Consider to figure out precise utils is complicate and cost much. I do this simple calculation. It is not very precise, but it is efficient and more bias toward performance. -- Thanks Alex -- 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 net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
Hello Byungho,
On 1/15/2013 10:45 PM, Byungho An wrote:
This patch adds gmac autoneg set function for SGMII, TBI,
or RTBI interface. In case of PHY's autoneg is set, gmac's
autoneg enable bit should set. After checking phy's autoneg
if phydev's autoneg is '1' gmac's ANE bit set for those
interface.
Sorry I've some doubts about these patches.
Firstly if the MAC is able to manage RGMII/SGMII etc this should be
verified by looking at the HW cap register: i.e. PCS bit.
(I have no HW that support this so I cannot do any tests).
In case of this feature is actually supported then the driver could
manage everything bypassing the MDIO.
IMO, we could not need to call the stmmac_phy_init and we should not
use the PHYLIB.
I mean if we have the PCS module we could have a minimal support to get
link status, restart ANE etc w/o using at all the PHYLIB (so w/o
touching the PHY regs via the MDIO/MDC).
It could also be useful to complete the support with the RGMII... no
extra effort should be needed while adding SGMII if you look at the
core registers.
If you add the RGMII on some platforms we could guarantee to manage
the fix_mac_speed (see stmmac doc).
Looking at the other your patches, the ethtool support is not
completed. I expected to restart ANE, get/set link property etc.
Also pay attention to properly treat EEE. Maybe, as first stage we
should disable the feature in this case. We will see it later.
The question is that we could not be able to use some extra features
that currently need to dialog more with the PHY device. I mean what we
actually do by using PHYLIB.
Signed-off-by: Byungho An
---
drivers/net/ethernet/stmicro/stmmac/common.h |1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c|9 +
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void __iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
pls use define instead of raw values ... see below.
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
+
+
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -311,6 +321,7 @@ static const struct stmmac_ops dwmac1000_ops = {
.reset_eee_mode = dwmac1000_reset_eee_mode,
.set_eee_timer = dwmac1000_set_eee_timer,
.set_eee_pls = dwmac1000_set_eee_pls,
+ .set_autoneg = dwmac1000_set_autoneg,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f07c061..3e28934 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1007,6 +1007,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ int interface = priv->plat->interface;
clk_prepare_enable(priv->stmmac_clk);
@@ -1041,6 +1042,14 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ /* If phy autoneg is on, set gmac autoneg for SGMII, TBI and RTBI*/
+ if (interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_TBI ||
+ interface == PHY_INTERFACE_MODE_RTBI) {
+ if (priv->phydev->autoneg)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
+ }
we could use the following instead of priv->hw->mac->set_autoneg:
static void dwmac1000_ctrl_ane(void __iomem *ioaddr, bool restart)
{
int value = GMAC_CTRL_ANE_EN;
if (restart)
value |= GMAC_CTRL_ANE_RESTART;
writel(value, ioaddr +GMAC_AN_CTRL);
}
where we should defines all the missing macros for the registers 48, 49 ...
/* RGMI/SGMII defines */
#define GMAC_CTRL_ANE_SGMII_RAL
Re: [GIT PULL] extcon for v3.9
On Wed, Jan 16, 2013 at 03:06:53PM +0900, Chanwoo Choi wrote: > Hi Greg, > > This is the extcon pull request for v3.9. > > I don't send separate pull request of extcon about bugfixes patch. > I'd like to apply this patch-set to your next branch for v3.9. > > Please pull extcon with following updates. > > Update to max77693/max8997 extcon driver: > - Using MHL_TA cable for charging. > - Support JIG cable. > - Support Dock-Audio device for playing music and button of device. > - Support Dock-Smart device for desktop mode with mouse/keyboard. > - Set default UART/USB path on probe(). > - Check the state/type of cable after completing initialization. > - Code clean to remove duplicate code and bug fix related to sequence of > interrupt. > - Fix irq_flag of max8997/max77693 driver. > > Update to arizona extcon driver: > - Headphone measurements. > - Alternative detection mechanism for non-default system designs. > - Microphone clamp integration. > - Support for additional detection pin. > - MICBIAS rise time configuration. > > Best regards, > Chanwoo Choi > > The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: > > Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-for-3.9 Pulled and pushed out, thanks. 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: [GIT PULL] irqchip init infrastructure and GIC/VIC move
On 01/14/2013 09:56 PM, Olof Johansson wrote: > On Sat, Jan 12, 2013 at 9:37 AM, Rob Herring wrote: >> Arnd, Olof, >> >> Please pull for 3.9. This is the initial infrastructure and conversion >> of the GIC and VIC to use it. Several people are waiting for the irqchip >> infrastructure to go in in order to convert other irqchip code over. >> >> I've left "static asmlinkage" in on the irq handlers. There's been no >> more discussion, so I think we are in agreement. If asmlinkage defines >> the procedure call convention for assembly calls, then it still makes >> sense to have it on a static function called thru a function pointer. >> >> Rob >> >> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: >> >> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) >> >> are available in the git repository at: >> >> git://sources.calxeda.com/kernel/linux.git tags/gic-vic-to-irqchip > > Ugh. This conflicts heavily with the timer cleanup from Stephen, due > to adjacent changes in the machine descriptors. > > I fixed them up, but I would appreciate a second glance at them for > sanity checking. Sorry about that. It all looks correct to me. Rob -- 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] sysfs: sysfs_update_group always fails and generates a WARNING CALL-trace
On Wed, Jan 16, 2013 at 03:04:25PM +0800, yanyg wrote:
> @sysfs_update_group@ always fails and borns a WARNING CALL-trace
> if the group exists. BUT still now, no *reference* of this routine at all.
I don't understand.
> >From fe40df7d716658a1fbdab79768628c81d4363428 Mon Sep 17 00:00:00 2001
> From: yanyg
> Date: Wed, 16 Jan 2013 11:25:15 +0800
> Subject: [PATCH] sysfs-fixes:
>
> @sysfs_update_group@ always fail and generates WARNING CALL trace.
> fix @internal_create_group@ to avoid it.
Why did you embed the patch here, with the words above it? I would have
to edit it to apply it :(
It's also not in a format I can apply (no signed-off-by: line.)
> ---
> fs/sysfs/group.c | 14 ++
> 1 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index 2df555c..51fcf62 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -60,7 +60,7 @@ static int internal_create_group(struct kobject *kobj, int
> update,
>const struct attribute_group *grp)
> {
> struct sysfs_dirent *sd;
> - int error;
> + int error, do_put = 0;
>
> BUG_ON(!kobj || (!update && !kobj->sd));
>
> @@ -73,9 +73,14 @@ static int internal_create_group(struct kobject *kobj, int
> update,
> return -EINVAL;
> }
> if (grp->name) {
> - error = sysfs_create_subdir(kobj, grp->name, );
> - if (error)
> - return error;
> + sd = sysfs_get_dirent(kobj->sd, NULL, grp->name);
> + if (sd) {
> + do_put = 1;
> + } else {
> + error = sysfs_create_subdir(kobj, grp->name, );
> + if (error)
> + return error;
> + }
> } else
> sd = kobj->sd;
> sysfs_get(sd);
> @@ -85,6 +90,7 @@ static int internal_create_group(struct kobject *kobj, int
> update,
> sysfs_remove_subdir(sd);
> }
> sysfs_put(sd);
> + if (do_put) sysfs_put(sd);
Always run your patches through scripts/checkpatch.pl and fix the
problems it tells you about.
What code in the kernel is hitting this today?
thanks,
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: [RFC PATCH 0/7] usb: musb: add driver for control module
On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote: > Hi Ravi, > > On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: > >>Hi, > >> > >>On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: > >>>Hi Arnd, > >>> > >>>On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: > On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: > >Added a new driver for the usb part of control module. > >>This has an > >API to power on the USB2 phy and an API to write to the mailbox > >depending on whether MUSB has to act in host mode or in > >>device mode. > > > >Writing to control module registers for doing the above > >>task which > >was previously done in omap glue and in omap-usb2 phy is removed. > > > >Also added the dt data to get MUSB working in OMAP platforms. > >This series has patches for both drivers and ARCH > >>folders, so If it > >has to be split I'll do it. > > > > The series looks good to me, I just had a minor comment on > >>one patch. > > One a somewhat related topic, I wonder whether there are > >>any plans on > your side to change this driver to support multiple bus > >>glues to be > built for one kernel image. With a multiplatform kernel, > >>we may need > all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. > >>> > >>>We don't have plans as of now. I actually don't expect any > >>changes in > >>>the driver other than the Kconfig changes. Anyways the > >>probe of glue's > >>>other than the platform it's running won't get called. right Felipe? > > > >If understand correctly the control module driver used to configure the > >respective usb phy of SoC to respective usb modes using the common set of > >control module APIs. > What if, if control module interface (register defintions) varies b/w > different revision or spin of same type of SoCs, if usbphy type is > changed. > Well in that case, we can write to the registers based on the IP > revision check (I think thats the common practice to do). > > In this case whether the single instance of control module driver is > good enough to cater of all cpu types of same SoC series ? > Of course. I don't see why we can't have the same driver to handle > different versions of the same IP. > The only reason where we might need multiple instance is if the SoC > have multiple control module which Arnd already pointed out. > > >Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in > >CM driver? > Not needed at all IMHO. We can use revision register to differentiate. > > Btw I think Felipe looped you for a different reason ;-) right, it was to look at removing inclusion from all davinci-link glue layers (they should be combined, btw). -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] extcon for 3.8-rc4
On 01/16/2013 03:46 PM, Greg KH wrote: > On Wed, Jan 16, 2013 at 12:38:35PM +0900, Chanwoo Choi wrote: OK, I will resend pull-request to include only bugfixes patch in 3.8. After released v3.8-rc7 or 3.8-rc8 kernel, I will send pull-request of extcon to include new feature patches of extcon driver in 3.9. >>> >>> No, you can send me that pull request now as well, I have two different >>> branches, one to go to Linus for this release, and one for the next one. >>> Both of them show up in linux-next. You should have the same. >>> >>> So you can send me two pull requests now, does that make more sense? >>> >> I understand and thanks for your comment. I will resend only one >> pull-request for >> extcon to include it for -next branch. I don't send separate pull-request >> for bugfixes patch. > > Why not send a bugfix pull request? Are none of these for 3.8? If so, > fine, but be sure to go through them to determine this. I think that it isn't critical bug and relevant to extcon core driver. And The issue is trivial and depend on new feature of max77693 extcon driver. Thank you, Chanwoo Choi -- 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] usb: phy: remove unused APIs from Tegra PHY.
Hi, On Tue, Jan 15, 2013 at 11:04:51AM -0700, Stephen Warren wrote: > On 01/15/2013 03:19 AM, Venu Byravarasu wrote: > > As tegra_usb_phy_clk_disable/enable() are not being > > used, removing them. > > Greg, Felipe, > > Again if I may, I'll take this through the Tegra tree. I think the next > set of patches that Venu posts should actually expose the dependencies > between his USB patches and the Tegra clock framework rework, which are > why I want to do this. that should be ok: Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: Use of memmap= to forcibly recover memory in 3GB-4GB range - is this safe?
On Tue, Jan 15, 2013 at 5:47 PM, Alex Villacís Lasso wrote: > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable > [0.00] BIOS-e820: [mem 0x0009f400-0x0009] > reserved > [0.00] BIOS-e820: [mem 0x000f-0x000f] > reserved > [0.00] BIOS-e820: [mem 0x0010-0xcf58] usable > [0.00] BIOS-e820: [mem 0xcf59-0xcf5e2fff] ACPI > NVS > [0.00] BIOS-e820: [mem 0xcf5e3000-0xcf5e] ACPI > data > [0.00] BIOS-e820: [mem 0xcf5f-0xcf5f] > reserved > [0.00] BIOS-e820: [mem 0xe000-0xefff] > reserved > [0.00] BIOS-e820: [mem 0xfec0-0x] > reserved > [0.00] NX (Execute Disable) protection: active .. > [0.00] original variable MTRRs > [0.00] reg 0, base: 4GB, range: 512MB, type WB > [0.00] reg 1, base: 4608MB, range: 256MB, type WB > [0.00] reg 2, base: 0GB, range: 2GB, type WB > [0.00] reg 3, base: 2GB, range: 1GB, type WB > [0.00] reg 4, base: 3GB, range: 256MB, type WB > [0.00] reg 5, base: 3319MB, range: 1MB, type UC > [0.00] reg 6, base: 3320MB, range: 8MB, type UC > [0.00] reg 7, base: 3318MB, range: 1MB, type UC > [0.00] total RAM covered: 4086M Can you apply attached debug patch to see if the raw e820 is right from BIOS ? Yinghai print_raw_e820.patch Description: Binary data
Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
Mimi Zohar writes: > Please remind me why you can't use IMA-appraisal, which was upstreamed > in Linux 3.7? Why another method is needed? Good question Vivek? I remeber there was a slight mismatch in the desired attributes. In particular we want signatures that are not generated on the local machine. > With IMA-appraisal, there are a couple of issues that would still need > to be addressed: > - missing the ability to specify the validation method required. > - modify the ima_appraise_tcb policy policy to require elf executables > to be digitally signed. > - security_bprm_check() is called before the binary handler is known. > > The first issue is addressed by a set of patches queued to be upstreamed > in linux-integrity/next-ima-appraise-status. > > To address the last issue would either require moving the existing > bprm_check or defining a new hook after the binary handler is known. Even if there is a small mismatch it certainly sounds like something to investigate. There are a lot of pieces flying around with IMA so an appropriate model of what needs to happen isn't in my head. As opposed to a signature in an ELF executable and a key in the kernel. Hooks aside in an IMA world where does the signing key live? Where does the signature live? Eric -- 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] sysfs: sysfs_update_group always fails and generates a WARNING CALL-trace
@sysfs_update_group@ always fails and borns a WARNING CALL-trace
if the group exists. BUT still now, no *reference* of this routine at all.
>From fe40df7d716658a1fbdab79768628c81d4363428 Mon Sep 17 00:00:00 2001
From: yanyg
Date: Wed, 16 Jan 2013 11:25:15 +0800
Subject: [PATCH] sysfs-fixes:
@sysfs_update_group@ always fail and generates WARNING CALL trace.
fix @internal_create_group@ to avoid it.
---
fs/sysfs/group.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 2df555c..51fcf62 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -60,7 +60,7 @@ static int internal_create_group(struct kobject *kobj, int
update,
const struct attribute_group *grp)
{
struct sysfs_dirent *sd;
- int error;
+ int error, do_put = 0;
BUG_ON(!kobj || (!update && !kobj->sd));
@@ -73,9 +73,14 @@ static int internal_create_group(struct kobject *kobj, int
update,
return -EINVAL;
}
if (grp->name) {
- error = sysfs_create_subdir(kobj, grp->name, );
- if (error)
- return error;
+ sd = sysfs_get_dirent(kobj->sd, NULL, grp->name);
+ if (sd) {
+ do_put = 1;
+ } else {
+ error = sysfs_create_subdir(kobj, grp->name, );
+ if (error)
+ return error;
+ }
} else
sd = kobj->sd;
sysfs_get(sd);
@@ -85,6 +90,7 @@ static int internal_create_group(struct kobject *kobj, int
update,
sysfs_remove_subdir(sd);
}
sysfs_put(sd);
+ if (do_put) sysfs_put(sd);
return error;
}
--
1.7.2.5
--
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] tty: Fix ptmx open without closed slave.
On Wed, Dec 19, 2012 at 11:00:05PM +0400, Ilya Zykov wrote: > When we are opening ptmx, we have closed pts, by description. > Now only if we open and after close all pts' descriptions, pty_close() sets > this bit correctly > > Signed-off-by: Ilya Zykov Ok, I have a ton of patches from you, lots of different threads, patches with the same subject, and I don't know what one Alan agreed to. So, can you please resend what Alan and you agree should be applied to the tree? totally confused, 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: Use of memmap= to forcibly recover memory in 3GB-4GB range - is this safe?
On Tue, Jan 15, 2013 at 6:28 PM, H. Peter Anvin wrote: > On 01/15/2013 05:47 PM, Alex Villacís Lasso wrote: >> 2) I have recompiled the kernel to support the memtest parameter. When >> using it, the extra memory segment appears to be as healthy as other >> areas of memory. However this might only mean that it is wrapping into >> healthy low RAM. memtest should print out about the range. and if you are using 64bit kernel, it should test all memory except for range with kernel itself. >> >> Is my reasoning sane? Is there a way to know, once and for all, whether >> the extra "memory" is real and safe to use or not? > > > Maybe you can get memtest86+ to test this phantom memory? But yes, it does > sound like a BIOS bug. that may not help, because e820 from bios is not right. Yinghai -- 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] 8250/16?50: Add support for Broadcom TruManage redirected serial port
On Wed, Dec 12, 2012 at 05:28:35AM +, Stephen Hurd wrote: > From: Stephen Hurd > > Add support for the UART device present in Broadcom TruManage capable > NetXtreme chips (ie: 5761m 5762, and 5725). > > This implementation has a hidden transmit FIFO, so running in single-byte > interrupt mode results in too many interrupts. The UART_CAP_HFIFO capability > was added to track this. It continues to reload the THR as long as the THRE > and TSRE bits are set in the LSR up to a specified limit (1024 is used here). > > Signed-off-by: Stephen Hurd > > --- > > Patch against linux-2.7 from ftp.kernel.org downloaded Dec-11-2012. 2.7? I need this against the linux-next release, can you please redo it, and not send it as an attachment, but put it all inline in the email properly like Documentation/email_clients.txt says? thanks, 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/
[no subject]
subscribe linux-kernel -- 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/4] serial: tty: Cleanup code using devm_ function
On Tue, Jan 15, 2013 at 05:58:06PM +1300, Tony Prisk wrote: > Convert the last memory allocation (vt8500_port) to use devm_kzalloc > and remove the fail path cleanup code from vt8500_serial_probe. > > Reorder iomem mapping above clk_enable to simplify fail code. The > clock is only enabled if all other resources are available. > > Signed-off-by: Tony Prisk You've send a few different versions of this patch, with no indication as to what changed, or what one I should take. Care to send me the correct one? thanks, 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 00/10] TTY: switch flipping functions to tty_port
On Thu, Jan 03, 2013 at 03:53:00PM +0100, Jiri Slaby wrote: > In this series we get rid of the tty_port_tty_get in most hot paths as > all the flipping functions needs to know is in tty_port already. This > simplifies the code at some places a lot. > > Two fixes for coverity issues are included. All applied, but the drivers/staging/sb105x/ driver is now broken, can you send me a follow-on patch to fix it? thanks, 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: [GIT PULL] extcon for 3.8-rc4
On Wed, Jan 16, 2013 at 12:38:35PM +0900, Chanwoo Choi wrote: > >> OK, I will resend pull-request to include only bugfixes patch in 3.8. > >> After released v3.8-rc7 or 3.8-rc8 kernel, I will send pull-request of > >> extcon > >> to include new feature patches of extcon driver in 3.9. > > > > No, you can send me that pull request now as well, I have two different > > branches, one to go to Linus for this release, and one for the next one. > > Both of them show up in linux-next. You should have the same. > > > > So you can send me two pull requests now, does that make more sense? > > > I understand and thanks for your comment. I will resend only one pull-request > for > extcon to include it for -next branch. I don't send separate pull-request > for bugfixes patch. Why not send a bugfix pull request? Are none of these for 3.8? If so, fine, but be sure to go through them to determine this. thanks, 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/
[GIT PULL] x86 fixes for v3.8-rc4
Hi Linus,
This is mainly a workaround for a bug in Sandy Bridge graphics which
cause corruption of certain memory pages.
The following changes since commit 787314c35fbb97e02823a1b8eb8cfa58f366cd49:
Merge tag 'iommu-updates-v3.8' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu (2012-12-20 10:07:25
-0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
The head of this tree is e43b3cec711a61edf047adf6204d542f3a659ef8:
x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI (2013-01-13
20:58:57 -0800)
H. Peter Anvin (2):
x86/Sandy Bridge: mark arrays in __init functions as __initconst
x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
Jesse Barnes (1):
x86/Sandy Bridge: reserve pages when integrated graphics is present
Sasha Levin (1):
x86, efi: correct precedence of operators in setup_efi_pci
arch/x86/boot/compressed/eboot.c | 2 +-
arch/x86/kernel/setup.c | 80
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b1942e2..18e329c 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -302,7 +302,7 @@ static efi_status_t setup_efi_pci(struct boot_params
*params)
if (status != EFI_SUCCESS)
continue;
- if (!attributes & EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM)
+ if (!(attributes & EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM))
continue;
if (!pci->romimage || !pci->romsize)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 23ddd55..00f6c14 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -610,6 +610,83 @@ static __init void reserve_ibft_region(void)
static unsigned reserve_low = CONFIG_X86_RESERVE_LOW << 10;
+static bool __init snb_gfx_workaround_needed(void)
+{
+#ifdef CONFIG_PCI
+ int i;
+ u16 vendor, devid;
+ static const __initconst u16 snb_ids[] = {
+ 0x0102,
+ 0x0112,
+ 0x0122,
+ 0x0106,
+ 0x0116,
+ 0x0126,
+ 0x010a,
+ };
+
+ /* Assume no if something weird is going on with PCI */
+ if (!early_pci_allowed())
+ return false;
+
+ vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
+ if (vendor != 0x8086)
+ return false;
+
+ devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
+ for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
+ if (devid == snb_ids[i])
+ return true;
+#endif
+
+ return false;
+}
+
+/*
+ * Sandy Bridge graphics has trouble with certain ranges, exclude
+ * them from allocation.
+ */
+static void __init trim_snb_memory(void)
+{
+ static const __initconst unsigned long bad_pages[] = {
+ 0x2005,
+ 0x2011,
+ 0x2013,
+ 0x20138000,
+ 0x40004000,
+ };
+ int i;
+
+ if (!snb_gfx_workaround_needed())
+ return;
+
+ printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
+
+ /*
+* Reserve all memory below the 1 MB mark that has not
+* already been reserved.
+*/
+ memblock_reserve(0, 1<<20);
+
+ for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
+ if (memblock_reserve(bad_pages[i], PAGE_SIZE))
+ printk(KERN_WARNING "failed to reserve 0x%08lx\n",
+ bad_pages[i]);
+ }
+}
+
+/*
+ * Here we put platform-specific memory range workarounds, i.e.
+ * memory known to be corrupt or otherwise in need to be reserved on
+ * specific platforms.
+ *
+ * If this gets used more widely it could use a real dispatch mechanism.
+ */
+static void __init trim_platform_memory_ranges(void)
+{
+ trim_snb_memory();
+}
+
static void __init trim_bios_range(void)
{
/*
@@ -630,6 +707,7 @@ static void __init trim_bios_range(void)
* take them out.
*/
e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), _map);
}
@@ -908,6 +986,8 @@ void __init setup_arch(char **cmdline_p)
setup_real_mode();
+ trim_platform_memory_ranges();
+
init_gbpages();
/* max_pfn_mapped is updated here */
--
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 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
On 1/15/2013 9:49 PM, James Bottomley wrote: On Tue, 2013-01-15 at 21:31 +0530, Subhash Jadavani wrote: blk_rq_map_sg() function merges the physically contiguous pages to use same scatter-gather node without checking if their page descriptors are contiguous or not. Now when dma_map_sg() is called on the scatter gather list, it would take the base page pointer from each node (one by one) and iterates through all of the pages in same sg node by keep incrementing the base page pointer with the assumption that physically contiguous pages will have their page descriptor address contiguous which may not be true if SPARSEMEM config is enabled. So here we may end referring to invalid page descriptor. Following table shows the example of physically contiguous pages but their page descriptor addresses non-contiguous. --- | Page Descriptor| Physical Address | -- | 0xc1e43fdc | 0xd000 | | 0xc2052000 | 0xe000 | --- With this patch, relevant blk-merge functions will also check if the physically contiguous pages are having page descriptors address contiguous or not? If not then, these pages are separated to be in different scatter-gather nodes. How does this manifest as a bug? The discontinuity is in struct page arrays, which hardware doesn't care about. All we need is to get from struct page to the physical address for programming the hardware, for which we use the sg_phys() inline function. Even given we have a two page physical contiguity at 0xd000 in your example, the sg list entry contains a length of 8192 and a page_link of 0xc1e43fdc, which we transform to the correct physical address and length. Thanks James for looking at this patch. Let's assume this scenario. PAGE_SIZE = 4096 (4K), 2 page descriptors (as mentioned commit text) whose own addresses are discontingous but they point to physically contiguous memory space, sizeof(struct page) is 36 bytes. Only one SG node created in Scatter Gather list (by blk_rq_map_sg) with this node's page_link=0xc1e43fdc, length=8192, offset=0 Now consider this call stack from MMC block driver (this is on the ARmv7 based board): [ 98.918174] [] (v7_dma_inv_range+0x30/0x48) from [] (dma_cache_maint_page+0x1c4/0x24c) [ 98.927819] [] (dma_cache_maint_page+0x1c4/0x24c) from [] (___dma_page_cpu_to_dev+0x14/0x1c) [ 98.937982] [] (___dma_page_cpu_to_dev+0x14/0x1c) from [] (dma_map_sg+0x3c/0x114) [ 98.947169] [] (dma_map_sg+0x3c/0x114) from [] (msmsdcc_prep_xfer+0x50/0x10c) [ 98.956020] [] (msmsdcc_prep_xfer+0x50/0x10c) from [] (msmsdcc_pre_req+0x78/0x98) [ 98.965237] [] (msmsdcc_pre_req+0x78/0x98) from [] (mmc_start_req+0x4c/0x1c4) [ 98.974088] [] (mmc_start_req+0x4c/0x1c4) from [] (mmc_blk_issue_rw_rq+0x3a0/0x84c) [ 98.983457] [] (mmc_blk_issue_rw_rq+0x3a0/0x84c) from [] (mmc_blk_issue_rq+0x568/0x5c4) [ 98.993193] [] (mmc_blk_issue_rq+0x568/0x5c4) from [] (mmc_queue_thread+0xb4/0x120) [ 99.002563] [] (mmc_queue_thread+0xb4/0x120) from [] (kthread+0x80/0x8c) [ 99.010987] [] (kthread+0x80/0x8c) from [] (kernel_thread_exit+0x0/0x8) dma_cache_maint_page() function iterates through each page in single sg node, maps it to virtual space and then call the cache maintainance operation on that page. With above scenario, first page descriptor would be 0xc1e43fdc, which would be mapped virtual address by either kmap() (if it's higmem page) or by page_address() (if it's low mem page). Now as the size of the sg node is 8192 bytes, dma_cache_maint_page() function increments the page pointer (pointed by page_link of sg node) to get to the next descriptor. page++ would yield page descriptor address = 0xc1e44000 (0xc1e43fdc + sizeof (struct page)). 0xc1e44000 is not pointing any real page descriptor so when calls page_address(0xc1e44000) to get virtual address of the page, it returns invalid virtual address. Now when we try to dereference that invalid virtual address in cache maintainance functions, it would result into "Unable to handle kernel paging request at virtual address " error and kernel crashes. Regards, Subhash James -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.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/
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
Hi, > > Then, I added the example code in the documentation using EADDRNOTAVAIL. > > Yes, I was brave with this one. Yet, EINVAL, EBUSY, ENOENT, did not > > really cut it and are so heavily used in drivers that they turned into a > > generic "something is wrong" error. I tried here to use a not overloaded > > error code in order to be specific again. Since the patches were > > accepted, I assumed it wasn't seen as a namespace violation. (Then > > again, it probably would have been if that error code would go out to > > userspace) Naturally, I didn't have the resources to check all patches > > for a consistent error code. > > The problem with the current approach is that people (me included) keep > telling people to use this or that error code in an attempt to achieve > some kind of consistency. Also using an error message to distinguish > between reasons for failure makes it impossible to handle the error > other than by visual inspection. Granted, there are currently no code > paths that require this. Yes, so currently, this is rather a cosmetic change. And for that, it is quite intrusive. I think something like this is needed somewhen as part of a bigger overhaul. That's what I called "master plan" last time. That could be that resource handling gets aligned in general, also taking e.g. interrupt resources into account. But only changing error code handling for this function, doesn't seem too useful to me and might even need another change later, then. > One problem with the original patch was also that it didn't actually > convert any existing uses, so there was little chance of anyone noticing Like with the error codes now, there are so many different ways of handling resources that I did not want to mass convert all the drivers without being able to test them. I was hoping for a migration over time with patches from people who really tested what they did. > potential problems. More than a year later this function is used by many > subsystems and a lot of drivers. It just so happened that I observed how > many people just didn't know what error codes to choose and often just > grabbing one randomly. Yes, and concerning resources this needs cleaning on a bigger scale IMO. > By adding devm_ioremap_resource() and having it return ERR_PTR()-encoded > error codes we get rid of all these problems and put the responsibility > for choosing the error code where, in my opinion, it belongs: the > failing function. For completeness, it leaves the problem that people might forget to use ERR_PTR (seen that often in the clk framework). And the change is huge while I can't see any real benefit right now. > > When working with this function, there was also the idea to abstract > > getting the resource away. Which then gave Sascha Hauer and me the > > question, if drivers really have to do this or if this couldn't be done > > by the kernel somehow, i.e. giving the drivers already the resources > > they need, completely prepared. > > I'm not sure I like that very much. That could possibly lead to a new > problem where drivers that need to do something special have to jump > through hoops to achieve something that may otherwise be simple. I assume that drivers are already doing something special :) So, that would turn up in the conversion process. I can't promise that it would really work, it would need some playing around. > Anyway, if people don't think this is a sensible conversion I should > waste no more time on it. On the other hand I have the patch series > ready so I might as well post it for broader review. Working on patches is hardly a waste. Even if not accepted, you gain understanding. Please put me on CC, if you post the patches. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [Linaro-mm-sig] [PATCH 5/7] seqno-fence: Hardware dma-buf implementation of fencing (v4)
2013/1/15 Maarten Lankhorst :
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
>
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
> not much was left of the file. Lots of documentation added.
> v3: Use fence_ops instead of custom callbacks. Moved to own file
> to avoid circular dependency between dma-buf.h and fence.h
> v4: Add spinlock pointer to seqno_fence_init
>
> Signed-off-by: Maarten Lankhorst
> ---
> Documentation/DocBook/device-drivers.tmpl | 1 +
> drivers/base/fence.c | 38 +++
> include/linux/seqno-fence.h | 105
> ++
> 3 files changed, 144 insertions(+)
> create mode 100644 include/linux/seqno-fence.h
>
> diff --git a/Documentation/DocBook/device-drivers.tmpl
> b/Documentation/DocBook/device-drivers.tmpl
> index 6f53fc0..ad14396 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
> !Edrivers/base/dma-buf.c
> !Edrivers/base/fence.c
> !Iinclude/linux/fence.h
> +!Iinclude/linux/seqno-fence.h
> !Edrivers/base/dma-coherent.c
> !Edrivers/base/dma-mapping.c
>
> diff --git a/drivers/base/fence.c b/drivers/base/fence.c
> index 28e5ffd..1d3f29c 100644
> --- a/drivers/base/fence.c
> +++ b/drivers/base/fence.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> atomic_t fence_context_counter = ATOMIC_INIT(0);
> EXPORT_SYMBOL(fence_context_counter);
> @@ -284,3 +285,40 @@ out:
> return ret;
> }
> EXPORT_SYMBOL(fence_default_wait);
> +
> +static bool seqno_enable_signaling(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->enable_signaling(fence);
> +}
> +
> +static bool seqno_signaled(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->signaled &&
> seqno_fence->ops->signaled(fence);
> +}
> +
> +static void seqno_release(struct fence *fence)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> +
> + dma_buf_put(f->sync_buf);
> + if (f->ops->release)
> + f->ops->release(fence);
> + else
> + kfree(f);
> +}
> +
> +static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> + return f->ops->wait(fence, intr, timeout);
> +}
> +
> +const struct fence_ops seqno_fence_ops = {
> + .enable_signaling = seqno_enable_signaling,
> + .signaled = seqno_signaled,
> + .wait = seqno_wait,
> + .release = seqno_release
> +};
> +EXPORT_SYMBOL_GPL(seqno_fence_ops);
> diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
> new file mode 100644
> index 000..603adc0
> --- /dev/null
> +++ b/include/linux/seqno-fence.h
> @@ -0,0 +1,105 @@
> +/*
> + * seqno-fence, using a dma-buf to synchronize fencing
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Copyright (C) 2012 Canonical Ltd
> + * Authors:
> + * Rob Clark
> + * Maarten Lankhorst
> + *
> + * 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. 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, see
Re: [PATCH v5 0/5] Add movablecore_map boot option
2013/01/15 7:46, Andrew Morton wrote: On Mon, 14 Jan 2013 22:41:03 + "Luck, Tony" wrote: hm, why. Obviously SRAT support will improve things, but is it actually unusable/unuseful with the command line configuration? Users will want to set these moveable zones along node boundaries (the whole purpose is to be able to remove a node by making sure the kernel won't allocate anything tricky in it, right?) So raw addresses are usable ... but to get them right the user will have to go parse the SRAT table manually to come up with the addresses. Any time you make the user go off and do some tedious calculation that the computer should have done for them is user-abuse. Sure. But SRAT configuration is in progress and the boot option is better than nothing? Yes. I think boot option which specifies memory range is necessary. Things I'm wondering: - is there *really* a case for retaining the boot option if/when SRAT support is available? Yes. If SRAT support is available, all memory which enabled hotpluggable bit are managed by ZONEMOVABLE. But performance degradation may occur by NUMA because we can only allocate anonymous page and page-cache from these memory. In this case, if user cannot change SRAT information, user needs a way to select/set removable memory manually. Thanks, Yasuaki Ishimatsu - will the boot option be needed for other archictectures, presumably because they don't provide sufficient layout information to the kernel? -- 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: [RFC][PATCH v7 1/2] trace,x86: add x86 irq vector tracepoints
Steven,
Thank you for reviewing my patchset.
I will update both patch 1/2 and 2/2 in accordance with your comment.
Seiji
> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Tuesday, January 15, 2013 8:25 PM
> To: Seiji Aguchi
> Cc: x...@kernel.org; linux-kernel@vger.kernel.org; H. Peter Anvin
> (h...@zytor.com); Thomas Gleixner (t...@linutronix.de);
> 'mi...@elte.hu' (mi...@elte.hu); Borislav Petkov (b...@alien8.de); Satoru
> Moriya; dle-deve...@lists.sourceforge.net; linux-
> e...@vger.kernel.org; Luck, Tony (tony.l...@intel.com)
> Subject: Re: [RFC][PATCH v7 1/2] trace,x86: add x86 irq vector tracepoints
>
> On Thu, 2013-01-10 at 17:33 +, Seiji Aguchi wrote:
>
> > diff --git a/arch/x86/include/asm/trace/irq_vectors.h
> > b/arch/x86/include/asm/trace/irq_vectors.h
> > new file mode 100644
> > index 000..9bcb27b
> > --- /dev/null
> > +++ b/arch/x86/include/asm/trace/irq_vectors.h
> > @@ -0,0 +1,154 @@
> > +#undef TRACE_SYSTEM
> > +#define TRACE_SYSTEM irq_vectors
> > +
> > +#if !defined(_TRACE_IRQ_VECTORS_H) ||
> > +defined(TRACE_HEADER_MULTI_READ) #define _TRACE_IRQ_VECTORS_H
> > +
> > +#include
> > +
> > +extern void trace_irq_vector_regfunc(void); extern void
> > +trace_irq_vector_unregfunc(void);
> > +
> > +#define DECLARE_IRQ_VECTOR_EVENT(name) \
> > +TRACE_EVENT_FN(name, \
> > + TP_PROTO(int vector), \
> > + \
> > + TP_ARGS(vector),\
> > + \
> > + TP_STRUCT__entry( \
> > + __field(int,vector ) \
> > + ), \
> > + \
> > + TP_fast_assign( \
> > + __entry->vector = vector; \
> > + ), \
> > + \
> > + TP_printk("vector=%d", __entry->vector),\
> > + trace_irq_vector_regfunc, trace_irq_vector_unregfunc\
> > +);
> > +
> > +/*
> > + * local_timer_entry - called before entering a local timer interrupt
> > + * vector handler
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(local_timer_entry)
>
> This is a great big waste of space. Add the below patch to your series and
> then just do:
>
> DECLARE_EVENT_CLASS(x86_irq_vector,
>
> TP_PROTO(int vector),
>
> TP_ARGS(vector),
>
> TP_STRUCT__entry(
> __field(int,vector )
> ),
>
> TP_fast_assign(
> __entry->vector = vector;
> ),
>
> TP_printk("vector=%d", __entry->vector) );
>
> #define DEFINE_IRQ_VECTOR_EVENT(name) \
> DEFINE_EVENT_FN(name, \
> TP_PROTO(int vector), \
> TP_ARGS(vector), \
> trace_irq_vector_regfunc, \
> trace_irq_vector_unregfunc);
>
> And keep the rest the same.
>
> > +
> > +/*
> > + * local_timer_exit - called immediately after the interrupt vector
> > + * handler returns
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(local_timer_exit)
> > +
> > +/*
> > + * reschedule_entry - called before entering a reschedule vector
> > +handler */
> > +DECLARE_IRQ_VECTOR_EVENT(reschedule_entry)
> > +
> > +/*
> > + * reschedule_exit - called immediately after the interrupt vector
> > + * handler returns
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(reschedule_exit)
> > +
> > +/*
> > + * spurious_apic_entry - called before entering a spurious apic
> > +vector handler */
> > +DECLARE_IRQ_VECTOR_EVENT(spurious_apic_entry)
> > +
> > +/*
> > + * spurious_apic_exit - called immediately after the interrupt vector
> > + * handler returns
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(spurious_apic_exit)
> > +
> > +/*
> > + * error_apic_entry - called before entering an error apic vector
> > +handler */
> > +DECLARE_IRQ_VECTOR_EVENT(error_apic_entry)
> > +
> > +/*
> > + * error_apic_exit - called immediately after the interrupt vector
> > + * handler returns
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(error_apic_exit)
> > +
> > +/*
> > + * x86_platform_ipi_entry - called before entering a x86 platform ipi
> > +interrupt
> > + * vector handler
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(x86_platform_ipi_entry)
> > +
> > +/*
> > + * x86_platform_ipi_exit - called immediately after the interrupt
> > +vector
> > + * handler returns
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(x86_platform_ipi_exit)
> > +
> > +/*
> > + * irq_work_entry - called before entering a irq work interrupt
> > + * vector handler
> > + */
> > +DECLARE_IRQ_VECTOR_EVENT(irq_work_entry)
> > +
> > +/*
> > + * irq_work_exit - called immediately after the interrupt vector
> > + * handler returns
> > + */
> >
Re: IPsec AH use of ahash
Please Cc net...@vger.kernel.org on all networking related topics. On Tue, Jan 15, 2013 at 11:51:48AM -0500, Tom St Denis wrote: > Hi all, > > The AH4/6 code uses ahash to perform the MAC calculation but this precludes > the availability of GMAC to the user. Are there any plans to port the AH > code over to the aead API so that it can use potentially any algo available > to the user? > There was no need for this by now, but you are welcome to send patches. -- 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 V4 3/3] tuntap: allow polling/writing/reading when detached
On Tuesday, January 15, 2013 06:48:08 PM Michael S. Tsirkin wrote:
> On Tue, Jan 15, 2013 at 06:28:46PM +0800, Jason Wang wrote:
> > We forbid polling, writing and reading when the file were detached, this
> > may complex the user in several cases:
> >
> > - when guest pass some buffers to vhost/qemu and then disable some queues,
> >
> > vhost/qemu needs to to its own cleanup which is complex. We can do this
> > simply by allowing a user can still write to an disabled queue to
> > handle this. And user can still do read but just nothing returned.
> >
> > - align the polling behavior with macvtap which never fails when the queue
> > is>
> > created. this can simplify the polling errors handling of its user (e.g
> > vhost)>
> > Signed-off-by: Jason Wang
> > ---
> >
> > drivers/net/tun.c | 18 +++---
> > 1 files changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index af372d0..eb68937 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -307,7 +307,7 @@ static void tun_flow_update(struct tun_struct *tun,
> > u32 rxhash,>
> > rcu_read_lock();
> >
> > - if (tun->numqueues == 1)
> > + if (tun->numqueues == 1 || queue_index >= tun->numqueues)
> >
> > goto unlock;
> >
> > e = tun_flow_find(head, rxhash);
>
> Hmm I don't understand - does something ensure that queue_index is >
> numqueues if the queue is disabled?
I miss this, something is needed.
> Can we check tun->disabled and skip tun_flow_update completely?
> We might need to switch to rcu_assign for tun->disabled for this
> but otherwise it looks easy.
Correct, will post another version, thanks.
>
> > @@ -406,21 +406,21 @@ static void __tun_detach(struct tun_file *tfile,
> > bool clean)>
> > tun = rtnl_dereference(tfile->tun);
> >
> > - if (tun) {
> > + if (tun && !tfile->detached) {
> >
> > u16 index = tfile->queue_index;
> > BUG_ON(index >= tun->numqueues);
> > dev = tun->dev;
> >
> > rcu_assign_pointer(tun->tfiles[index],
> >
> >tun->tfiles[tun->numqueues - 1]);
> >
> > - rcu_assign_pointer(tfile->tun, NULL);
> >
> > ntfile = rtnl_dereference(tun->tfiles[index]);
> > ntfile->queue_index = index;
> >
> > --tun->numqueues;
> >
> > - if (clean)
> > + if (clean) {
> > + rcu_assign_pointer(tfile->tun, NULL);
> >
> > sock_put(>sk);
> >
> > - else
> > + } else
> >
> > tun_disable_queue(tun, tfile);
> >
> > synchronize_net();
> >
> > @@ -465,6 +465,10 @@ static void tun_detach_all(struct net_device *dev)
> >
> > rcu_assign_pointer(tfile->tun, NULL);
> > --tun->numqueues;
> >
> > }
> >
> > + list_for_each_entry(tfile, >disabled, next) {
> > + wake_up_all(>wq.wait);
> > + rcu_assign_pointer(tfile->tun, NULL);
> > + }
> >
> > BUG_ON(tun->numqueues != 0);
> >
> > synchronize_net();
> >
> > @@ -491,7 +495,7 @@ static int tun_attach(struct tun_struct *tun, struct
> > file *file)>
> > int err;
> >
> > err = -EINVAL;
> >
> > - if (rtnl_dereference(tfile->tun))
> > + if (rtnl_dereference(tfile->tun) && !tfile->detached)
> >
> > goto out;
> >
> > err = -EBUSY;
> >
> > @@ -1795,7 +1799,7 @@ static int tun_set_queue(struct file *file, struct
> > ifreq *ifr)>
> > ret = tun_attach(tun, file);
> >
> > } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> >
> > tun = rtnl_dereference(tfile->tun);
> >
> > - if (!tun || !(tun->flags & TUN_TAP_MQ))
> > + if (!tun || !(tun->flags & TUN_TAP_MQ) || tfile->detached)
> >
> > ret = -EINVAL;
> >
> > else
> >
> > __tun_detach(tfile, false);
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.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/
Re: [PATCH 0/4] switch arc-uart to devicetree based probing
On Wednesday 16 January 2013 11:46 AM, Greg KH wrote: > On Fri, Jan 11, 2013 at 11:50:19AM +0530, Vineet Gupta wrote: >> Hi, >> >> As part of converting ARC Port to devicetree infrastructure, the following >> series converts the arc-uart driver to DT. >> >> * The first patch is a bug-fix which showed up in the process as DT based >> platform devices by default have -ve id >> * Next two prepare the driver for forthcoming DT changes. >> * Last one contains the DT bindings and driver using those. >> >> Couple of points worth mentioning: >> * The earlyprintk portion of driver still relies on static platform data >> we would need some earlyprintk handling in of_fdt_* to clean it up properly >> * Two of the three platform data instances are now retrieved from DT. >> However one still needs to be dynamically passed by platform (using >> of_dev_auxdata) as we want to run same image in simulator and hardware >> >> Tested on in-works ARC 3.8 port. >> >> P.S. Greg, can this be treated as a bug-fix for 3.8 > No, because it is not a bugfix, but a new feature, sorry. > > greg k-h NP. Thx a bunch for merging these. -Vineet -- 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/4] switch arc-uart to devicetree based probing
On Fri, Jan 11, 2013 at 11:50:19AM +0530, Vineet Gupta wrote: > Hi, > > As part of converting ARC Port to devicetree infrastructure, the following > series converts the arc-uart driver to DT. > > * The first patch is a bug-fix which showed up in the process as DT based > platform devices by default have -ve id > * Next two prepare the driver for forthcoming DT changes. > * Last one contains the DT bindings and driver using those. > > Couple of points worth mentioning: > * The earlyprintk portion of driver still relies on static platform data > we would need some earlyprintk handling in of_fdt_* to clean it up properly > * Two of the three platform data instances are now retrieved from DT. > However one still needs to be dynamically passed by platform (using > of_dev_auxdata) as we want to run same image in simulator and hardware > > Tested on in-works ARC 3.8 port. > > P.S. Greg, can this be treated as a bug-fix for 3.8 No, because it is not a bugfix, but a new feature, sorry. 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 v3 17/22] sched: packing small tasks in wake/exec balancing
On 01/14/2013 03:13 PM, Namhyung Kim wrote:
> On Fri, 11 Jan 2013 11:47:03 +0800, Alex Shi wrote:
>> On 01/11/2013 01:17 AM, Morten Rasmussen wrote:
>>> On Sat, Jan 05, 2013 at 08:37:46AM +, Alex Shi wrote:
If the wake/exec task is small enough, utils < 12.5%, it will
has the chance to be packed into a cpu which is busy but still has space to
handle it.
Signed-off-by: Alex Shi
---
> [snip]
>>> I may be missing something, but could the expression be something like
>>> the below instead?
>>>
>>> Create a putil < 12.5% check before the loop. There is no reason to
>>> recheck it every iteration. Then:
>
> Agreed. Also suggest that the checking local cpu can also be moved
> before the loop so that it can be used without going through the loop if
> it's vacant enough.
Yes, thanks for suggestion!
>
>>>
>>> vacancy = FULL_UTIL - (rq->util + putil)
>>>
>>> should be enough?
>>>
+
+ /* bias toward local cpu */
+ if (vacancy > 0 && (i == this_cpu))
+ return i;
+
+ if (vacancy > 0 && vacancy < min_vacancy) {
+ min_vacancy = vacancy;
+ idlest = i;
>>>
>>> "idlest" may be a bit misleading here as you actually select busiest cpu
>>> that have enough spare capacity to take the task.
>>
>> Um, change to leader_cpu?
>
> vacantest? ;-)
hard to the ward in google. are you sure it is better than leader_cpu? :)
>
> Thanks,
> Namhyung
>
--
Thanks Alex
--
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/
Redefinition of struct in6_addr in and
(Cc'ing some glibc developers...) Hello, In glibc source file inet/netinet/in.h and kernel source file include/uapi/linux/in6.h, both define struct in6_addr, and both are visible to user applications. Thomas reported a conflict below. So, how can we handle this? /me is wondering why we didn't see this before. Thanks. On Tue, 2013-01-15 at 12:55 +0200, Thomas Backlund wrote: > Cong Wang skrev 15.1.2013 12:11: > > > > Does the following patch help? > > > > $ git diff include/uapi/linux/if_bridge.h > > diff --git a/include/uapi/linux/if_bridge.h > > b/include/uapi/linux/if_bridge.h > > index 5db2975..653db23 100644 > > --- a/include/uapi/linux/if_bridge.h > > +++ b/include/uapi/linux/if_bridge.h > > @@ -14,6 +14,7 @@ > > #define _UAPI_LINUX_IF_BRIDGE_H > > > > #include > > +#include > > > > #define SYSFS_BRIDGE_ATTR "bridge" > > #define SYSFS_BRIDGE_FDB "brforward" > > > > Well, I suggested the same fix in the beginning of the thread > on netdev and lkml: "if_bridge.h: include in6.h for struct in6_addr use" > > as it seemed to fix the libvirt case > > but then asked it to be ignored after I tried to build connman, > and hit this conflict with glibc-2.17: > > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:35:5: error: expected identifier before > numeric constant > /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:30:8: note: originally defined here > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:238:8: error: redefinition of 'struct > sockaddr_in6' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:46:8: note: originally defined here > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:54:8: note: originally defined here > make[1]: *** [src/src_connmand-tethering.o] Error 1 > > > So I'm not sure it's the right one... > -- 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] extcon for v3.9
Hi Greg, This is the extcon pull request for v3.9. I don't send separate pull request of extcon about bugfixes patch. I'd like to apply this patch-set to your next branch for v3.9. Please pull extcon with following updates. Update to max77693/max8997 extcon driver: - Using MHL_TA cable for charging. - Support JIG cable. - Support Dock-Audio device for playing music and button of device. - Support Dock-Smart device for desktop mode with mouse/keyboard. - Set default UART/USB path on probe(). - Check the state/type of cable after completing initialization. - Code clean to remove duplicate code and bug fix related to sequence of interrupt. - Fix irq_flag of max8997/max77693 driver. Update to arizona extcon driver: - Headphone measurements. - Alternative detection mechanism for non-default system designs. - Microphone clamp integration. - Support for additional detection pin. - MICBIAS rise time configuration. Best regards, Chanwoo Choi The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-for-3.9 for you to fetch changes up to 689557d3c7045320958d5bc4141088f7b4dff7ba: mfd: wm5102: Add microphone clamp control registers (2013-01-15 15:42:18 +0900) Chanwoo Choi (9): extcon: max77693: Remove duplicate code by making function extcon: max77693: Add support MHL_TA cable for charging battery extcon: max77693: Add support jig cable extcon: max77693: Add support dock device and buttons extcon: max77693: Check the state/type of cable after boot completed extcon: max8997/max77693: Support IRQF_NO_SUSPEND flag for interrupt extcon: max77693: Set default uart/usb path by using platform data extcon: max77693: Fix bug when detecting MHL/Dock-Audio with USB/TA cable extcon: max77693: Add support Dock-Smart device for desktop mode Mark Brown (11): extcon: arizona: Convert to devm_input_allocate_device() extcon: arizona: Remove duplicate mic ramp configuration extcon: arizona: Only set GPIO if it has been requested extcon: arizona: Allow configuration of MICBIAS rise time extcon: arizona: Use microphone clamp function if available extcon: arizona: Support use of GPIO5 as an input to jack detection extcon: arizona: Enable basic headphone identification extcon: Simple code motion supporting future work. extcon: arizona: Support HPDET based accessory identification extcon: arizona: Support direct microphone measurement via HPDET mfd: wm5102: Add microphone clamp control registers drivers/extcon/extcon-arizona.c | 634 +-- drivers/extcon/extcon-max77693.c | 920 +- drivers/extcon/extcon-max8997.c | 6 +- drivers/mfd/wm5102-tables.c | 10 + include/linux/mfd/arizona/core.h | 4 +- include/linux/mfd/arizona/pdata.h | 12 + include/linux/mfd/arizona/registers.h | 48 ++ include/linux/mfd/max77693-private.h | 86 include/linux/mfd/max77693.h | 9 + 9 files changed, 1439 insertions(+), 290 deletions(-) -- 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: [PATCHv5 7/8] ARM: tegra: Add board data and 2D clocks
On 15.01.2013 20:44, Stephen Warren wrote:
>> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
>> b/arch/arm/mach-tegra/board-dt-tegra20.c
>
>> +OF_DEV_AUXDATA("nvidia,tegra20-gr2d", 0x5414, "gr2d", NULL),
>
> I assume the only reason to add AUXDATA is to give the device a specific
> name, which will then match the driver name in the clock driver:
>
>> -CLK_DUPLICATE("2d", "tegra_grhost", "gr2d"),
>> +CLK_DUPLICATE("2d", "gr2d", "gr2d"),
>
> If so, this shouldn't be needed once the common clock framework patches
> are applied, since all device clocks will be retrieved from device tree,
> and hence the device name will be irrelevant; the phandle in device tree
> is all that will matter.
Yes, clock binding is the only reason for the OF_DEV_AUXDATA line. I'll
need to look into Prashant's clock changes, but I assume it's going to
be a trivial change to host1x patches.
Thanks for the heads-up.
Terje
--
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: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi Ravi, On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe? If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs. What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed. Well in that case, we can write to the registers based on the IP revision check (I think thats the common practice to do). In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Of course. I don't see why we can't have the same driver to handle different versions of the same IP. The only reason where we might need multiple instance is if the SoC have multiple control module which Arnd already pointed out. Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver? Not needed at all IMHO. We can use revision register to differentiate. Btw I think Felipe looped you for a different reason ;-) 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 v3 16/22] sched: add power aware scheduling in fork/exec/wake
On 01/15/2013 12:09 AM, Morten Rasmussen wrote: > On Fri, Jan 11, 2013 at 07:08:45AM +, Alex Shi wrote: >> On 01/10/2013 11:01 PM, Morten Rasmussen wrote: >>> On Sat, Jan 05, 2013 at 08:37:45AM +, Alex Shi wrote: This patch add power aware scheduling in fork/exec/wake. It try to select cpu from the busiest while still has utilization group. That's will save power for other groups. The trade off is adding a power aware statistics collection in group seeking. But since the collection just happened in power scheduling eligible condition, the worst case of hackbench testing just drops about 2% with powersaving/balance policy. No clear change for performance policy. I had tried to use rq load avg utilisation in this balancing, but since the utilisation need much time to accumulate itself. It's unfit for any burst balancing. So I use nr_running as instant rq utilisation. >>> >>> So you effective use a mix of nr_running (counting tasks) and PJT's >>> tracked load for balancing? >> >> no, just task number here. >>> >>> The problem of slow reaction time of the tracked load a cpu/rq is an >>> interesting one. Would it be possible to use it if you maintained a >>> sched group runnable_load_avg similar to cfs_rq->runnable_load_avg where >>> load contribution of a tasks is added when a task is enqueued and >>> removed again if it migrates to another cpu? >>> This way you would know the new load of the sched group/domain instantly >>> when you migrate a task there. It might not be precise as the load >>> contribution of the task to some extend depends on the load of the cpu >>> where it is running. But it would probably be a fair estimate, which is >>> quite likely to be better than just counting tasks (nr_running). >> >> For power consideration scenario, it ask task number less than Lcpu >> number, don't care the load weight, since whatever the load weight, the >> task only can burn one LCPU. >> > > True, but you miss the opportunities for power saving when you have many > light tasks (> LCPU). Currently, the sd_utils < threshold check will go > for SCHED_POLICY_PERFORMANCE if the number tasks (sd_utils) is greater > than the domain weight/capacity irrespective of the actual load caused > by those tasks. > > If you used tracked task load weight for sd_utils instead you would be > able to go for power saving in scenarios with many light tasks as well. yes, that's right on power consideration. but for performance consider, it's better to spread tasks on different LCPU to save CS cost. And if the cpu usage is nearly full, we don't know if some tasks real want more cpu time. Even in the power sched policy, we still want to get better performance if it's possible. :) > + + if (sched_policy == SCHED_POLICY_POWERSAVING) + threshold = sgs.group_weight; + else + threshold = sgs.group_capacity; >>> >>> Is group_capacity larger or smaller than group_weight on your platform? >> >> Guess most of your confusing come from the capacity != weight here. >> >> In most of Intel CPU, a cpu core's power(with 2 HT) is usually 1178, it >> just bigger than a normal cpu power - 1024. but the capacity is still 1, >> while the group weight is 2. >> > > Thanks for clarifying. To the best of my knowledge there are no > guidelines for how to specify cpu power so it may be a bit dangerous to > assume that capacity < weight when capacity is based on cpu power. Sure. I also just got them from code. and don't know other arch how to different them. but currently, seems this cpu power concept works fine. > > You could have architectures where the cpu power of each LCPU (HT, core, > cpu, whatever LCPU is on the particular platform) is greater than 1024 > for most LCPUs. In that case, the capacity < weight assumption fails. > Also, on non-HT systems it is quite likely that you will have capacity = > weight. yes. > > Morten > >> -- >> 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/ >> > -- Thanks Alex -- 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 v3 15/22] sched: log the cpu utilization at rq
On 01/14/2013 09:59 PM, Morten Rasmussen wrote:
> On Fri, Jan 11, 2013 at 03:30:30AM +, Alex Shi wrote:
>> On 01/10/2013 07:40 PM, Morten Rasmussen wrote:
> #undef P64
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index ee015b8..7bfbd69 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1495,8 +1495,12 @@ static void update_cfs_rq_blocked_load(struct
> cfs_rq *cfs_rq, int force_update)
>
> static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
> {
> + u32 period;
> __update_entity_runnable_avg(rq->clock_task, >avg, runnable);
> __update_tg_runnable_avg(>avg, >cfs);
> +
> + period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
> + rq->util = rq->avg.runnable_avg_sum * 100 / period;
>>> The existing tg->runnable_avg and cfs_rq->tg_runnable_contrib variables
>>> both holds
>>> rq->avg.runnable_avg_sum / rq->avg.runnable_avg_period scaled by
>>> NICE_0_LOAD (1024). Why not use one of the existing variables instead of
>>> introducing a new one?
>>
>> we want to a rq variable that reflect the utilization of the cpu, not of
>> the tg
>
> It is the same thing for the root tg. You use exactly the same variables
> for calculating rq->util as is used to calculate both tg->runnable_avg and
> cfs_rq->tg_runnable_contrib in __update_tg_runnable_avg(). The only
> difference is that you scale by 100 while __update_tg_runnable_avg()
> scale by NICE_0_LOAD.
yes, the root tg->runnable_avg has same meaningful, but normal tg not,
and more important it is hidden by CONFIG_FAIR_GROUP_SCHED,
--
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: the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi
On Tue, 2013-01-15 at 12:55 +0200, Thomas Backlund wrote: > > as it seemed to fix the libvirt case > > but then asked it to be ignored after I tried to build connman, > and hit this conflict with glibc-2.17: > > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:35:5: error: expected identifier before > numeric constant > /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:30:8: note: originally defined here > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:238:8: error: redefinition of 'struct > sockaddr_in6' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:46:8: note: originally defined here > In file included from /usr/include/arpa/inet.h:22:0, > from ./include/connman/inet.h:25, > from src/connman.h:128, > from src/tethering.c:40: > /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq' > In file included from /usr/include/linux/if_bridge.h:17:0, > from src/tethering.c:38: > /usr/include/linux/in6.h:54:8: note: originally defined here > make[1]: *** [src/src_connmand-tethering.o] Error 1 > > > So I'm not sure it's the right one... % rpm -q --whatprovides /usr/include/netinet/in.h glibc-headers-2.14.90-24.fc16.9.x86_64 Seems we have conflicts with glibc headers... -- 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 1/2] 6lowpan: Refactor packet delivery into a function
Refactor the handing of the skb's to the individual lowpan devices into a
function.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f651da6..1714cfa 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -594,10 +594,32 @@ static int lowpan_header_create(struct sk_buff *skb,
}
}
+static int lowpan_give_skb_to_devices(struct sk_buff *skb)
+{
+ struct lowpan_dev_record *entry;
+ struct sk_buff *skb_cp;
+ int stat = NET_RX_SUCCESS;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(entry, _devices, list)
+ if (lowpan_dev_info(entry->ldev)->real_dev == skb->dev) {
+ skb_cp = skb_copy(skb, GFP_ATOMIC);
+ if (!skb_cp) {
+ stat = -ENOMEM;
+ break;
+ }
+
+ skb_cp->dev = entry->ldev;
+ stat = netif_rx(skb_cp);
+ }
+ rcu_read_unlock();
+
+ return stat;
+}
+
static int lowpan_skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr)
{
struct sk_buff *new;
- struct lowpan_dev_record *entry;
int stat = NET_RX_SUCCESS;
new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
@@ -614,19 +636,7 @@ static int lowpan_skb_deliver(struct sk_buff *skb, struct
ipv6hdr *hdr)
new->protocol = htons(ETH_P_IPV6);
new->pkt_type = PACKET_HOST;
- rcu_read_lock();
- list_for_each_entry_rcu(entry, _devices, list)
- if (lowpan_dev_info(entry->ldev)->real_dev == new->dev) {
- skb = skb_copy(new, GFP_ATOMIC);
- if (!skb) {
- stat = -ENOMEM;
- break;
- }
-
- skb->dev = entry->ldev;
- stat = netif_rx(skb);
- }
- rcu_read_unlock();
+ stat = lowpan_give_skb_to_devices(new);
kfree_skb(new);
--
1.7.11.2
--
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 0/2] Handle Uncompressed IPv6 on 6LoWPAN
This has been tested by exchanging data with with the Contiki operating system using a Redwire Econotag. Contiki had to be set to send uncompressed data, and had to have a #define modified to enable reception and processing of header-compressed packets when not set to send compressed data. Alan Ott (2): 6lowpan: Refactor packet delivery into a function 6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN net/ieee802154/6lowpan.c | 79 ++-- 1 file changed, 56 insertions(+), 23 deletions(-) -- 1.7.11.2 -- 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] 6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN
Handle the reception of uncompressed packets (dispatch type = IPv6).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 1714cfa..43bd1c0 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1147,19 +1147,42 @@ static int lowpan_rcv(struct sk_buff *skb, struct
net_device *dev,
goto drop;
/* check that it's our buffer */
- switch (skb->data[0] & 0xe0) {
- case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
- case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
- case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
- local_skb = skb_clone(skb, GFP_ATOMIC);
+ if (skb->data[0] == LOWPAN_DISPATCH_IPV6) {
+ /* Copy the packet so that the IPv6 header is
+* properly aligned.
+*/
+ local_skb = skb_copy_expand(skb, NET_SKB_PAD - 1,
+ skb_tailroom(skb), GFP_ATOMIC);
if (!local_skb)
goto drop;
- lowpan_process_data(local_skb);
+ local_skb->protocol = htons(ETH_P_IPV6);
+ local_skb->pkt_type = PACKET_HOST;
+
+ /* Pull off the 1-byte of 6lowpan header. */
+ skb_pull(local_skb, 1);
+ skb_reset_network_header(local_skb);
+ skb_set_transport_header(local_skb, sizeof(struct ipv6hdr));
+
+ lowpan_give_skb_to_devices(local_skb);
+
+ kfree_skb(local_skb);
kfree_skb(skb);
- break;
- default:
- break;
+ } else {
+ switch (skb->data[0] & 0xe0) {
+ case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
+ case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
+ case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
+ local_skb = skb_clone(skb, GFP_ATOMIC);
+ if (!local_skb)
+ goto drop;
+ lowpan_process_data(local_skb);
+
+ kfree_skb(skb);
+ break;
+ default:
+ break;
+ }
}
return NET_RX_SUCCESS;
--
1.7.11.2
--
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 v3 05/22] sched: remove domain iterations in fork/exec/wake
- /* while loop will break here if sd == NULL */ >> >> I agree that this should be a major optimization. I just can't figure >> out why the existing recursive search for an idle cpu switches to the >> new cpu near the end and then starts a search for an idle cpu in the new >> cpu's domain. Is this to handle some exotic sched domain configurations? >> If so, they probably wouldn't work with your optimizations. > > Let me explain my understanding of why the recursive search is the way > it is. > > _ sd0 > | | > | ___sd1__ ___sd2__| > | || || | > | | sgx| | sga | | > | | sgy| | sgb | | > | || || | > |_| > > What the current recursive search is doing is (assuming we start with > sd0-the top level sched domain whose flags are rightly set). we find > that sd1 is the idlest group,and a cpux1 in sgx is the idlest cpu. > > We could have ideally stopped the search here.But the problem with this > is that there is a possibility that sgx is more loaded than sgy; meaning > the cpus in sgx are heavily imbalanced;say there are two cpus cpux1 and > cpux2 in sgx,where cpux2 is heavily loaded and cpux1 has recently gotten > idle and load balancing has not come to its rescue yet.According to the > search above, cpux1 is idle,but is *not the right candidate for > scheduling forked task,it is the right candidate for relieving the load > from cpux2* due to cache locality etc. The problem still exists on the current code. It still goes to cpux1. and then goes up to sgx to seek idlest group ... idlest cpu, and back to cpux1 again. nothing help. -- 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 v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Grant Likely
---
Changes from v4:
- Added gpio line for VBUS of USB2.0 on snow board.
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250-snow.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6
4 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@1211 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x1211 0x100>;
+ interrupts = <0 71 0>;
+ samsung,vbus-gpio = < 6 1 3 3>;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..7363e14 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -204,4 +204,8 @@
samsung,mfc-r = <0x4300 0x80>;
samsung,mfc-l = <0x5100 0x80>;
};
+
+ usb@1211 {
+ samsung,vbus-gpio = < 6 1 3 3>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..47b6b84 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -40,4 +40,8 @@
< 5 2 3 0>, < 6 2 3 0>;
};
};
+
+ usb@1211 {
+ samsung,vbus-gpio = < 1 1 3 3>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..2cbe53e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,12 @@
#size-cells = <0>;
};
+ usb@1211 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x1211 0x100>;
+ interrupts = <0 71 0>;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
--
1.7.6.5
--
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] regulator: maintainers: update email address
On Tue, Jan 15, 2013 at 03:13:27PM +, Liam Girdwood wrote: > From: Liam Girdwood > > I no longer work at TI. Applied, thanks. -- 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] mm/slab: add a leak decoder callback
On wed, 16 Jan 2013 11:03:13 +0800, Liu Bo wrote:
> This adds a leak decoder callback so that slab destruction
> can use to generate debugging output for the allocated objects.
>
> Callers like btrfs are using their own leak tracking which will
> manage allocated objects in a list(or something else), this does
> indeed the same thing as what slab does. So adding a callback
> for leak tracking can avoid this as well as runtime overhead.
If the slab is merged with the other one, this patch can work well?
Thanks
Miao
> (The idea is from Zach Brown .)
>
> Signed-off-by: Liu Bo
> ---
> v2: add a wrapper API for slab destruction to make decoder only
> work in particular path.
>
> fs/btrfs/extent_io.c | 26 --
> fs/btrfs/extent_map.c| 13 -
> include/linux/slab.h |2 ++
> include/linux/slab_def.h |1 +
> include/linux/slub_def.h |1 +
> mm/slab_common.c | 17 -
> mm/slub.c|2 ++
> 7 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index bcc8dff..355c7fc 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -63,6 +63,26 @@ tree_fs_info(struct extent_io_tree *tree)
> return btrfs_sb(tree->mapping->host->i_sb);
> }
>
> +static void extent_state_leak_decoder(void *object)
> +{
> + struct extent_state *state = object;
> +
> + printk(KERN_ERR "btrfs state leak: start %llu end %llu "
> +"state %lu in tree %p refs %d\n",
> +(unsigned long long)state->start,
> +(unsigned long long)state->end,
> +state->state, state->tree, atomic_read(>refs));
> +}
> +
> +static void extent_buffer_leak_decoder(void *object)
> +{
> + struct extent_buffer *eb = object;
> +
> + printk(KERN_ERR "btrfs buffer leak start %llu len %lu "
> +"refs %d\n", (unsigned long long)eb->start,
> +eb->len, atomic_read(>refs));
> +}
> +
> int __init extent_io_init(void)
> {
> extent_state_cache = kmem_cache_create("btrfs_extent_state",
> @@ -115,9 +135,11 @@ void extent_io_exit(void)
>*/
> rcu_barrier();
> if (extent_state_cache)
> - kmem_cache_destroy(extent_state_cache);
> + kmem_cache_destroy_decoder(extent_state_cache,
> +extent_state_leak_decoder);
> if (extent_buffer_cache)
> - kmem_cache_destroy(extent_buffer_cache);
> + kmem_cache_destroy_decoder(extent_buffer_cache,
> +extent_buffer_leak_decoder);
> }
>
> void extent_io_tree_init(struct extent_io_tree *tree,
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index f359e4c..bccba3d 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -16,6 +16,16 @@ static LIST_HEAD(emaps);
> static DEFINE_SPINLOCK(map_leak_lock);
> #endif
>
> +static void extent_map_leak_decoder(void *object)
> +{
> + struct extent_map *em = object;
> +
> + printk(KERN_ERR "btrfs ext map leak: start %llu len %llu block %llu "
> +"flags %lu refs %d in tree %d compress %d\n",
> +em->start, em->len, em->block_start, em->flags,
> +atomic_read(>refs), em->in_tree, (int)em->compress_type);
> +}
> +
> int __init extent_map_init(void)
> {
> extent_map_cache = kmem_cache_create("btrfs_extent_map",
> @@ -39,7 +49,8 @@ void extent_map_exit(void)
> }
>
> if (extent_map_cache)
> - kmem_cache_destroy(extent_map_cache);
> + kmem_cache_destroy_decoder(extent_map_cache,
> +extent_map_leak_decoder);
> }
>
> /**
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 5d168d7..5c6a8d8 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -114,6 +114,7 @@ struct kmem_cache {
> const char *name; /* Slab name for sysfs */
> int refcount; /* Use counter */
> void (*ctor)(void *); /* Called on object slot creation */
> + void (*decoder)(void *);/* Called on object slot leak detection */
> struct list_head list; /* List of all slab caches on the system */
> };
> #endif
> @@ -132,6 +133,7 @@ struct kmem_cache *
> kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t,
> unsigned long, void (*)(void *), struct kmem_cache *);
> void kmem_cache_destroy(struct kmem_cache *);
> +void kmem_cache_destroy_decoder(struct kmem_cache *, void (*)(void *));
> int kmem_cache_shrink(struct kmem_cache *);
> void kmem_cache_free(struct kmem_cache *, void *);
>
> diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> index 8bb6e0e..7ca8309 100644
> --- a/include/linux/slab_def.h
> +++ b/include/linux/slab_def.h
> @@ -48,6 +48,7 @@ struct kmem_cache {
>
> /* constructor func */
> void (*ctor)(void *obj);
> +
Re: [PATCH v3 11/22] sched: consider runnable load average in effective_load
On 01/14/2013 08:01 PM, Morten Rasmussen wrote:
static long effective_load(struct task_group *tg, int cpu, long wl, long
wg)
> >> {
> >> struct sched_entity *se = tg->se[cpu];
> >>
> >> if (!tg->parent)/* the trivial, non-cgroup case */
> >> - return wl;
> >> + return wl * tg->cfs_rq[cpu]->tg_runnable_contrib
> >> + >> NICE_0_SHIFT;
>>> > >
>>> > > Why do we need to scale the load of the task (wl) by runnable_contrib
>>> > > when the task is in the root task group? Wouldn't the load change still
>>> > > just be wl?
>>> > >
>> >
>> > Here, wl is the load weight, runnable_contrib engaged the runnable time.
> Yes, wl is the load weight of the task. But I don't understand why you
> multiply it with the tg_runnable_contrib of the group you want to insert
> it into. Since effective_load() is supposed to return the load change
> caused by adding the task to the cpu it would make more sense if you
> multiplied with the task runnable_avg_sum / runnable_avg_period of the
> task in question.
>
I was consider the task will follow the cpu's runnable time, like
throttle etc.
But may it is a bit early to consider this. use the task's runnable avg
seems better.
--
Thanks
Alex
--
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: [v3 PATCH 7/9] watchdog/at91sam9_wdt: Use module_platform_driver()
Hi Fabio Porcedda,
> -Original Message-
> From: Fabio Porcedda [mailto:fabio.porce...@gmail.com]
> Sent: 2013年1月8日 18:18
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; Ferre, Nicolas; Jean-Christophe
> PLAGNIOL-VILLARD; Lin, JM; Wim Van Sebroeck;
> linux-watch...@vger.kernel.org; linux-kernel@vger.kernel.org; Geert
> Uytterhoeven
> Subject: Re: [v3 PATCH 7/9] watchdog/at91sam9_wdt: Use
> module_platform_driver()
>
> On Sat, Jan 5, 2013 at 3:38 AM, Wenyou Yang
> wrote:
> > Using module_platform_driver() replaces module_init() and module_exit()
> > and makes the code simpler.
> >
> > Remove '__init' annotation from the function 'at91wdt_probe'
> > since the driver becomes hot-plug aware now.
> >
> > Signed-off-by: Wenyou Yang
> > Cc: w...@iguana.be
> > Cc: linux-watch...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > drivers/watchdog/at91sam9_wdt.c | 16 +++-
> > 1 file changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c
> b/drivers/watchdog/at91sam9_wdt.c
> > index 94be9d6..7c13dda 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -204,7 +204,7 @@ static struct watchdog_device at91wdt_wdd = {
> > .ops = _ops,
> > };
> >
> > -static int __init at91wdt_probe(struct platform_device *pdev)
> > +static int at91wdt_probe(struct platform_device *pdev)
> > {
> > struct at91wdt_drvdata *driver_data;
> > struct resource *r;
> > @@ -273,6 +273,7 @@ MODULE_DEVICE_TABLE(of, at91_wdt_dt_ids);
> > #endif
> >
> > static struct platform_driver at91wdt_driver = {
> > + .probe = at91wdt_probe,
> > .remove = __exit_p(at91wdt_remove),
> > .driver = {
> > .name = "at91_wdt",
> > @@ -281,18 +282,7 @@ static struct platform_driver at91wdt_driver = {
> > },
> > };
> >
> > -static int __init at91sam_wdt_init(void)
> > -{
> > - return platform_driver_probe(_driver, at91wdt_probe);
> > -}
> > -
> > -static void __exit at91sam_wdt_exit(void)
> > -{
> > - platform_driver_unregister(_driver);
> > -}
> > -
> > -module_init(at91sam_wdt_init);
> > -module_exit(at91sam_wdt_exit);
> > +module_platform_driver(at91wdt_driver);
> >
> > MODULE_AUTHOR("Renaud CERRATO ");
> > MODULE_DESCRIPTION("Watchdog driver for Atmel AT91SAM9x
> processors");
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> The module_platform_driver isn't a substitute of platform_driver_probe,
> because module_platform_driver use platform_driver_register/unregister.
> Using that macro we lose the advantage of platform_driver_probe,
> as stated in:
>
> https://lkml.org/lkml/2012/1/10/335
I just referred to the commit 6b761b2902c56b468370e0ee1691c37e0dae042a.
Didn't think more about it.
I will remove this patch in the next version.
> On Tue, Jan 10, 2012 at 21:47, Geert Uytterhoeven
> wrote:
> > [...]
> >Still, setting up platform_driver.probe and removing __init from all probe
> >functions is not the right thing to do, as this make (non-__init) kernel code
> >size bigger, while none of these devices are hotpluggable and thus cannot
> >appear after bootup. That's why we have platform_driver_probe() in the
> >first place. So I think all of this should be reverted for non-hotpluggable
> >drivers.
> > [...]
You said is reasonable, watchdog is not hotpluggable.
>
> Best regards
>
> --
> Fabio Porcedda
Best Regards,
Wenyou Yang
Re: [PATCH v4 1/4] ARM: Exynos5250: Enabling ehci-s5p driver
On Tue, Jan 15, 2013 at 7:08 PM, Vivek Gautam wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 25
>
> arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
> arch/arm/boot/dts/exynos5250.dtsi |6
> 3 files changed, 35 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> new file mode 100644
> index 000..e8bbb47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -0,0 +1,25 @@
> +Samsung Exynos SoC USB controller
> +
> +The USB devices interface with USB controllers on Exynos SOCs.
> +The device node has following properties.
> +
> +EHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
> + EHCI controller in host mode.
> + - reg: physical base address of the controller and length of memory mapped
> + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Optional properties:
> + - samsung,vbus-gpio: if present, specifies the GPIO that
> + needs to be pulled up for the bus to be powered.
> +
> +Example:
> +
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 942d576..7363e14 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -204,4 +204,8 @@
> samsung,mfc-r = <0x4300 0x80>;
> samsung,mfc-l = <0x5100 0x80>;
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
Add required vbus gpio for snow board also here.
> };
--
Thanks & Regards
Vivek
--
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: BUG at net/sunrpc/svc_xprt.c:921
16.01.2013 00:56, J. Bruce Fields пишет: On Mon, Jan 14, 2013 at 11:16:00PM -0500, Mark Lord wrote: On 13-01-14 03:37 PM, J. Bruce Fields wrote: Thanks for the report. On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote: Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server It's acting as an NFS client, right? Client and server, with other Linux boxes all running 3.something kernels. What did you upgrade from? 3.4.something, I believe. is getting these BUG complaints. The .config file is gzip'd/attached. Is this easy to reproduce? So far, it seems to pop up within a day or so of any reboot. I normally only reboot that system for a kernel upgrade, but can do so a bit more often if there's useful info to collect. So this means svc_delete_xprt was called on an xprt twice. That could happen if server threads are still running (and calling svc_recv) after we start shutting down the server: svc_shutdown_net assumes that server threads are already shut down, but that isn't true any more after the containerization work. I thought that would only be a bug for users actually running multiple containers, but looking at nfs_callback_down, I don't think that's true--it seems to always shut down the thread last. Thanks, Bruce. It reminds me the patch with additional protection for permanents sockets shutdown I've sent you a couple of mount ago... Look like I should revisit this patch at least. Mark, could you provide any call traces? --b. -- Best regards, Stanislav Kinsbursky -- 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] HID: add support for Sony RF receiver with USB product id 0x0374
Hi Jiri, On 2013/01/16 01:02, Jiri Kosina wrote: On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote: Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have a RF receiver, multi-interface USB device 054c:0374, that is used to connect a wireless keyboard and a wireless mouse. The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not seem to be generating any pointer events. The problem is that the mouse pointer is wrongly declared as a constant non-data variable in the report descriptor (see lsusb and usbhid-dump output below), with the consequence that it is ignored by the HID code. Add this device to the have-special-driver list and fix up the report descriptor in the Sony-specific driver which happens to already have a fixup for a similar firmware bug. Applied, thanks. Thank you. I noticed that the patch was tagged "for-3.9". Does this mean that it is too late to get it merged during the current release cycle? If possible, I would like to get it backported to 3.7-stable (and possibly 3.2 stable), since without it a whole family of Sony desktop computers is unusable under Linux out of the box. Should I do it myself or do you have a process in place for HID stable patches? Regards, Fernando -- 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/3] x86: enable common clk on x86
On Wed, Jan 16, 2013 at 12:59:17AM +0100, Rafael J. Wysocki wrote: > On Monday, January 14, 2013 04:46:26 PM Mika Westerberg wrote: > > We are starting to see traditional SoC peripherals also in the x86 world, > > things like UART, I2C and SPI controllers that might already have a working > > device driver. These drivers typically take advantage of the Linux clk > > framework to control and retrieve information about the peripheral clock. > > > > There hasn't been a standard way on x86 to pass the clock rate from > > whatever configuration system is used to the driver, but instead different > > variations have emerged, like adding this information to the platform data. > > > > In order to use the standard Linux way we enable the common clk subsystem > > also on x86. This allows us to re-use the drivers with little or no > > modification wrt. clock API usage. > > > > This patch was originally proposed by Mark Brown. > > Are there any side effects of selecting COMMON_CLK by an arch and if so then > what are they? Selecting COMMON_CLK also selects HAVE_CLK, so drivers that are dependent on that option become available when you run make config. It also makes clk_get() and friends to return errors if the clock is not found (instead of returning NULL as in case with !HAVE_CLK). This means that if there is a driver that counted on the stubbed out clocks on x86 it will fail to get the clock after this patch. However, the patch that adds the stub functions was merged only lately: commit 93abe8e4b13ae9a0428ce940a8a03ac72a7626f1 Author: Viresh Kumar Date: Mon Jul 30 14:39:27 2012 -0700 clk: add non CONFIG_HAVE_CLK routines Many drivers are shared between architectures that may or may not have HAVE_CLK selected for them. To remove compilation errors for them we enclose clk_*() calls in these drivers within #ifdef CONFIG_HAVE_CLK, #endif. This patch removes the need of these CONFIG_HAVE_CLK statements, by introducing dummy routines when HAVE_CLK is not selected by platforms. So, definition of these routines will always be available. These calls will return error for platforms that don't select HAVE_CLK. -- 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 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
On 1/15/2013 9:02 PM, Mike Turquette wrote: > Quoting Afzal Mohammed (2013-01-15 05:44:36) >> LCDC IP has a clock divider to adjust pixel clock, this limits pixel >> clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP). >> In the case of AM335x, where this IP is present, default fck is not >> sufficient to provide normal pixel clock rates, hence rendering this >> driver unusable on AM335x. >> >> If input clock too is configurable, allowable range of pixel clock >> would increase. Here initially it is checked whether with present fck, >> divider in IP could be configured to obtain required rate, if not, >> fck is adjusted. This makes it usable on AM335x. >> >> Note: >> A better (if allowable) solution may be to represent clock divider in >> LCDC IP as a basic divider clock - the one defined in common clock >> framework. But for this to happen, all the platform's using this driver >> should be using common clock framework (DaVinci is yet to be converted >> to use common clock framework). And it has to be determined whether >> common clock framework allows this kind of a clock modelling inside a >> driver and for this to be part of clock tree. Advantage of doing so >> would be better resolution for pixel clock, even though without this >> existing use cases are working properly. Or another extreme alternative >> would be to replicate clk-divider of common clock framework inside the >> driver, but that probably is not preferred and not worth as it would be >> duplication and without much advantage to existing users. >> > > Afzal, > > Modeling the divider inside your IP block as a clock is supported in the > common clock framework. Linking up these sorts of clocks to the clock > tree was one of the original design goals of CCF. > > Regarding DaVinci: converting that platform over to use CCF would be the > best approach. This is work in progress. There are patches that have been posted. Work has been slow on this though due to lack of bandwidth. > An alternative would be that you could break > single-image boot for AM335x and DaVinci, by having AM335x use CCF and > DaVinci use the legacy clock framework. From the LCDC driver's Single image for DaVinci and AM335x is not possible anyway since ARMv5 and ARMv6+ cannot be supported in a single image. > perspective this should not matter and is indeed the purpose of the > clk.h api and clkdev interfaces, however looking at this driver I can > see there would still be a lot ifdef-ery going on... better to just > convert everything over to CCF. Waiting for DaVinci CCF to complete will be too long a wait. Probably convert to CCF just for AM335x ATM. There would be some ifdef'ry but hopefully that need not be inside function bodies. Would have to see the implementation, I guess. Thanks, Sekhar -- 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] serial:ifx6x60:Keep word size accordance with SPI controller
Sorry for that, please check my resubmitted patch right now. Thanks, Chao -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Wednesday, January 16, 2013 10:50 AM To: Bi, Chao Cc: Alan Cox; Gorby, Russ; Chen, Jun D; linux-ser...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] serial:ifx6x60:Keep word size accordance with SPI controller On Wed, Dec 12, 2012 at 01:07:06PM +0800, chao bi wrote: > > As protocol driver, IFX SPI driver initiate to setup SPI master with > default SPI word size as 16 bit/word, however, SPI master may not > adopt this default value due to SPI controller's capability, it might > choose an available value by itself and set it to > spi_device.bits_per_word. In order to keep align with Controller, IFX > driver should make use of this value during SPI transfer, but the default one. > > Signed-off-by: Chen Jun > Signed-off-by: channing > --- > drivers/tty/serial/ifx6x60.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/tty/serial/ifx6x60.c > b/drivers/tty/serial/ifx6x60.c index 675d94a..5919992 100644 > --- a/drivers/tty/serial/ifx6x60.c > +++ b/drivers/tty/serial/ifx6x60.c > @@ -810,7 +810,8 @@ static void ifx_spi_io(unsigned long data) > ifx_dev->spi_xfer.cs_change = 0; > ifx_dev->spi_xfer.speed_hz = ifx_dev->spi_dev->max_speed_hz; > /* ifx_dev->spi_xfer.speed_hz = 390625; */ > - ifx_dev->spi_xfer.bits_per_word = spi_bpw; > + ifx_dev->spi_xfer.bits_per_word = > + ifx_dev->spi_dev->bits_per_word; Please follow the proper coding style (hint, this isn't it.) thanks, 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] serial:ifx6x60:Keep word size accordance with SPI controller
As protocol driver, IFX SPI driver initiate to setup SPI master with default SPI word size as 16 bit/word, however, SPI master may not adopt this default value due to SPI controller's capability, it might choose an available value by itself and set it to spi_device.bits_per_word. In order to keep align with Controller, IFX driver should make use of this value during SPI transfer, but the default one. Signed-off-by: Chen Jun Signed-off-by: channing --- drivers/tty/serial/ifx6x60.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c index 675d94a..3e337b8 100644 --- a/drivers/tty/serial/ifx6x60.c +++ b/drivers/tty/serial/ifx6x60.c @@ -810,7 +810,8 @@ static void ifx_spi_io(unsigned long data) ifx_dev->spi_xfer.cs_change = 0; ifx_dev->spi_xfer.speed_hz = ifx_dev->spi_dev->max_speed_hz; /* ifx_dev->spi_xfer.speed_hz = 390625; */ - ifx_dev->spi_xfer.bits_per_word = spi_bpw; + ifx_dev->spi_xfer.bits_per_word = + ifx_dev->spi_dev->bits_per_word; ifx_dev->spi_xfer.tx_buf = ifx_dev->tx_buffer; ifx_dev->spi_xfer.rx_buf = ifx_dev->rx_buffer; -- 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/
Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
On Tue, 2013-01-15 at 20:30 -0800, Eric W. Biederman wrote: > Vivek Goyal writes: > > > If a binary is signed, verify its signature. If signature is not valid, do > > not allow execution. If binary is not signed, execution is allowed > > unconditionally. > > > > CONFIG_BINFMT_ELF_SIGNATURE controls whether elf binary signature support > > is compiled in or not. > > > > Signature are expected to be present in elf section ".section". This code > > is written along the lines of module signature verification code. Just > > that I have removed the magic string. It is not needed as signature is > > expected to be present in a specific section. > > > > I put the signature into a section, instead of appending it so that > > strip operation works fine. > > > > One signs and verifies all the areas mapped by PT_LOAD segments of elf > > binary. Typically Elf header is mapped in first PT_LOAD segment. As adding > > .signature section can change three elf header fields (e_shoff, e_shnum > > and e_shstrndx), these fields are excluded from digest calculation > > My gut feel says that a signature that we verify should reside in an ELF > segment. Sections are for the linker not the kernel. > > I don't totally know what the signature should cover but my gut feels > says the signature should come after ever non-signature segment and > cover all of the prior segments (PT_LOAD or not). Because presumably > the loader needs to look at everything in a segment. We can > restrict ourselves to only processing signed binaries on executables > with only PT_LOAD segments and signatures for now. Please remind me why you can't use IMA-appraisal, which was upstreamed in Linux 3.7? Why another method is needed? With IMA-appraisal, there are a couple of issues that would still need to be addressed: - missing the ability to specify the validation method required. - modify the ima_appraise_tcb policy policy to require elf executables to be digitally signed. - security_bprm_check() is called before the binary handler is known. The first issue is addressed by a set of patches queued to be upstreamed in linux-integrity/next-ima-appraise-status. To address the last issue would either require moving the existing bprm_check or defining a new hook after the binary handler is known. thanks, Mimi -- 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 tegra tree with the arm-soc tree
On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote:
> On 01/15/2013 08:49 PM, Tony Prisk wrote:
> > On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the tegra tree got a conflict in
> >> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
> >> Move timer code to drivers/clocksource") from the arm-soc tree and commit
> >> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
> >> the tegra tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary (no action
> >> is required).
> >>
> >
> > I don't know about everyone else, but I feel the preference should be to
> > keep things alphabetized where possible to help avoid with merge
> > conflicts later on. This is always a problem when we start tacking
> > things on the end of lists.
> >
> > I realise this Kconfig is not alphabetized anyway, but it's never too
> > early to start on the 'right' path.
>
> Sounds like a good idea, but the issue is: When to do the initial sort
> so it doesn't conflict with all the adds in a kernel cycle... Post and
> immediately commit a new patch near the end of the merge window?
Given that the maintainer can quite safely do the patch (sorry
maintainers), I don't see any reason why it couldn't be done at the
point where they stop accepting patches for the merge-window. Once the
patches are stopped, sort the list in one last patch.
It makes sense to get it done in this window if possible as the Kconfig
will only get bigger as time goes on, making sorting it more time
consuming.
Regards
Tony P
--
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] mm: forcely swapout when we are out of page cache
On Tue, Jan 15, 2013 at 05:21:15PM -0800, Sonny Rao wrote: > On Tue, Jan 15, 2013 at 4:50 PM, Andrew Morton > wrote: > > On Tue, 15 Jan 2013 16:32:38 -0800 > > Sonny Rao wrote: > > > >> >> It's for saving the power to increase batter life. > >> > > >> > It might well have that effect, dunno. That wasn't my intent. Testing > >> > needed! > >> > > >> > >> Power saving is certainly why we had it on originally for ChromeOS, > >> but we turned it off due to misbehavior. > >> > >> Specifically, we saw a pathological behavior where we'd end up writing > >> to the disk every few seconds when laptop mode was turned on. This > >> turned out to be because laptop-mode sets a timer which is used to > >> check for new dirty data after the initial flush and writes that out > >> before spinning the disk down, and on ChromeOS various chatty daemons > >> on the system were logging and dirtying data more or less constantly > >> so there was almost always something there to be written out. So what > >> ended up happening was that we'd need to do a read, then wake up the > >> disk, and then keep writing every few seconds for a long period of > >> time, which had the opposite effect from what we wanted. > > > > So after the read, the disk would chatter away doing a dribble of > > writes? That sounds like plain brokenness (and why did the chrome guys > > not tell anyone about it?!?!?). > > Yes, either read or fsync. I ranted about it a little (here: > http://marc.info/?l=linux-mm=135422986220016=4), but mostly > assumed it was working as expected, and that ChromeOS was just > dirtying data at an absurd pace. Might have been a bad assumption and > I could have been more explicit about reporting it, sorry about that. > > > The idea is that when the physical > > read occurs, we should opportunistically flush out all pending writes, > > while the disk is running. Then go back into > > buffer-writes-for-a-long-time mode. > > > > See the comment in page-writeback.c above laptop_io_completion(): > > /* > * We've spun up the disk and we're in laptop mode: schedule writeback > * of all dirty data a few seconds from now. If the flush is already > scheduled > * then push it back - the user is still using the disk. > */ > void laptop_io_completion(struct backing_dev_info *info) > > What ends up happening fairly often is that there's always something > dirty with that few seconds (or even one second) on our system. > > > I forget what we did with fsync() and friends. Quite a lot of > > pestiferous applications like to do fsync quite frequently. I had a > > special kernel in which fsync() consisted of "return 0;", but ISTR > > there being some resistance to productizing that idea. > > > > Yeah, we have this problem and we try to fix up users of fsync() as we > find them but it's a bit of a never-ending battle. Such a feature > would be useful. > > >> The issues > >> with zram swap just confirmed that we didn't want laptop mode. > >> > >> Most of our devices have had SSDs rather than spinning disks, so noise > >> wasn't an issue, although when we finally did support an official > >> device with a spinning disk people certainly complained when the disk > >> started clicking all the time > > > > hm, it's interesting that the general idea still has vailidity. It > > would be a fun project for someone to sniff out all the requirements, > > fixup/enhance/rewrite the current implementation and generally make it > > all spiffy and nice. > > > >> (due to the underflow in the writeback code). > > > > To what underflow do you refer? > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c8b74c2f6604923de91f8aa6539f8bb934736754 > > That particular bug caused writes to happen almost instantly after the > underflow ocurred, and consequently slowed write throughput to a crawl > because there was no chance for contiguous writes to gather. > > >> We do know that current SSDs save a significant amount of > >> power when they go into standby, so minimizing disk writes is still > >> useful on these devices. > >> > >> A very simple laptop mode which only does a single sync when we spin > >> up the disk, and didn't bother with the timer behavior or muck with > >> swap behavior might be something that is more useful for us, and I > >> suspect it might simplify the writeback code somewhat as well. > > > > I don't think I understand the problem with the timer. My original RFC > > said > > > > : laptop_writeback_centisecs > > : -- > > : > > : This tunable determines the maximum age of dirty data when the machine > > : is operating in Laptop mode. The default value is 3 - five > > : minutes. This means that if applications are generating a small amount > > : of write traffic, the disk will spin up once per five minutes. > > : > > : If the disk is spun up for any other reason (such as for a read) then > > : all dirty data will be flushed anyway, and this timer is reset to zero. > > > >
Re: [PATCH 2/2] mm: forcely swapout when we are out of page cache
On Tue, Jan 15, 2013 at 04:09:57PM -0800, Andrew Morton wrote: > On Fri, 11 Jan 2013 13:43:27 +0900 > Minchan Kim wrote: > > > Hi Andrew, > > > > On Thu, Jan 10, 2013 at 01:58:28PM -0800, Andrew Morton wrote: > > > On Thu, 10 Jan 2013 11:23:06 +0900 > > > Minchan Kim wrote: > > > > > > > > I have a feeling that laptop mode has bitrotted and these patches are > > > > > kinda hacking around as-yet-not-understood failures... > > > > > > > > Absolutely, this patch is last guard for unexpectable behavior. > > > > As I mentioned in cover-letter, Luigi's problem could be solved either > > > > [1/2] > > > > or [2/2] but I wanted to add this as last resort in case of unexpected > > > > emergency. But you're right. It's not good to hide the problem like > > > > this path > > > > so let's drop [2/2]. > > > > > > > > Also, I absolutely agree it has bitrotted so for correcting it, we need > > > > a > > > > volunteer who have to inverstigate power saveing experiment with long > > > > time. > > > > So [1/2] would be band-aid until that. > > > > > > I'm inclined to hold off on 1/2 as well, really. > > > > Then, what's your plan? > > My plan is to sit here until someone gets down and fully tests and > fixes laptop-mode. Making it work properly, reliably and as-designed. > > Or perhaps someone wants to make the case that we just don't need it > any more (SSDs are silent!) and removes it all. > > > > > > > The point of laptop_mode isn't to save power btw - it is to minimise > > > the frequency with which the disk drive is spun up. By deferring and > > > then batching writeout operations, basically. > > > > I don't get it. Why should we minimise such frequency? > > Because my laptop was going clickety every minute and was keeping me > awake. > > > It's for saving the power to increase batter life. > > It might well have that effect, dunno. That wasn't my intent. Testing > needed! > > > As I real all document about laptop_mode, they all said about the power > > or battery life saving. > > > > 1. Documentation/laptops/laptop-mode.txt > > 2. http://linux.die.net/man/8/laptop_mode > > 3. http://samwel.tk/laptop_mode/ > > 3. http://www.thinkwiki.org/wiki/Laptop-mode > > Documentation creep ;) > > Ten years ago, gad: http://lwn.net/Articles/1652/ Odd, I grep it in linux-history.git and found this. http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=93d33a4885a483c708ccb7d24b56e0d5fef7bcab It seem to be first commit about laptop_mode but it still said about battery life , NOT clickety. But unfortunately, it had no number, measure method and even no side-effect when the memory pressure is severe so we couldn't sure how it helped about batter life without reclaim problem so the VM problem have been exported since we apply f80c067[mm: zone_reclaim: make isolate_lru_page() filter-aware]. So let's apply [1/2] in mainline and even stable to fix the problem. After that, we can add warning to laptop_mode so user who have used it will claim their requirements. With it, we can know they need it for power saving, clickety or , both so we can make requirement lists. From then, we can start to do someting. If we are luck, we can remove it totally if any user doesn't claim. What do you think about it? > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- 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] ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled
On Tue, Jan 15, 2013 at 11:45:08PM +0100, Rafael J. Wysocki wrote: > On Tuesday, January 15, 2013 05:23:24 PM Konrad Rzeszutek Wilk wrote: > > If cpuidle is disabled, that means the: > > > > per_cpu(acpi_cpuidle_device, pr->id) > > > > is set to NULL as the acpi_processor_power_init ends up failing at > > > > retval = cpuidle_register_driver(_idle_driver) > > > > (in acpi_processor_power_init) and never sets the per_cpu idle > > device. So when acpi_processor_hotplug on CPU online notification tries > > to reference said device it crashes: > > > > cpu 3 spinlock event irq 62 > > BUG: unable to handle kernel NULL pointer dereference at 0004 > > IP: [] acpi_processor_setup_cpuidle_cx+0x3f/0x105 > > PGD a259b067 PUD ab38b067 PMD 0 > > Oops: 0002 [#1] SMP > > odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp > > libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi > > wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata > > crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor > > drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt > > sysfillrect syscopyarea xenfs xen_privcmd mperf > > CPU 1 > > Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI > > MS-7680/H61M-P23 (MS-7680) > > RIP: e030:[] [] > > acpi_processor_setup_cpuidle_cx+0x3f/0x105 > > RSP: e02b:88001742dca8 EFLAGS: 00010202 > > RAX: 00010be9 RBX: 8800a0a61800 RCX: 88010538 > > RDX: 0003 RSI: 0200 RDI: 8800a0a61800 > > RBP: 88001742dce8 R08: 81812360 R09: 0200 > > R10: R11: 0001 R12: 8800a0a61800 > > R13: ff01 R14: R15: 81a907a0 > > FS: 7fd6942f7700() GS:88010528() knlGS: > > CS: e033 DS: ES: CR0: 80050033 > > CR2: 0004 CR3: a6773000 CR4: 00042660 > > DR0: DR1: DR2: > > DR3: DR6: 0ff0 DR7: 0400 > > Process bash (pid: 3047, threadinfo 88001742c000, task 880017944000) > > Stack: > > 0150 880100f59e00 88001742dcd8 8800a0a61800 > > ff01 81a907a0 > > 88001742dd18 813815b1 88001742dd08 810ae336 > > Call Trace: > > [] acpi_processor_hotplug+0x7c/0x9f > > [] ? schedule_delayed_work_on+0x16/0x20 > > [] acpi_cpu_soft_notify+0x90/0xca > > [] notifier_call_chain+0x4d/0x70 > > [] __raw_notifier_call_chain+0x9/0x10 > > [] __cpu_notify+0x1b/0x30 > > [] _cpu_up+0x103/0x14b > > [] cpu_up+0xd9/0xec > > [] store_online+0x94/0xd0 > > [] dev_attr_store+0x1b/0x20 > > [] sysfs_write_file+0xf4/0x170 > > > > This patch fixes it. > > This appears to be -stable material too. Which -stable kernels should it > be applied to? Oh, 3.1 and onward. I am basing that on 62027aea since that allowed subsystem to disable the cpuidle API. Thanks! > > Rafael > > > > Cc: Rafael J. Wysocki > > Signed-off-by: Konrad Rzeszutek Wilk > > --- > > drivers/acpi/processor_idle.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c > > index f1a5da4..fea6f8d 100644 > > --- a/drivers/acpi/processor_idle.c > > +++ b/drivers/acpi/processor_idle.c > > @@ -958,6 +958,9 @@ static int acpi_processor_setup_cpuidle_cx(struct > > acpi_processor *pr) > > return -EINVAL; > > } > > > > + if (!dev) > > + return -EINVAL; > > + > > dev->cpu = pr->id; > > > > if (max_cstate == 0) > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] ACPI: add support for CSRT table
On Wed, Jan 16, 2013 at 12:35:56AM +0100, Rafael J. Wysocki wrote:
> On Monday, January 14, 2013 11:51:51 AM Mika Westerberg wrote:
> > Core System Resources Table (CSRT) is a proprietary ACPI table that
> > contains resources for certain devices that are not found in the DSDT
> > table. Typically a shared DMA controller might be found here.
> >
> > This patch adds support for this table. We go through all entries in the
> > table and make platform devices of them. The resources from the table are
> > passed with the platform device.
> >
> > There is one special resource in the table and it is the DMA request line
> > base and number of request lines. This information might be needed by the
> > DMA controller driver as it needs to map the ACPI DMA request line number
> > to the actual request line understood by the hardware. This range is passed
> > as IORESOURCE_DMA resource.
>
> I have a question: Who's going to bind to those platform devices created
> by the code in this patch and how exactly this is going to happen?
Typically it is the DMA driver (but not limited to that). It is supposed to
work so that either the driver name (in the platform driver struct) matches
the device name in the CSRT or like with the dw_dmac case we do something
like:
/* The platform device created is "INTL9C60.0.auto" */
static const struct platform_device_id dw_dma_ids[] = {
{ "INTL9C60", 0 },
{ }
}
static struct platform_driver dw_driver = {
...
.id_table = dw_dma_ids,
};
--
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/
[3.8.0-0.rc3.git1.2] Processes hanging after unmounting mm0 device (not confirmed related)
Hello kernel folks, I am seeing problems with snapshot 3.8.0-0.rc3.git1.2 [fc19]. Processes hanging after it appears unmounting my mmc0 (SD) card, I will attempt to reproduce but, I am unclear if the two are related at this moment [ 9127.631555] mmc0: new high speed SDHC card at address 1234 [ 9127.665816] mmcblk0: mmc0:1234 SA08G 7.42 GiB [ 9127.667810] mmcblk0: p1 [ 9273.215847] mmc0: card 1234 removed [ 9273.219007] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9273.276972] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9273.336307] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9273.394115] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9273.453340] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9284.165082] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9284.226002] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9284.293369] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 9284.360836] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. Live stack trace: [10336.859532] SysRq : Show Blocked State [10336.859538] taskPC stack pid father [10336.859546] khugepaged D 88023bc93d80 032 2 0x [10336.859551] 88022ff07c80 0046 88022fef1760 88022ff07fd8 [10336.859555] 88022ff07fd8 88022ff07fd8 880230149760 88022fef1760 [10336.859558] 81e8b500 88022fef1760 88022a5e9568 [10336.859562] Call Trace: [10336.859574] [] schedule+0x29/0x70 [10336.859578] [] rwsem_down_failed_common+0xb5/0x140 [10336.859581] [] rwsem_down_read_failed+0x15/0x17 [10336.859587] [] call_rwsem_down_read_failed+0x14/0x30 [10336.859591] [] ? down_read+0x24/0x2b [10336.859597] [] khugepaged+0x17d/0x15b0 [10336.859602] [] ? wake_up_bit+0x40/0x40 [10336.859606] [] ? maybe_pmd_mkwrite+0x20/0x20 [10336.859609] [] kthread+0xc0/0xd0 [10336.859614] [] ? ftrace_define_fields_xen_mc_entry+0x30/0xf0 [10336.859618] [] ? kthread_create_on_node+0x120/0x120 [10336.859622] [] ret_from_fork+0x7c/0xb0 [10336.859626] [] ? kthread_create_on_node+0x120/0x120 [10336.859678] qemu-kvmD 88023bc93d80 0 3697 1 0x0080 [10336.859682] 8801e0a77cb8 0086 880190751760 8801e0a77fd8 [10336.859686] 8801e0a77fd8 8801e0a77fd8 8801c3b2aec0 880190751760 [10336.859689] 8801e0a77cb8 880190751760 880212659c88 [10336.859692] Call Trace: [10336.859697] [] schedule+0x29/0x70 [10336.859700] [] rwsem_down_failed_common+0xb5/0x140 [10336.859704] [] rwsem_down_write_failed+0x13/0x20 [10336.859708] [] call_rwsem_down_write_failed+0x13/0x20 [10336.859712] [] ? down_write+0x32/0x40 [10336.859716] [] vma_adjust+0x10d/0x770 [10336.859720] [] vma_merge+0x267/0x320 [10336.859723] [] do_brk+0x1e2/0x370 [10336.859727] [] sys_brk+0x13e/0x150 [10336.859730] [] system_call_fastpath+0x16/0x1b [10336.859785] ps D 88023bc93d80 0 3709 3708 0x0080 [10336.859788] 88018a765c90 0086 8801c8161760 88018a765fd8 [10336.859791] 88018a765fd8 88018a765fd8 880230149760 8801c8161760 [10336.859795] 0001 8801c8161760 88022a5e9568 fffe [10336.859798] Call Trace: [10336.859802] [] schedule+0x29/0x70 [10336.859805] [] rwsem_down_failed_common+0xb5/0x140 [10336.859809] [] rwsem_down_read_failed+0x15/0x17 [10336.859813] [] call_rwsem_down_read_failed+0x14/0x30 [10336.859817] [] ? down_read+0x24/0x2b [10336.859820] [] __access_remote_vm+0x3f/0x1d0 [10336.859823] [] access_process_vm+0x5f/0x90 [10336.859828] [] proc_pid_cmdline+0x9a/0x130 [10336.859831] [] proc_info_read+0x9f/0xf0 [10336.859836] [] vfs_read+0xa9/0x180 [10336.859839] [] sys_read+0x52/0xa0 [10336.859843] [] ? __audit_syscall_exit+0x20c/0x2c0 [10336.859847] [] system_call_fastpath+0x16/0x1b There are more but they show same point in the stack per process. Active CPU backtrace: [10718.740248] SysRq : Show backtrace of all active CPUs [10718.740252] sending NMI to all CPUs: [10718.740258] NMI backtrace for cpu 0 [10718.740259] CPU 0 [10718.740262] Pid: 7864, comm: bash Not tainted 3.8.0-0.rc3.git1.2.fc19.x86_64 #1 LENOVO 4058CTO/4058CTO [10718.740264] RIP: 0010:[] [] __const_udelay+0x12/0x30 [10718.740271] RSP: 0018:88022a7dde08 EFLAGS: 0046 [10718.740272] RAX: 01062560 RBX: 2710 RCX: 0002 [10718.740274] RDX: 00268f12 RSI: 0080 RDI: 00418958 [10718.740275] RBP: 88022a7dde28 R08:
Re: linux-next: manual merge of the tegra tree with the arm-soc tree
On 01/15/2013 08:49 PM, Tony Prisk wrote:
> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the tegra tree got a conflict in
>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
>> Move timer code to drivers/clocksource") from the arm-soc tree and commit
>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
>> the tegra tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>>
>
> I don't know about everyone else, but I feel the preference should be to
> keep things alphabetized where possible to help avoid with merge
> conflicts later on. This is always a problem when we start tacking
> things on the end of lists.
>
> I realise this Kconfig is not alphabetized anyway, but it's never too
> early to start on the 'right' path.
Sounds like a good idea, but the issue is: When to do the initial sort
so it doesn't conflict with all the adds in a kernel cycle... Post and
immediately commit a new patch near the end of the merge window?
--
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/3] binfmt_elf: Verify signature of signed elf binary
Vivek Goyal writes: > If a binary is signed, verify its signature. If signature is not valid, do > not allow execution. If binary is not signed, execution is allowed > unconditionally. > > CONFIG_BINFMT_ELF_SIGNATURE controls whether elf binary signature support > is compiled in or not. > > Signature are expected to be present in elf section ".section". This code > is written along the lines of module signature verification code. Just > that I have removed the magic string. It is not needed as signature is > expected to be present in a specific section. > > I put the signature into a section, instead of appending it so that > strip operation works fine. > > One signs and verifies all the areas mapped by PT_LOAD segments of elf > binary. Typically Elf header is mapped in first PT_LOAD segment. As adding > .signature section can change three elf header fields (e_shoff, e_shnum > and e_shstrndx), these fields are excluded from digest calculation My gut feel says that a signature that we verify should reside in an ELF segment. Sections are for the linker not the kernel. I don't totally know what the signature should cover but my gut feels says the signature should come after ever non-signature segment and cover all of the prior segments (PT_LOAD or not). Because presumably the loader needs to look at everything in a segment. We can restrict ourselves to only processing signed binaries on executables with only PT_LOAD segments and signatures for now. Eric -- 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.8-rc1 - another regression on USB :-(
Alan Stern wrote: On Sat, 12 Jan 2013, Andreas Mohr wrote: There's of course the EHCI vs. UHCI(/OHCI) duality (EHCI host controller responsible for high speed transfers, the other for 1.1 full speed, both serving the same port connectors). So if the coordination between the two is a problem, you might end up with merely full speed on a 2.0 port. And with drivers builtin vs. module, the init sequence/timing might possibly be affected - right? Perhaps this got worsened by semi-recent driver init kernel changes? (AFAIR the kernel was changed to init more things in parallel, for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing. Another important change is that the EHCI driver is now split into two modules. That can slow down loading and affect the timing. Alan Stern My testcase is a live initramfs + squash root. The boot logic is as stable as can be - unchanged since 2.6.2x kernels. And it was working fine till 3.8-rc1. The modules are insmoded in a fixed order: usb-common, usbcore, xhci-hcd, ehci-hcd, uhci-hcd, ohci-hcd, usbhid, usb_storage,... If all USB is built as modules - I get read errors from USB drives when accessing squash image, boot fails. If usb-common and usbcore are built in, system seems to crawl with a very slow USB, but boots. That could be caused by timing between hcd modules. If usb-common, usbcore and ehci-hcd are built-in, all works OK like "before 3.8". I was testing on machines without xhci or ohci hardware, so these drivers probably are not playing any role. I have retried initramfs with a 1s sleep between insmods to verify if it is timing - still the same read errors - so the main issue is _not_ timing. The read errors problem is 100% reproducible for me, the blocks where read fails are not fixed - every (failed) boot errors start appearing in a bit different location. Just selecting a differently - configured kernel image makes the boot work, so it is not a problem of squash image, USB drive, squashfs driver. Scratching my head loudly, Woody -- 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] module, async: async_synchronize_full() on module init iff async is used
Tejun Heo writes: > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3058,8 +3064,25 @@ static int do_init_module(struct module > blocking_notifier_call_chain(_notify_list, >MODULE_STATE_LIVE, mod); > > - /* We need to finish all async code before the module init sequence is > done */ > - async_synchronize_full(); Linus put async_synchronize_full() here as a fix but beware: you can start using the module before this call. Normally the potential caller is the one requesting the module load so it works, but if we get more async stuff we may land in that hole. Changing every caller of any async-initializing service is not going to be pretty, but maybe put an async_cookie_t in struct module for module_init to use, and sync it in try_module_get()? Which would now need a can_sleep flag... but the result would be more async. 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/
linux-next: Tree for Jan 16
Hi all, Changes since 20130115: Dropped tree: samung (many conflicts) The powerpc tree lost a build failure but still has another. The arm-soc tree gained conflicts against the slave-dma tree. The tegra tree gained conflicts against the arm-soc tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 211 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (406089d Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging fixes/master (d287b87 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arm-current/fixes (d106de3 ARM: 7614/1: mm: fix wrong branch from Cortex-A9 to PJ4b) Merging m68k-current/for-linus (e7e29b4 m68k: Wire up finit_module) Merging powerpc-merge/merge (e6449c9 powerpc: Add missing NULL terminator to avoid boot panic on PPC40x) Merging sparc/master (b7c13f7 sparc: remove __devinit, __devexit annotations) Merging net/master (daf3ec6 tg3: Fix crc errors on jumbo frame receive) Merging sound-current/for-linus (6f54c36 ALSA: hda/hdmi - Work around "alsactl restore" errors) Merging pci-current/for-linus (9e16721 PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported) Merging wireless/master (4668cce ath9k: disable the tasklet before taking the PCU lock) Merging driver-core.current/driver-core-linus (f1688e0 debugfs: convert gid= argument from decimal, not octal) Merging tty.current/tty-linus (d1c3ed6 Linux 3.8-rc2) Merging usb.current/usb-linus (8cf65dc usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added) Merging staging.current/staging-linus (397c606 staging: zram: fix invalid memory references during disk write) Merging char-misc.current/char-misc-linus (e6028db mei: fix mismatch in mutex unlock-lock in mei_amthif_read()) Merging input-current/for-linus (bec7a4b Input: lm8323 - fix checking PWM interrupt status) Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device tree binding for ERA information.) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option) CONFLICT (content): Merge conflict in arch/x86/Kconfig Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in hspi_probe().) Merging gpio-current/gpio/merge (bc1008c gpio/mvebu-gpio: Make mvebu-gpio depend on OF_CONFIG) Merging rr-fixes/fixes (52441fa module: prevent warning when finit_module a 0 sized file) Merging asm-gener
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Tue, Jan 15, 2013 at 7:05 PM, Ming Lei wrote: > > So looks only sd.c and floppy.c are to be synchronized suppose > some sync interfaces are introduced, doesn't it? What about ata_host_register() (usually called through ata_host_activate())? I don't understand why you continue to push for something fragile where you have to get things right in the driver, when it clearly is very fragile indeed, as now shown *twice* by how you seem to have missed some potential case. This is *exactly* why I NAK'ed the patch, and said it has to be handled automatically (or at least default to the safe model, not the unsafe one). We do have the automatic patch now. Admittedly it's not wonderful, and I agreed when Tejun called it slightly ugly, but at least it does these things automatically without humans having to go through these cases one by one and having to get them right. So please just stop pushing this "manual marking" thing. It's fundamentally flawed and broken. Linus -- 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: [ 000/171] 3.4.26-stable review
On Tue, Jan 15, 2013 at 08:48:24PM -0700, Shuah Khan wrote: > On Tue, Jan 15, 2013 at 3:42 PM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 3.4.26 release. > > There are 171 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jan 17 22:42:47 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.26-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. > Compiled and booted on the following systems: > HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Thanks for testing. 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: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Tue, 15 Jan 2013, Tejun Heo wrote: > Hello, Arjan. > > On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote: > > async fundamentally had the concept of a monotonic increasing number, > > and that you could always wait for "everyone before me". > > then people (like me) wanted exceptions to what "everyone" means ;-( > > I'm ok with going back to a single space and simplify the world. > > If we want (or need) finer grained operation, we'll probably have to > head the other direction, so that we can definitively tell that an > async operation belongs to domains system, module load A and B, so > that each waiter knows what to wait for. > > The current domain implementation is somewhere inbetween. It's not > completely simplistic system and at the same time not developed enough > to do properly stacked flushing. I like your idea of chronological synchronization: Insist that anybody who wants to flush async jobs must get a cookie, and then only allow them to wait for async jobs started after the cookie was issued. I don't know if this is possible with the current implementation. It would require changing every call to async_synchronize_*(), and in a nontrivial way. But it might provide a proper solution to all these problems. Can you think of any reasons why it wouldn't work in principle? It would prevent code from doing "wait until all currently-running async jobs have finished" -- but arguably, nobody should be allowed to do that anyway. Alan Stern -- 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] virtio-scsi: reset virtqueue affinity when doing cpu hotplug
On 01/16/2013 11:31 AM, Rusty Russell wrote:
> Wanlong Gao writes:
>> Add hot cpu notifier to reset the request virtqueue affinity
>> when doing cpu hotplug.
>
> You need to be careful to get_online_cpus() and put_online_cpus() here,
> so CPUs can't go up and down in the middle of operations.
>
> In particular, get_online_cpus()/put_online_cpus() around calls to
> virtscsi_set_affinity() (except within notifiers).
Yes, I'll take care of this, thank you.
>
>> +static int virtscsi_cpu_callback(struct notifier_block *nfb,
>> + unsigned long action, void *hcpu)
>> +{
>> +struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
>> +switch(action) {
>> +case CPU_ONLINE:
>> +case CPU_ONLINE_FROZEN:
>> +case CPU_DEAD:
>> +case CPU_DEAD_FROZEN:
>> +virtscsi_set_affinity(vscsi, true);
>> +break;
>> +default:
>> +break;
>> +}
>> +return NOTIFY_OK;
>> +}
>
> You probably want to remove affinities *before* the CPU goes down, and
> restore it after the CPU comes up.
>
> So, how about:
>
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_ONLINE:
> case CPU_DOWN_FAILED:
> virtscsi_set_affinity(vscsi, true, -1);
> break;
> case CPU_DOWN_PREPARE:
> virtscsi_set_affinity(vscsi, true, (unsigned long)hcpu);
> break;
> }
>
> The extra argument to virtscsi_set_affinity() is to tell it to ignore a
> cpu which seems online (because it's going down).
OK, thank you very much for teaching this.
>
>> static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
>> struct virtqueue *vq)
>> {
>> @@ -888,6 +909,13 @@ static int __devinit virtscsi_probe(struct
>> virtio_device *vdev)
>> if (err)
>> goto virtscsi_init_failed;
>>
>> +vscsi->nb.notifier_call = _cpu_callback;
>> +err = register_hotcpu_notifier(>nb);
>> +if (err) {
>> +pr_err("virtio_scsi: registering cpu notifier failed\n");
>> +goto scsi_add_host_failed;
>> +}
>> +
>
> You have to clean this up if scsi_add_host() fails, I think.
Yeah, will do, thank you very much.
Regards,
Wanlong Gao
>
> 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/
>
--
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: [ 000/171] 3.4.26-stable review
On Tue, Jan 15, 2013 at 3:42 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.26 release. > There are 171 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jan 17 22:42:47 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.26-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- 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 tegra tree with the arm-soc tree
On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tegra tree got a conflict in
> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
> Move timer code to drivers/clocksource") from the arm-soc tree and commit
> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
> the tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
I don't know about everyone else, but I feel the preference should be to
keep things alphabetized where possible to help avoid with merge
conflicts later on. This is always a problem when we start tacking
things on the end of lists.
I realise this Kconfig is not alphabetized anyway, but it's never too
early to start on the 'right' path.
Regards
Tony P
--
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 V4 3/3] ARM: davinci: da850: add NAND driver DT entries
Add NAND driver DT node and related pinctrl DT data to export NAND
functionality on da850 evm.
Signed-off-by: Kumar, Anil
---
:100644 100644 c7609d0... 433027f... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 e9c6e82... 59e6ea4... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts |5 +
arch/arm/boot/dts/da850.dtsi| 30 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c7609d0..433027f 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -28,4 +28,9 @@
status = "okay";
};
};
+ nand_cs3@6200 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_cs3_pins>;
+ };
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e9c6e82..59e6ea4 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -38,6 +38,23 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x>;
status = "disabled";
+
+ nand_cs3_pins: pinmux_nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_OE, EMA_WE */
+ 0x1c 0x0011 0x00ff
+ /* EMA_CS[4],EMA_CS[3]*/
+ 0x1c 0x0110 0x0ff0
+ /*
+* EMA_D[0], EMA_D[1], EMA_D[2],
+* EMA_D[3], EMA_D[4], EMA_D[5],
+* EMA_D[6], EMA_D[7]
+*/
+ 0x24 0x 0x
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x0110 0x0ff0
+ >;
+ };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -67,4 +84,17 @@
status = "disabled";
};
};
+ nand_cs3@6200 {
+ compatible = "ti,davinci-nand";
+ reg = <0x6200 0x807ff
+ 0x6800 0x8000>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+ status = "disabled";
+ };
};
--
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/
[PATCH V4 2/3] ARM: davinci: da8xx defconfig: enable pinctrl config option
Enable pinctrl related config option in da8xx_omapl_defconfig Signed-off-by: Kumar, Anil --- :100644 100644 f292239... 0892db4... M arch/arm/configs/da8xx_omapl_defconfig arch/arm/configs/da8xx_omapl_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig index f292239..0892db4 100644 --- a/arch/arm/configs/da8xx_omapl_defconfig +++ b/arch/arm/configs/da8xx_omapl_defconfig @@ -81,6 +81,7 @@ CONFIG_SERIAL_OF_PLATFORM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_DAVINCI=y +CONFIG_PINCTRL_SINGLE=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_REGULATOR=y -- 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/
[PATCH V4 1/3] ARM: davinci: da850: add pinctrl driver DT entries
For DT, DaVinci platform can use pinctrl-single driver for handling
padconf registers.
Enable PINCTRL Kconfig for MACH_DA8XX_DT platform. Add required
pinctrl DT entries in da850 dts file.
Test procedure
1)Populate DT file with NAND node information.
2)Populate board DT file with pinmux information for NAND.
3)Boot and confirm NAND is detected by the kernel.
4)cat /proc/mtd to show partitions.
Signed-off-by: Kumar, Anil
---
:100644 100644 37dc5a3... c7609d0... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 fbada87... e9c6e82... M arch/arm/boot/dts/da850.dtsi
:100644 100644 0153950... a075b3e... M arch/arm/mach-davinci/Kconfig
arch/arm/boot/dts/da850-evm.dts |3 +++
arch/arm/boot/dts/da850.dtsi| 10 ++
arch/arm/mach-davinci/Kconfig |1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..c7609d0 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -15,6 +15,9 @@
model = "DA850/AM1808/OMAP-L138 EVM";
soc {
+ pmx_core:pinmux@1c14120 {
+ status = "okay";
+ };
serial0: serial@1c42000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index fbada87..e9c6e82 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -29,6 +29,16 @@
#size-cells = <1>;
ranges = <0x0 0x01c0 0x40>;
+ pmx_core:pinmux@1c14120 {
+ compatible = "pinctrl-single";
+ reg = <0x14120 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ status = "disabled";
+ };
serial0: serial@1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0153950..a075b3e 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -62,6 +62,7 @@ config MACH_DA8XX_DT
bool "Support DA8XX platforms using device tree"
default y
depends on ARCH_DAVINCI_DA8XX
+ select PINCTRL
help
Say y here to include support for TI DaVinci DA850 based using
Flattened Device Tree. More information at Documentation/devicetree
--
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/
[PATCH V4 0/3] ARM: davinci: da850: add pinctrl support
This set of patches adds: * Add pinctrl-single for handling Padconf registers. * Add NAND node to export NAND functionality on da850 EVM. * Add NAND pinctrl node to do pin mux according to pinctrl-single driver. This series applies on top of tag next-20130107 git tree https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and the following patch -drivers/pinctrl: grab default handles from device core https://patchwork.kernel.org/patch/1862231/ This series is tested on da850 EVM. Changes since V3: -Move NAND related pinctrl DT data into the da850.dtsi file so it can be reused. Changes since V2: -Move NAND pins configuration into the nand_cs3 DT node to avoid pins configuration if it is not probed. Changes since V1: -Remove the binding documentation as already documented as part of Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt -Enable PINCTRL Kconfig for MACH_DA8XX_DT platform only. -Fix the pinctrl driver node unit-address. -Make separate patch for da8xx_omapl_defconfig changes. Kumar, Anil (3): ARM: davinci: da850: add pinctrl driver DT entries ARM: davinci: da8xx defconfig: enable pinctrl config option ARM: davinci: da850: add NAND driver DT entries arch/arm/boot/dts/da850-evm.dts|8 ++ arch/arm/boot/dts/da850.dtsi | 40 arch/arm/configs/da8xx_omapl_defconfig |1 + arch/arm/mach-davinci/Kconfig |1 + 4 files changed, 50 insertions(+), 0 deletions(-) -- 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/
Re: [ 00/71] 3.0.59-stable review
On Tue, Jan 15, 2013 at 3:53 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.59 release. > There are 71 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jan 17 22:53:26 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.59-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Cross-compile tests: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- 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] firmware: make sure the fw file size is not 0
On Tue, Jan 15, 2013 at 4:43 PM, Luciano Coelho wrote: > If the requested firmware file size is 0 bytes in the filesytem, we > will try to vmalloc(0), which causes a warning: > > [37834.750274] vmalloc: allocation failure: 0 bytes > [37834.756347] kworker/1:1: page allocation failure: order:0, mode:0xd2 > [37834.763214] [] (unwind_backtrace+0x0/0x13c) from [] > (dump_stack+0x20/0x24) > [37834.772430] [] (dump_stack+0x20/0x24) from [] > (warn_alloc_failed+0xc8/0x120) > [37834.781799] [] (warn_alloc_failed+0xc8/0x120) from [] > (__vmalloc_node_range+0x16) > [37834.792663] [] (__vmalloc_node_range+0x164/0x208) from > [] (__vmalloc_node+0x4c/0) > [37834.802703] [] (__vmalloc_node+0x4c/0x58) from [] > (vmalloc+0x38/0x44) > [37834.811401] [] (vmalloc+0x38/0x44) from [] > (_request_firmware_load+0x220/0x6b0) > [37834.820983] [] (_request_firmware_load+0x220/0x6b0) from > [] (request_firmware+0x) > [37834.831451] [] (request_firmware+0x64/0xc8) from [] > (wl18xx_setup+0xb4/0x570 [wl) > [37834.841918] [] (wl18xx_setup+0xb4/0x570 [wl18xx]) from > [] (wlcore_nvs_cb+0x64/0x) > [37834.852844] [] (wlcore_nvs_cb+0x64/0x9f8 [wlcore]) from > [] (request_firmware_wor) > [37834.864227] [] (request_firmware_work_func+0x94/0x100) from > [] (process_one_work) > [37834.875122] [] (process_one_work+0x1d0/0x750) from [] > (worker_thread+0x184/0x4ac) > [37834.884918] [] (worker_thread+0x184/0x4ac) from [] > (kthread+0xb4/0xc0) > [37834.893707] [] (kthread+0xb4/0xc0) from [] > (ret_from_fork+0x14/0x20) > > To fix this, check whether the file size is less than or equal to zero > in fw_read_file_contents(). > > Cc: stable [3.7] > Signed-off-by: Luciano Coelho > --- > drivers/base/firmware_class.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index d814603..b392b35 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -305,7 +305,7 @@ static bool fw_read_file_contents(struct file *file, > struct firmware_buf *fw_buf > char *buf; > > size = fw_file_size(file); > - if (size < 0) > + if (size <= 0) > return false; One trivial thing is that if we should return false on zero size firmware? If we think zero size firmware file as a good fw image, we should handle the case and return true. Otherwise, false should be returned. But that is not a big deal, so looks fine for me. Acked-by: Ming Lei Thanks, -- Ming Lei -- 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] MODSIGN: Add TAINT_NOKEY_MODULE
Josh Boyer writes:
> With module signing enabled but not in enforcing mode, we don't consider
> unsigned modules to be an error. However, if we encounter an unsigned
> module we currently taint the module and kernel with TAINT_FORCED_MODULE.
> That also disables lockdep within the kernel.
How about this, instead? Ingo?
taint: add explicit flag to show whether lock dep is still OK.
Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.
Signed-off-by: Rusty Russell
diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 272666d..2fca8ca 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -186,7 +186,7 @@ die_if_kernel(char * str, struct pt_regs *regs, long err,
unsigned long *r9_15)
#endif
printk("%s(%d): %s %ld\n", current->comm, task_pid_nr(current), str,
err);
dik_show_regs(regs, r9_15);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
dik_show_trace((unsigned long *)(regs+1));
dik_show_code((unsigned int *)regs->pc);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index b0179b8..02d2e1a 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -296,7 +296,7 @@ static void oops_end(unsigned long flags, struct pt_regs
*regs, int signr)
bust_spinlocks(0);
die_owner = -1;
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
die_nest_count--;
if (!die_nest_count)
/* Nest count reaches zero, release the lock. */
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 3883f84..d4fe267 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -242,7 +242,7 @@ void die(const char *str, struct pt_regs *regs, int err)
crash_kexec(regs);
bust_spinlocks(0);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
raw_spin_unlock_irq(_lock);
oops_exit();
diff --git a/arch/avr32/kernel/traps.c b/arch/avr32/kernel/traps.c
index 3d760c0..4c084d9 100644
--- a/arch/avr32/kernel/traps.c
+++ b/arch/avr32/kernel/traps.c
@@ -61,7 +61,7 @@ void die(const char *str, struct pt_regs *regs, long err)
show_regs_log_lvl(regs, KERN_EMERG);
show_stack_log_lvl(current, regs->sp, regs, KERN_EMERG);
bust_spinlocks(0);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
spin_unlock_irq(_lock);
if (in_interrupt())
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index a41eeb8..0637a86 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -225,7 +225,7 @@ int die(const char *str, struct pt_regs *regs, long err)
do_show_stack(current, >r30, pt_elr(regs));
bust_spinlocks(0);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
spin_unlock_irq();
diff --git a/arch/ia64/kernel/traps.c b/arch/ia64/kernel/traps.c
index bd42b76..e4e71c5 100644
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -72,7 +72,7 @@ die (const char *str, struct pt_regs *regs, long err)
bust_spinlocks(0);
die.lock_owner = -1;
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
spin_unlock_irq();
if (!regs)
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index cbc624a..18798af 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -1176,7 +1176,7 @@ void die_if_kernel (char *str, struct pt_regs *fp, int nr)
console_verbose();
printk("%s: %08x\n",str,nr);
show_registers(fp);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
do_exit(SIGSEGV);
}
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index cf7ac54..a88f820 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -396,7 +396,7 @@ void __noreturn die(const char *str, struct pt_regs *regs)
printk("%s[#%d]:\n", str, ++die_counter);
show_registers(regs);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
raw_spin_unlock_irq(_lock);
oops_exit();
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 45ba99f..614dc31 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -282,7 +282,7 @@ void die_if_kernel(char *str, struct pt_regs *regs, long
err)
show_regs(regs);
dump_stack();
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, false);
if (in_interrupt())
panic("Fatal exception in interrupt");
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 3251840..ec875b8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -138,7 +138,7 @@ static void __kprobes oops_end(unsigned long flags, struct
pt_regs *regs,
{
bust_spinlocks(0);
die_owner = -1;
-
Re: [PATCH 2/2] virtio-scsi: reset virtqueue affinity when doing cpu hotplug
Wanlong Gao writes:
> Add hot cpu notifier to reset the request virtqueue affinity
> when doing cpu hotplug.
You need to be careful to get_online_cpus() and put_online_cpus() here,
so CPUs can't go up and down in the middle of operations.
In particular, get_online_cpus()/put_online_cpus() around calls to
virtscsi_set_affinity() (except within notifiers).
> +static int virtscsi_cpu_callback(struct notifier_block *nfb,
> + unsigned long action, void *hcpu)
> +{
> + struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
> + switch(action) {
> + case CPU_ONLINE:
> + case CPU_ONLINE_FROZEN:
> + case CPU_DEAD:
> + case CPU_DEAD_FROZEN:
> + virtscsi_set_affinity(vscsi, true);
> + break;
> + default:
> + break;
> + }
> + return NOTIFY_OK;
> +}
You probably want to remove affinities *before* the CPU goes down, and
restore it after the CPU comes up.
So, how about:
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
case CPU_DOWN_FAILED:
virtscsi_set_affinity(vscsi, true, -1);
break;
case CPU_DOWN_PREPARE:
virtscsi_set_affinity(vscsi, true, (unsigned long)hcpu);
break;
}
The extra argument to virtscsi_set_affinity() is to tell it to ignore a
cpu which seems online (because it's going down).
> static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
>struct virtqueue *vq)
> {
> @@ -888,6 +909,13 @@ static int __devinit virtscsi_probe(struct virtio_device
> *vdev)
> if (err)
> goto virtscsi_init_failed;
>
> + vscsi->nb.notifier_call = _cpu_callback;
> + err = register_hotcpu_notifier(>nb);
> + if (err) {
> + pr_err("virtio_scsi: registering cpu notifier failed\n");
> + goto scsi_add_host_failed;
> + }
> +
You have to clean this up if scsi_add_host() fails, I think.
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: [RFCv2 00/12] Introduce host-side virtio queue and CAIF Virtio.
"Michael S. Tsirkin" writes:
>> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
>> +{
>> +struct iovec *new;
>> +unsigned int new_num = iov->max * 2;
>
> We must limit this I think, this is coming
> from userspace. How about UIO_MAXIOV?
We limit it to the ring size already; UIO_MAXIOV is a weird choice here.
>> +static u16 __cold return_from_indirect(const struct vringh *vrh, int
>> *up_next,
>> + struct vring_desc **descs, int *desc_max)
>
> Not sure it should be cold like that - virtio net uses indirect on data
> path.
This is only when we have a chained, indirect descriptor (ie. we have to
go back up to the next entry in the main descriptor table). That's
allowed in the spec, but noone does it.
>> +/* Make sure it's OK, and get offset. */
>> +if (!check_range(desc.addr, desc.len, , getrange)) {
>> +err = -EINVAL;
>> +goto fail;
>> +}
>
> Hmm this looks like it will translate and
> validate immediate descriptors same way as indirect ones.
> vhost-net has different translation for regular descriptors
> and indirect ones, both for speed and to allow ring aliasing,
> so it has to know which is which.
I see translate_desc() in both cases, what's different?
>> +addr = (void *)(long)desc.addr + range.offset;
>
> I really dislike raw pointers that we must never dereference.
> Since we are forcing everything to __user anyway, why don't we
> tag all addresses as __user? The kernel users of this API
> can cast that away, this will keep the casts to minimum.
>
> Failing that, we can add our own class
> # define __virtio __attribute__((noderef, address_space(2)))
In this case, perhaps we should leave addr as a u64?
>> +iov->iov[iov->i].iov_base = (__force __user void *)addr;
>> +iov->iov[iov->i].iov_len = desc.len;
>> +iov->i++;
>
>
> This looks like it won't do the right thing if desc.len spans multiple
> ranges. I don't know if this happens in practice but this is something
> vhost supports ATM.
Well, kind of. I assumed that the bool (*getrange)(u64, struct
vringh_range *)) callback would meld any adjacent ranges if it needs to.
>> +/* All the information about an iovec. */
>> +struct vringh_iov {
>> +struct iovec *iov;
>> +unsigned i, max;
>> +bool allocated;
>
> MAybe set iov = NULL when not allocated?
The idea was that iov points to the initial (on-stack?) iov, for the
fast path.
I'm writing a more complete test at the moment, then I will look at how
this fits with vhost.c as it stands...
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: [GIT PULL] extcon for 3.8-rc4
On 01/15/2013 10:49 PM, Greg KH wrote: > On Tue, Jan 15, 2013 at 10:23:44PM +0900, Chanwoo Choi wrote: >> On Tuesday, January 15, 2013, Greg KH wrote: >> >> On Tue, Jan 15, 2013 at 09:09:20PM +0900, Chanwoo Choi wrote: >> > On Tuesday, January 15, 2013, Greg KH wrote: >> > >> > On Tue, Jan 15, 2013 at 04:34:18PM +0900, Chanwoo Choi wrote: >> > > Hi Greg, >> > > >> > > This is the extcon pull request for Linux 3.8-rc4. >> > > >> > > Please pull extcon with following updates: >> > > >> > > Update to max77693/max8997 extcon driver: >> > > - Using MHL_TA cable for charging. >> > > - Support JIG cable. >> > > - Support Dock-Audio device for playing music and button of >> device. >> > > - Support Dock-Smart device for desktop mode with mouse/keyboard. >> > > - Set default UART/USB path on probe(). >> > > - Check the state/type of cable after completing initialization. >> > > - Code clean to remove duplicate code and bug fix related to >> sequence of >> > interrupt. >> > > - Fix irq_flag of max8997/max77693 driver. >> > > >> > > Update to arizona extcon driver: >> > > - Headphone measurements. >> > > - Alternative detection mechanism for non-default system designs. >> > > - Microphone clamp integration. >> > > - Support for additional detection pin. >> > > - MICBIAS rise time configuration. >> > > >> > > Thanks in advance for pulling, >> > >> > This request is for inclusion in 3.9, right? This seems much too >> big >> > for 3.8 at the moment. >> > >> > >> > If you think that, I agree your opinion about including this request in >> 3.9. >> >> That's really up to you, as a subsystem maintainer, to decide about. >> You need to take bugfixes and ask for them to be included in the 3.8, >> and new features and other work, for 3.9. >> >> OK, I will resend pull-request to include only bugfixes patch in 3.8. >> After released v3.8-rc7 or 3.8-rc8 kernel, I will send pull-request of extcon >> to include new feature patches of extcon driver in 3.9. > > No, you can send me that pull request now as well, I have two different > branches, one to go to Linus for this release, and one for the next one. > Both of them show up in linux-next. You should have the same. > > So you can send me two pull requests now, does that make more sense? > I understand and thanks for your comment. I will resend only one pull-request for extcon to include it for -next branch. I don't send separate pull-request for bugfixes patch. Best regards and thanks, Chanwoo Choi -- 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] module, async: async_synchronize_full() on module init iff async is used
On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo wrote: > Hello, Linus. > > On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote: >> That said, maybe we could just make the rule be that you can't pick a >> default IO scheduler that is modular. > > This is definitely much more preferable but it would affect use case > where everything is built modular and the elevator is selected via > kernel param. This is way outside the usual usage and we can warn > about the new behavior but it still is an observable behavior change. > Do you think this would be okay? I do want the same user-visible semantics, so it's not some one-liner. The compiled-in elevator would be easy enough to handle in the Kconfig file (maybe we do already, I didn't even bother to check). The real problem is the "chosen_elevator" one, which is dynamic with the kernel command line. And we could handle that one by just trying to load the module early (but exactly _when_?) and then instead of looking things up by name, just keep a pointer to the default elevator around. But no, it's not just some trivial one-liner. Especially the question about "when to try to load the module that is given on the kernel command line" is not trivial. Do we require that the module is in the initrd and loadable basically immediate at boot? Do we try again after switching the root filesystem? Things like that.. > And then this warning can be added without introducing > request_module_but_dont_warn_about_being_called_from_async(). I do agree that it would be much nicer that way. Linus -- 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] module, async: async_synchronize_full() on module init iff async is used
On Wed, Jan 16, 2013 at 10:52 AM, Tejun Heo wrote: > If the default iosched is built as module, the kernel may deadlock > while trying to load the iosched module on device probe if the probing > was running off async. This is because async_synchronize_full() at > the end of module init ends up waiting for the async job which > initiated the module loading. > > async Amodprobe > > 1. finds a device > 2. registers the block device > 3. request_module(default iosched) > 4. modprobe in userland > 5. load and init module > 6. async_synchronize_full() > > Async A waits for modprobe to finish in request_module() and modprobe > waits for async A to finish in async_synchronize_full(). > > Because there's no easy to track dependency once control goes out to > userland, implementing properly nested flushing is difficult. For > now, make module init perform async_synchronize_full() iff module init > has queued async jobs as suggested by Linus. > > This avoids the described deadlock because iosched module doesn't use > async and thus wouldn't invoke async_synchronize_full(). This is > hacky and incomplete. It will deadlock if async module loading nests; > however, this works around the known problem case and seems to be the > best of bad options. > > For more details, please refer to the following thread. > > http://thread.gmane.org/gmane.linux.kernel/1420814 > > Signed-off-by: Tejun Heo > Reported-by: Alex Riesen > Cc: Linus Torvalds > --- Looks it does fix the deadlock problem on my Pandaboard, also the scsi disk device node(/dev/sdX) comes just after loading module of 'sd_mod'. Tested-by: Ming Lei Thanks, -- Ming Lei -- 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: [PATCHv2] Smack: add support for modification of existing rules
On 1/10/2013 10:42 AM, Rafal Krypa wrote:
> Rule modifications are enabled via /smack/change-rule. Format is as follows:
> "Subject Object rwaxt rwaxt"
>
> First two strings are subject and object labels up to 255 characters.
> Third string contains permissions to enable.
> Fourth string contains permissions to disable.
>
> All unmentioned permissions will be left unchanged.
> If no rule previously existed, it will be created.
>
> Targeted for git://git.gitorious.org/smack-next/kernel.git
Applied to git://git.gitorious.org/smack-next/kernel.git#stage-for-3.9
>
> Signed-off-by: Rafal Krypa
> ---
> Documentation/security/Smack.txt | 11 ++
> security/smack/smackfs.c | 249
> ++
> 2 files changed, 181 insertions(+), 79 deletions(-)
>
> diff --git a/Documentation/security/Smack.txt
> b/Documentation/security/Smack.txt
> index 8a177e4..7a2d30c 100644
> --- a/Documentation/security/Smack.txt
> +++ b/Documentation/security/Smack.txt
> @@ -117,6 +117,17 @@ access2
> ambient
> This contains the Smack label applied to unlabeled network
> packets.
> +change-rule
> + This interface allows modification of existing access control rules.
> + The format accepted on write is:
> + "%s %s %s %s"
> + where the first string is the subject label, the second the
> + object label, the third the access to allow and the fourth the
> + access to deny. The access strings may contain only the characters
> + "rwxat-". If a rule for a given subject and object exists it will be
> + modified by enabling the permissions in the third string and disabling
> + those in the fourth string. If there is no such rule it will be
> + created using the access specified in the third and the fourth strings.
> cipso
> This interface allows a specific CIPSO header to be assigned
> to a Smack label. The format accepted on write is:
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 337e32c..2479a41 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -50,12 +50,12 @@ enum smk_inos {
> SMK_ACCESS2 = 16, /* make an access check with long labels */
> SMK_CIPSO2 = 17, /* load long label -> CIPSO mapping */
> SMK_REVOKE_SUBJ = 18, /* set rules with subject label to '-' */
> + SMK_CHANGE_RULE = 19, /* change or add rules (long labels) */
> };
>
> /*
> * List locks
> */
> -static DEFINE_MUTEX(smack_list_lock);
> static DEFINE_MUTEX(smack_cipso_lock);
> static DEFINE_MUTEX(smack_ambient_lock);
> static DEFINE_MUTEX(smk_netlbladdr_lock);
> @@ -110,6 +110,13 @@ struct smack_master_list {
>
> LIST_HEAD(smack_rule_list);
>
> +struct smack_parsed_rule {
> + char*smk_subject;
> + char*smk_object;
> + int smk_access1;
> + int smk_access2;
> +};
> +
> static int smk_cipso_doi_value = SMACK_CIPSO_DOI_DEFAULT;
>
> const char *smack_cipso_option = SMACK_CIPSO_OPTION;
> @@ -167,25 +174,28 @@ static void smk_netlabel_audit_set(struct netlbl_audit
> *nap)
> #define SMK_NETLBLADDRMIN9
>
> /**
> - * smk_set_access - add a rule to the rule list
> - * @srp: the new rule to add
> + * smk_set_access - add a rule to the rule list or replace an old rule
> + * @srp: the rule to add or replace
> * @rule_list: the list of rules
> * @rule_lock: the rule list lock
> + * @global: if non-zero, indicates a global rule
> *
> * Looks through the current subject/object/access list for
> * the subject/object pair and replaces the access that was
> * there. If the pair isn't found add it with the specified
> * access.
> *
> - * Returns 1 if a rule was found to exist already, 0 if it is new
> * Returns 0 if nothing goes wrong or -ENOMEM if it fails
> * during the allocation of the new pair to add.
> */
> -static int smk_set_access(struct smack_rule *srp, struct list_head
> *rule_list,
> - struct mutex *rule_lock)
> +static int smk_set_access(struct smack_parsed_rule *srp,
> + struct list_head *rule_list,
> + struct mutex *rule_lock, int global)
> {
> struct smack_rule *sp;
> + struct smack_master_list *smlp;
> int found = 0;
> + int rc = 0;
>
> mutex_lock(rule_lock);
>
> @@ -197,23 +207,89 @@ static int smk_set_access(struct smack_rule *srp,
> struct list_head *rule_list,
> if (sp->smk_object == srp->smk_object &&
> sp->smk_subject == srp->smk_subject) {
> found = 1;
> - sp->smk_access = srp->smk_access;
> + sp->smk_access |= srp->smk_access1;
> + sp->smk_access &= ~srp->smk_access2;
> break;
> }
> }
> - if (found == 0)
> - list_add_rcu(>list, rule_list);
>
Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
On 16.01.2013 03:40, Jason Cooper wrote: Soeren, On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote: On 15.01.2013 22:56, Jason Cooper wrote: On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote: If my understanding is correct, one of the drivers (most likely one) either asks for too small of a dma buffer, or is not properly deallocating blocks from the per-device pool. Either case leads to exhaustion, and falling back to the atomic pool. Which subsequently gets wiped out as well. If my hunch is right, could you please try each of the three dvb drivers in turn and see which one (or more than one) causes the error? In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk demodulator, and dib0700 usb bridge plus dib7000p demod. I would bet for em28xx causing the error, but this is not thoroughly tested. Unfortunately testing with removed sticks is not easy, because this is a production system and disabling some services for the long time we need to trigger this error will certainly result in unhappy users. Just out of curiosity, what board is it? The kirkwood board? A modified Guruplug Server Plus. I will see what I can do here. Is there an easy way to track the buffer usage without having to wait for complete exhaustion? DMA_API_DEBUG OK, maybe I can try this. In linux-3.5.x there is no such problem. Can we use all available memory for dma buffers here on armv5 architectures, in contrast to newer kernels? Were the loads exactly the same when you tested 3.5.x? Exactly the same, yes. I looked at the changes from v3.5 to v3.7.1 for all four drivers you mentioned as well as sata_mv. The biggest thing I see is that all of the media drivers got shuffled around into their own subdirectories after v3.5. 'git show -M 0c0d06c' shows it was a clean copy of all the files. What would be most helpful is if you could do a git bisect between v3.5.x (working) and the oldest version where you know it started failing (v3.7.1 or earlier if you know it). I did not bisect it, but Marek mentioned earlier that commit e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced new code for dma allocations. This is probably the root cause for the new (mis-)behavior (due to my tests 3.6.0 is not working anymore). I'm not very familiar with arm mm code, and from the patch itself I cannot understand what's different. Maybe CONFIG_CMA is default also for armv5 (not only v6) now? But I might be totally wrong here, maybe someone of the mm experts can explain the difference? Regards, Soeren -- 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] module, async: async_synchronize_full() on module init iff async is used
Hello, Linus. On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote: > That said, maybe we could just make the rule be that you can't pick a > default IO scheduler that is modular. This is definitely much more preferable but it would affect use case where everything is built modular and the elevator is selected via kernel param. This is way outside the usual usage and we can warn about the new behavior but it still is an observable behavior change. Do you think this would be okay? > And I *would* like to see the warning we discussed. Maybe there are > other situations that can trigger this? > > Because something like that > > WARN_ON_ONCE(wait && i_am_async() && system_state == SYSTEM_RUNNING); > > in kernel/kmod.c (__request_module()) still sounds like a good idea to > verify that this is the only thing that triggers it (of course, we'd > need to somehow avoid the warning for the known case with the known > workaround). And then this warning can be added without introducing request_module_but_dont_warn_about_being_called_from_async(). Thanks. -- tejun -- 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 tegra tree with the arm-soc tree
Hi all,
Today's linux-next merge of the tegra tree got a conflict in
drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
Move timer code to drivers/clocksource") from the arm-soc tree and commit
ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
the tegra 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 drivers/clocksource/Makefile
index 440449c,b5cc507..000
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@@ -17,6 -17,6 +17,7 @@@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU) += cl
obj-$(CONFIG_ARMADA_370_XP_TIMER) += time-armada-370-xp.o
obj-$(CONFIG_ARCH_BCM2835)+= bcm2835_timer.o
obj-$(CONFIG_SUNXI_TIMER) += sunxi_timer.o
+obj-$(CONFIG_VT8500_TIMER)+= vt8500_timer.o
+ obj-$(CONFIG_ARCH_TEGRA) += tegra20_timer.o
obj-$(CONFIG_CLKSRC_ARM_GENERIC) += arm_generic.o
pgpgoNu2BZmoj.pgp
Description: PGP signature
Re: linux-next: manual merge of the tegra tree with the arm-soc tree
Hi All,
On Wed, 16 Jan 2013 14:10:16 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tegra tree got a conflict in
> arch/arm/mach-tegra/board-dt-tegra20.c between commit 1d5cc604f42f ("ARM:
> remove mach .handle_irq for GIC users") from the arm-soc tree and commit
> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
> the tegra tree.
This also affected arch/arm/mach-tegra/board-dt-tegra30.c.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-tegra/board-dt-tegra30.c
index 12dc2dd,cfe5fc0..000
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@@ -111,7 -113,8 +112,7 @@@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Te
.map_io = tegra_map_common_io,
.init_early = tegra30_init_early,
.init_irq = tegra_dt_init_irq,
- .init_time = tegra_init_timer,
- .handle_irq = gic_handle_irq,
+ .init_time = clocksource_of_init,
.init_machine = tegra30_dt_init,
.init_late = tegra_init_late,
.restart= tegra_assert_system_reset,
pgpqEBX8SkDVa.pgp
Description: PGP signature
linux-next: manual merge of the tegra tree with the arm-soc tree
Hi all,
Today's linux-next merge of the tegra tree got a conflict in
arch/arm/mach-tegra/board-dt-tegra20.c between commit 1d5cc604f42f ("ARM:
remove mach .handle_irq for GIC users") from the arm-soc tree and commit
ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
the tegra 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-tegra/board-dt-tegra20.c
index 5ed81bab,171ba3c..000
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@@ -200,7 -203,8 +201,7 @@@ DT_MACHINE_START(TEGRA_DT, "nVidia Tegr
.smp= smp_ops(tegra_smp_ops),
.init_early = tegra20_init_early,
.init_irq = tegra_dt_init_irq,
- .init_time = tegra_init_timer,
- .handle_irq = gic_handle_irq,
+ .init_time = clocksource_of_init,
.init_machine = tegra_dt_init,
.init_late = tegra_dt_init_late,
.restart= tegra_assert_system_reset,
pgpxLRlOyirH5.pgp
Description: PGP signature
[PATCH V2] mm/slab: add a leak decoder callback
This adds a leak decoder callback so that slab destruction
can use to generate debugging output for the allocated objects.
Callers like btrfs are using their own leak tracking which will
manage allocated objects in a list(or something else), this does
indeed the same thing as what slab does. So adding a callback
for leak tracking can avoid this as well as runtime overhead.
(The idea is from Zach Brown .)
Signed-off-by: Liu Bo
---
v2: add a wrapper API for slab destruction to make decoder only
work in particular path.
fs/btrfs/extent_io.c | 26 --
fs/btrfs/extent_map.c| 13 -
include/linux/slab.h |2 ++
include/linux/slab_def.h |1 +
include/linux/slub_def.h |1 +
mm/slab_common.c | 17 -
mm/slub.c|2 ++
7 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index bcc8dff..355c7fc 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -63,6 +63,26 @@ tree_fs_info(struct extent_io_tree *tree)
return btrfs_sb(tree->mapping->host->i_sb);
}
+static void extent_state_leak_decoder(void *object)
+{
+ struct extent_state *state = object;
+
+ printk(KERN_ERR "btrfs state leak: start %llu end %llu "
+ "state %lu in tree %p refs %d\n",
+ (unsigned long long)state->start,
+ (unsigned long long)state->end,
+ state->state, state->tree, atomic_read(>refs));
+}
+
+static void extent_buffer_leak_decoder(void *object)
+{
+ struct extent_buffer *eb = object;
+
+ printk(KERN_ERR "btrfs buffer leak start %llu len %lu "
+ "refs %d\n", (unsigned long long)eb->start,
+ eb->len, atomic_read(>refs));
+}
+
int __init extent_io_init(void)
{
extent_state_cache = kmem_cache_create("btrfs_extent_state",
@@ -115,9 +135,11 @@ void extent_io_exit(void)
*/
rcu_barrier();
if (extent_state_cache)
- kmem_cache_destroy(extent_state_cache);
+ kmem_cache_destroy_decoder(extent_state_cache,
+ extent_state_leak_decoder);
if (extent_buffer_cache)
- kmem_cache_destroy(extent_buffer_cache);
+ kmem_cache_destroy_decoder(extent_buffer_cache,
+ extent_buffer_leak_decoder);
}
void extent_io_tree_init(struct extent_io_tree *tree,
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index f359e4c..bccba3d 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -16,6 +16,16 @@ static LIST_HEAD(emaps);
static DEFINE_SPINLOCK(map_leak_lock);
#endif
+static void extent_map_leak_decoder(void *object)
+{
+ struct extent_map *em = object;
+
+ printk(KERN_ERR "btrfs ext map leak: start %llu len %llu block %llu "
+ "flags %lu refs %d in tree %d compress %d\n",
+ em->start, em->len, em->block_start, em->flags,
+ atomic_read(>refs), em->in_tree, (int)em->compress_type);
+}
+
int __init extent_map_init(void)
{
extent_map_cache = kmem_cache_create("btrfs_extent_map",
@@ -39,7 +49,8 @@ void extent_map_exit(void)
}
if (extent_map_cache)
- kmem_cache_destroy(extent_map_cache);
+ kmem_cache_destroy_decoder(extent_map_cache,
+ extent_map_leak_decoder);
}
/**
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 5d168d7..5c6a8d8 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -114,6 +114,7 @@ struct kmem_cache {
const char *name; /* Slab name for sysfs */
int refcount; /* Use counter */
void (*ctor)(void *); /* Called on object slot creation */
+ void (*decoder)(void *);/* Called on object slot leak detection */
struct list_head list; /* List of all slab caches on the system */
};
#endif
@@ -132,6 +133,7 @@ struct kmem_cache *
kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t,
unsigned long, void (*)(void *), struct kmem_cache *);
void kmem_cache_destroy(struct kmem_cache *);
+void kmem_cache_destroy_decoder(struct kmem_cache *, void (*)(void *));
int kmem_cache_shrink(struct kmem_cache *);
void kmem_cache_free(struct kmem_cache *, void *);
diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 8bb6e0e..7ca8309 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -48,6 +48,7 @@ struct kmem_cache {
/* constructor func */
void (*ctor)(void *obj);
+ void (*decoder)(void *obj);
/* 4) cache creation/removal */
const char *name;
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 9db4825..fc18af7 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -93,6 +93,7 @@ struct kmem_cache {
gfp_t
