Re: [PATCHV3 1/3] x86, ras: Add new infrastructure for machine check fixup tables

[Borislav Petkov]

On Tue, Dec 15, 2015 at 05:29:30PM -0800, Tony Luck wrote:
> Copy the existing page fault fixup mechanisms to create a new table
> to be used when fixing machine checks. Note:
> 1) At this time we only provide a macro to annotate assembly code
> 2) We assume all fixups will in code builtin to the kernel.
> 3) Only for x86_64
> 4) New code under CONFIG_MCE_KERNEL_RECOVERY (default 'n')
> 
> Signed-off-by: Tony Luck 
> ---
>  arch/x86/Kconfig  | 10 ++
>  arch/x86/include/asm/asm.h| 10 --
>  arch/x86/include/asm/mce.h| 14 ++
>  arch/x86/kernel/cpu/mcheck/mce.c  | 16 
>  arch/x86/kernel/vmlinux.lds.S |  6 +-
>  arch/x86/mm/extable.c | 19 +++
>  include/asm-generic/vmlinux.lds.h | 12 +++-
>  7 files changed, 79 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 96d058a87100..42d26b4d1ec4 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1001,6 +1001,16 @@ config X86_MCE_INJECT
> If you don't know what a machine check is and you don't do kernel
> QA it is safe to say n.
>  
> +config MCE_KERNEL_RECOVERY
> + bool "Recovery from machine checks in special kernel memory copy 
> functions"
> + default n
> + depends on X86_MCE && X86_64

Still no dependency on CONFIG_LIBNVDIMM.

> + ---help---
> +   This option provides a new memory copy function mcsafe_memcpy()
> +   that is annotated to allow the machine check handler to return
> +   to an alternate code path to return an error to the caller instead
> +   of crashing the system. Say yes if you have a driver that uses this.
> +

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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 1/3] ACPI: amba bus probing support

[Andy Shevchenko]

On Mon, Dec 21, 2015 at 6:41 PM, Aleksey Makarov
 wrote:
> From: Graeme Gregory 
>
> On ARM64 some devices use the AMBA device and not the platform bus for
> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
> does not have a suitable clock representation and to keep the core
> AMBA bus code unchanged between probing methods.
>
> Signed-off-by: Graeme Gregory 
> Signed-off-by: Aleksey Makarov 
> ---
>  drivers/acpi/Makefile|   1 +
>  drivers/acpi/acpi_amba.c | 149 
> +++
>  drivers/acpi/internal.h  |   5 ++
>  3 files changed, 155 insertions(+)
>  create mode 100644 drivers/acpi/acpi_amba.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 675eaf3..3cf732f 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -43,6 +43,7 @@ acpi-y+= pci_root.o 
> pci_link.o pci_irq.o
>  acpi-y += acpi_lpss.o acpi_apd.o
>  acpi-y += acpi_platform.o
>  acpi-y += acpi_pnp.o
> +acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
>  acpi-y += int340x_thermal.o
>  acpi-y += power.o
>  acpi-y += event.o
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> new file mode 100644
> index 000..ebc8913
> --- /dev/null
> +++ b/drivers/acpi/acpi_amba.c
> @@ -0,0 +1,149 @@
> +
> +/*
> + * ACPI support for platform bus type.
> + *
> + * Copyright (C) 2015, Linaro Ltd
> + * Authors: Graeme Gregory 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "internal.h"
> +
> +static const struct acpi_device_id amba_id_list[] = {
> +   {"ARMH0011", 0}, /* PL011 SBSA Uart */
> +   {"ARMH0061", 0}, /* PL061 GPIO Device */
> +   {"", 0},
> +};
> +
> +static struct clk *amba_dummy_clk;
> +
> +static void amba_register_dummy_clk(void)
> +{
> +   struct clk *clk;
> +
> +   /* If clock already registered */
> +   if (amba_dummy_clk)
> +   return;
> +
> +   clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
> +   clk_register_clkdev(clk, "apb_pclk", NULL);
> +
> +   amba_dummy_clk = clk;
> +}
> +
> +static int amba_handler_attach(struct acpi_device *adev,
> +   const struct acpi_device_id *id)
> +{
> +   struct amba_device *dev = NULL;
> +   struct acpi_device *acpi_parent;
> +   struct resource_entry *rentry;
> +   struct list_head resource_list;
> +   struct resource *resources = NULL;
> +   bool address_found = false;
> +   int ret, count, irq_no = 0;
> +
> +   /* If the ACPI node already has a physical device attached, skip it. 
> */
> +   if (adev->physical_node_count)
> +   return 0;
> +
> +   amba_register_dummy_clk();
> +
> +   dev = amba_device_alloc(NULL, 0, 0);
> +   if (!dev) {
> +   pr_err("%s(): amba_device_alloc() failed for %s\n",

Can it be dev_err(>dev, …); ?
Same for below cases.

> +  __func__, dev_name(>dev));
> +   return 0;
> +   }
> +
> +   INIT_LIST_HEAD(_list);

> +   count = acpi_dev_get_resources(adev, _list, NULL, NULL);
> +   if (count < 0) {
> +   return 0;
> +   } else if (count > 0) {
> +   resources = kmalloc_array(count, sizeof(struct resource),
> +   GFP_KERNEL);
> +   if (!resources) {
> +   acpi_dev_free_resource_list(_list);
> +   return 0;
> +   }
> +   count = 0;
> +   list_for_each_entry(rentry, _list, node) {
> +   switch (resource_type(rentry->res)) {
> +   case IORESOURCE_MEM:
> +   if (!address_found) {
> +   dev->res = *rentry->res;
> +   address_found = true;
> +   }
> +   break;
> +   case IORESOURCE_IRQ:
> +   if (irq_no < AMBA_NR_IRQS)
> +   dev->irq[irq_no++] = 
> rentry->res->start;
> +   break;
> +   default:
> +   dev_warn(>dev, "Invalid resource\n");
> +   }
> +   }
> +   acpi_dev_free_resource_list(_list);
> +   }
> +
> +   

Re: [PATCH 1/2] ARM: dts: ts-4800: Add LCD support

[Damien Riegel]

On Mon, Dec 21, 2015 at 09:35:19PM +0800, Shawn Guo wrote:
> On Fri, Dec 18, 2015 at 12:00:32PM -0500, Damien Riegel wrote:
> > This commit adds LCD support for the TS-4800. The panel is an Okaya
> > RS800480T-7X0WQ and the timings have been extracted from Technologic
> > Systems' tree.
> > 
> > Signed-off-by: Damien Riegel 
> > ---
> >  arch/arm/boot/dts/imx51-ts4800.dts | 109 
> > +
> >  1 file changed, 109 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx51-ts4800.dts 
> > b/arch/arm/boot/dts/imx51-ts4800.dts
> > index 83352cb..4951ebd 100644
> > --- a/arch/arm/boot/dts/imx51-ts4800.dts
> > +++ b/arch/arm/boot/dts/imx51-ts4800.dts
> > @@ -30,6 +30,60 @@
> > clock-frequency = <24576000>;
> > };
> > };
> > +
> > +   regulators {
> > +   compatible = "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   backlight_reg: regulator@0 {
> > +   compatible = "regulator-fixed";
> > +   reg = <0>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_enable_lcd>;
> > +   regulator-name = "enable_lcd_reg";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   gpio = < 9 GPIO_ACTIVE_HIGH>;
> > +   enable-active-high;
> > +   };
> > +   };
> 
> DT maintainers dislike this fake simple-bus container.  Let's put the
> regulator directly under root like below.
> 
> backlight_reg: regulator-backlight {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> pinctrl-0 = <_enable_lcd>;
> regulator-name = "enable_lcd_reg";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> gpio = < 9 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
> 
> I fixed it up and applied both patches.

Thank you. I am using the imx51-*.dts as examples, maybe they should be
updated to be consistent with the newer device tree style? I'm willing
to do that but I don't want to make changes on dts files that I can't
test.

Sidenote: your Signed-off-by is missing on these two patches.


Thanks,
Damien

> 
> Shawn
> 
> > +
> > +   backlight: backlight {
> > +   compatible = "pwm-backlight";
> > +   pwms = < 0 78770>;
> > +   brightness-levels = <0 150 200 255>;
> > +   default-brightness-level = <1>;
> > +   power-supply = <_reg>;
> > +   };
> > +
> > +   display0: display@di0 {
> > +   compatible = "fsl,imx-parallel-display";
> > +   interface-pix-fmt = "rgb24";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_lcd>;
> > +
> > +   display-timings {
> > +   800x480p60 {
> > +   native-mode;
> > +   clock-frequency = <30066000>;
> > +   hactive = <800>;
> > +   vactive = <480>;
> > +   hfront-porch = <50>;
> > +   hback-porch = <70>;
> > +   hsync-len = <50>;
> > +   vback-porch = <0>;
> > +   vfront-porch = <0>;
> > +   vsync-len = <50>;
> > +   };
> > +   };
> > +
> > +   port@0 {
> > +   display0_in: endpoint {
> > +   remote-endpoint = <_di0_disp0>;
> > +   };
> > +   };
> > +   };
> >  };
> >  
> >   {
> > @@ -60,6 +114,16 @@
> > };
> >  };
> >  
> > +_di0_disp0 {
> > +   remote-endpoint = <_in>;
> > +};
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pwm_backlight>;
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_uart1>;
> > @@ -115,6 +179,12 @@
> > >;
> > };
> >  
> > +   pinctrl_enable_lcd: enablelcdgrp {
> > +   fsl,pins = <
> > +   MX51_PAD_CSI2_D12__GPIO4_9  0x1c5
> > +   >;
> > +   };
> > +
> > pinctrl_esdhc1: esdhc1grp {
> > fsl,pins = <
> > MX51_PAD_SD1_CMD__SD1_CMD   0x400020d5
> > @@ -159,6 +229,45 @@
> > >;
> > };
> >  
> > +   pinctrl_lcd: lcdgrp {
> > +   fsl,pins = <
> > +   MX51_PAD_DISP1_DAT0__DISP1_DAT0 0x5
> > +   MX51_PAD_DISP1_DAT1__DISP1_DAT1 0x5
> > +   MX51_PAD_DISP1_DAT2__DISP1_DAT2 0x5
> > +   MX51_PAD_DISP1_DAT3__DISP1_DAT3 0x5
> > +   MX51_PAD_DISP1_DAT4__DISP1_DAT4 0x5
> > +   

Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Dr. Philipp Tomsich]

> On 18 Dec 2015, at 13:47, Arnd Bergmann  wrote:
> 
>> 3. Follow the PCS up to glibc but always pass syscall arguments in W
>>   registers, like AArch32 compat support (the least preferred option,
>>   the only advantage is a single wrapper for all syscalls but it would
>>   be doing unnecessary zeroing even for syscalls where it isn't needed)
> 
> This would mean we cannot pass 64-bit arguments in registers, right?

Note that there’s no 32bit registers (the ‘w’-form always refers to the lower
32bits of a 64bit register, with implicit zero-extension)… and load/store
instructions always use the full base-register (‘x’-form) for address 
calculation.
I.e. a load/store would inadvertently pickup “random garbage” in the upper 
32bits, if no explicit zero-extension is applied.

In other words: all zero-extensions for 32bit arguments should be explicit
on the kernel side.

Regards,
Philipp.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] staging: lustre: Fix a jump label position in osc_get_info()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 19:30:42 +0100

The script "checkpatch.pl" pointed out that labels should not be indented.
Thus delete a horizontal tab before the jump label "out"
in the function "osc_get_info".

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/osc/osc_request.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index d6c1447..85ab180 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -2727,7 +2727,7 @@ static int osc_get_info(const struct lu_env *env, struct 
obd_export *exp,
}
 
*((u64 *)val) = *reply;
-   out:
+out:
ptlrpc_req_finished(req);
return rc;
} else if (KEY_IS(KEY_FIEMAP)) {
-- 
2.6.3

--
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 4/4] scsi: storvsc: Tighten up the interrupt path

[KY Srinivasan]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Monday, December 21, 2015 8:28 AM
> To: KY Srinivasan ; Hannes Reinecke ;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com
> Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path
> 
> On Sat, 2015-12-19 at 02:28 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com
> > > ]
> > > Sent: Friday, December 18, 2015 8:48 AM
> > > To: KY Srinivasan ; Hannes Reinecke <
> > > h...@suse.de>;
> > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > > de...@linuxdriverproject.org; oher...@suse.com;
> > > jbottom...@parallels.com; h...@infradead.org;
> > > linux-s...@vger.kernel.org;
> > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > martin.peter...@oracle.com
> > > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt
> > > path
> > >
> > > On Fri, 2015-12-18 at 16:20 +, KY Srinivasan wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Hannes Reinecke [mailto:h...@suse.de]
> > > > > Sent: Friday, December 18, 2015 12:52 AM
> > > > > To: KY Srinivasan ;
> > > > > gre...@linuxfoundation.org;
> > > > > linux-
> > > > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > > > oher...@suse.com;
> > > > > jbottom...@parallels.com; h...@infradead.org;
> > > > > linux-s...@vger.kernel.org;
> > > > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > > > martin.peter...@oracle.com
> > > > > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the
> > > > > interrupt
> > > > > path
> > > > >
> > > > > On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> > > > > > On the interrupt path, we repeatedly establish the pointer to
> > > > > > the
> > > > > > storvsc_device. Fix this.
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan 
> > > > > > Reviewed-by: Long Li 
> > > > > > Reviewed-by: Johannes Thumshirn 
> > > > > > Tested-by: Alex Ng 
> > > > > > ---
> > > > > >   drivers/scsi/storvsc_drv.c |   23 ---
> > > > > >   1 files changed, 8 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/scsi/storvsc_drv.c
> > > > > > b/drivers/scsi/storvsc_drv.c
> > > > > > index d6ca4f2..b68aebe 100644
> > > > > > --- a/drivers/scsi/storvsc_drv.c
> > > > > > +++ b/drivers/scsi/storvsc_drv.c
> > > > > > @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct
> > > > > vmscsi_request *vm_srb,
> > > > > >   }
> > > > > >
> > > > > >
> > > > > > -static void storvsc_command_completion(struct
> > > > > > storvsc_cmd_request
> > > > > *cmd_request)
> > > > > > +static void storvsc_command_completion(struct
> > > > > > storvsc_cmd_request
> > > > > *cmd_request,
> > > > > > +  struct storvsc_device
> > > > > > *stor_dev)
> > > > > >   {
> > > > > > struct scsi_cmnd *scmnd = cmd_request->cmd;
> > > > > > -   struct hv_host_device *host_dev = shost_priv(scmnd
> > > > > > ->device-
> > > > > > host);
> > > > > > struct scsi_sense_hdr sense_hdr;
> > > > > > struct vmscsi_request *vm_srb;
> > > > > > struct Scsi_Host *host;
> > > > > > -   struct storvsc_device *stor_dev;
> > > > > > -   struct hv_device *dev = host_dev->dev;
> > > > > > u32 payload_sz = cmd_request->payload_sz;
> > > > > > void *payload = cmd_request->payload;
> > > > > >
> > > > > > -   stor_dev = get_in_stor_device(dev);
> > > > > > host = stor_dev->host;
> > > > > >
> > > > > > vm_srb = _request->vstor_packet.vm_srb;
> > > > > > @@ -987,14 +984,13 @@ static void
> > > > > > storvsc_command_completion(struct
> > > > > storvsc_cmd_request *cmd_request)
> > > > > > kfree(payload);
> > > > > >   }
> > > > > >
> > > > > > -static void storvsc_on_io_completion(struct hv_device
> > > > > > *device,
> > > > > > +static void storvsc_on_io_completion(struct storvsc_device
> > > > > > *stor_device,
> > > > > >   struct vstor_packet
> > > > > > *vstor_packet,
> > > > > >   struct
> > > > > > storvsc_cmd_request
> > > > > > *request)
> > > > > >   {
> > > > > > -   struct storvsc_device *stor_device;
> > > > > > struct vstor_packet *stor_pkt;
> > > > > > +   struct hv_device *device = stor_device->device;
> > > > > >
> > > > > > -   stor_device = hv_get_drvdata(device);
> > > > > > stor_pkt = >vstor_packet;
> > > > > >
> > > > > > /*
> > > > > > @@ -1049,7 +1045,7 @@ static void
> > > > > > 

Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, 2015-12-21 at 18:16 +, Måns Rullgård wrote:
>> Andy Shevchenko  writes:
>> 
>> > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård 
>> > wrote:
>> > > Andy Shevchenko  writes:
>> > > 
>> > I used to have a patch to implement this in dw_dmac driver.
>> > However, I
>> > dropped it at some point. Seems we need it back and now I possible
>> > have a good explanation why.
>> 
>> Are you still able to find that patch?  Shouldn't be too hard to do
>> from scratch if not.
>
> Yes, I found a version of it, let me mock up tomorrow something
> working.
>
>> 
>> > > If those values didn't matter, why would the fields exist in the
>> > > first place?
>> > 
>> > Because someone can have more than one AHB bus on the system and
>> > connect DMA to all of them (up to 4).
>> 
>> Which apparently these guys did.  Well, not a full-blown AHB bus, but
>> they seem to be using two master interfaces.
>
> To different buses? Intel HW uses two masters and they are quite equal
> (at least from OS point of view, it might be HW adjusts it).

Judging by the block diagram in the 460EX datasheet [1], and by the fact
that the old SATA driver works despite using an invalid address, the DMA
FIFO of the controller isn't connected to the AHB bus at all but
directly to master 0 on the DW DMA controller.  Master 1 of the DMA
controller is connected to the AHB bus, which is bridged to the main
system bus.

I haven't managed to find a full manual for the 460EX.

[1] http://datasheet.octopart.com/PPC460EX-NUB800T-AMCC-datasheet-11553412.pdf

-- 
Måns Rullgård
--
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] nfsd fix for 4.4

[J. Bruce Fields]

Please pull an nfsd change for 4.4:

  git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.4-1

Just one fix for a NFSv4 callback bug introduced in 4.4.


Jeff Layton (1):
  nfsd: don't hold ls_mutex across a layout recall

 fs/nfsd/nfs4layouts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] irqchip: add documentation for TS-4800 interrupt controller

[Damien Riegel]

This is an interrupt-controller implemented in an FPGA, to multiplex
interrupts generated from other IPs. The FPGA usually uses a GPIO as a
parent interrupt controller to notify that one of the multiplexed
interrupts has triggered.

Signed-off-by: Damien Riegel 
Acked-by: Rob Herring 
---
Changes in v2:
 - Added Acked-by Rob Herring.

 .../bindings/interrupt-controller/technologic,ts4800.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt 
b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
new file mode 100644
index 000..7f15f1b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
@@ -0,0 +1,16 @@
+TS-4800 FPGA interrupt controller
+
+TS-4800 FPGA has an internal interrupt controller. When one of the
+interrupts is triggered, the SoC is notified, usually using a GPIO as
+parent interrupt source.
+
+Required properties:
+- compatible: should be "technologic,ts4800-irqc"
+- interrupt-controller: identifies the node as an interrupt controller
+- reg: physical base address of the controller and length of memory mapped
+  region
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: phandle to the parent interrupt controller this one is
+  cascaded from
+- interrupts: specifies the interrupt line in the interrupt-parent controller
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] irqchip: add TS-4800 interrupt controller

[Damien Riegel]

This commit adds support for the TS-4800 interrupt controller. This
controller is instantiated in a companion FPGA, and multiplex interrupts
for other FPGA IPs.

As this component is external to the SoC, the SoC might need to reserve
pins, so this controller is implemented as a platform driver and doesn't
use the IRQCHIP_DECLARE construct.

Signed-off-by: Damien Riegel 
---
Changes in v2:
 - Added chained_irq_{enter,exit} in interrupt handler.

 drivers/irqchip/Kconfig  |   6 ++
 drivers/irqchip/Makefile |   1 +
 drivers/irqchip/irq-ts4800.c | 163 +++
 3 files changed, 170 insertions(+)
 create mode 100644 drivers/irqchip/irq-ts4800.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 27b52c8..e734772 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -137,6 +137,12 @@ config TB10X_IRQC
select IRQ_DOMAIN
select GENERIC_IRQ_CHIP
 
+config TS4800_IRQ
+   tristate "TS-4800 IRQ controller"
+   select IRQ_DOMAIN
+   help
+ Support for the TS-4800 FPGA IRQ controller
+
 config VERSATILE_FPGA_IRQ
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index bb3048f..ca9de01 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_ARCH_NSPIRE) += irq-zevio.o
 obj-$(CONFIG_ARCH_VT8500)  += irq-vt8500.o
 obj-$(CONFIG_ST_IRQCHIP)   += irq-st.o
 obj-$(CONFIG_TB10X_IRQC)   += irq-tb10x.o
+obj-$(CONFIG_TS4800_IRQ)   += irq-ts4800.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-ts4800.c b/drivers/irqchip/irq-ts4800.c
new file mode 100644
index 000..1dc5f3d
--- /dev/null
+++ b/drivers/irqchip/irq-ts4800.c
@@ -0,0 +1,163 @@
+/*
+ * Multiplexed-IRQs driver for TS-4800's FPGA
+ *
+ * Copyright (c) 2015 - Savoir-faire Linux
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IRQ_MASK0x4
+#define IRQ_STATUS  0x8
+
+struct ts4800_irq_data {
+   void __iomem*base;
+   struct irq_domain   *domain;
+   struct irq_chip irq_chip;
+};
+
+static void ts4800_irq_mask(struct irq_data *d)
+{
+   struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
+   u16 mask = 1 << d->hwirq;
+   u16 reg = readw(data->base + IRQ_MASK);
+
+   writew(reg | mask, data->base + IRQ_MASK);
+}
+
+static void ts4800_irq_unmask(struct irq_data *d)
+{
+   struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
+   u16 mask = 1 << d->hwirq;
+   u16 reg = readw(data->base + IRQ_MASK);
+
+   writew(reg & ~mask, data->base + IRQ_MASK);
+}
+
+static int ts4800_irqdomain_map(struct irq_domain *d, unsigned int irq,
+   irq_hw_number_t hwirq)
+{
+   struct ts4800_irq_data *data = d->host_data;
+
+   irq_set_chip_and_handler(irq, >irq_chip, handle_simple_irq);
+   irq_set_chip_data(irq, data);
+   irq_set_noprobe(irq);
+
+   return 0;
+}
+
+struct irq_domain_ops ts4800_ic_ops = {
+   .map = ts4800_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void ts4800_ic_chained_handle_irq(struct irq_desc *desc)
+{
+   struct ts4800_irq_data *data = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   u16 status = readw(data->base + IRQ_STATUS);
+
+   chained_irq_enter(chip, desc);
+
+   if (unlikely(status == 0)) {
+   handle_bad_irq(desc);
+   goto out;
+   }
+
+   do {
+   unsigned int bit = __ffs(status);
+   int irq = irq_find_mapping(data->domain, bit);
+
+   status &= ~(1 << bit);
+   generic_handle_irq(irq);
+   } while (status);
+
+out:
+   chained_irq_exit(chip, desc);
+}
+
+static int ts4800_ic_probe(struct platform_device *pdev)
+{
+   struct device_node *node = pdev->dev.of_node;
+   struct ts4800_irq_data *data;
+   struct irq_chip *irq_chip;
+   struct resource *res;
+   int parent_irq;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   data->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(data->base))
+   return PTR_ERR(data->base);
+
+   writew(0x, data->base + IRQ_MASK);
+
+   parent_irq = irq_of_parse_and_map(node, 

[REGRESSION] tcp/ipv4: kernel panic because of (possible) division by zero

[Oleksandr Natalenko]

Commit 3759824da87b30ce7a35b4873b62b0ba38905ef5 (tcp: PRR uses CRB mode by 
default and SS mode conditionally) introduced changes to net/ipv4/tcp_input.c 
tcp_cwnd_reduction() that, possibly, cause division by zero, and therefore, 
kernel panic in interrupt handler [1].

Reverting 3759824da87b30ce7a35b4873b62b0ba38905ef5 seems to fix the issue.

I'm able to reproduce the issue on 4.3.0–4.3.3 once per several day 
(occasionally).

What could be done to help in debugging this issue?

Regards,
  Oleksandr.

[1] http://i.piccy.info/
i9/6f5cb187c4ff282d189f78c63f95af43/1450729403/283985/951663/panic.jpg
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote:
>> On 12/21/2015 2:27 PM, Måns Rullgård wrote:
>> > The hard drive is recognized .
>> > > These system gets unresponsive with USB devices like the mouse
>> > > and
>> > > keyboard not responding  when I start Gparted.
>> > Did you disable the SATA and DMA debug messages?
>> > 
>> It is working.
>
> Indeed, thanks, Julian!
>
> I might ask you to test my branch with set of patches when it will be
> ready (apparently after Xmas) if you are okay with that.
>
> Måns, also I would ask you to test on your hardware (AVR32) as well if
> you have no objections.

Sure, but it will have to wait until January.

-- 
Måns Rullgård
--
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/2] crypto: KEYS: convert public key to the akcipher api

[Tadeusz Struk]

Hi,
On 12/19/2015 03:49 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> [auto build test ERROR on crypto/master]
> [also build test ERROR on v4.4-rc5 next-20151218]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-KEYS-convert-public-key-to-akcipher-api/20151213-103429
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master
> config: x86_64-randconfig-s4-12200710 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/crypto/public_key.h:17:0,
> from include/linux/verify_pefile.h:15,
> from arch/x86/kernel/kexec-bzimage64.c:22:
>include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to 
>>> incomplete type 'const struct key'
>  return key->payload.data[asym_key_ids];
>^
> 
> vim +74 include/keys/asymmetric-type.h
> 
> 7901c1a8 David Howells 2014-09-16  68 
> size_t len_1,
> 7901c1a8 David Howells 2014-09-16  69 
> const void *val_2,
> 7901c1a8 David Howells 2014-09-16  70 
> size_t len_2);
> 146aa8b1 David Howells 2015-10-21  71  static inline
> 146aa8b1 David Howells 2015-10-21  72  const struct asymmetric_key_ids 
> *asymmetric_key_ids(const struct key *key)
> 146aa8b1 David Howells 2015-10-21  73  {
> 146aa8b1 David Howells 2015-10-21 @74 return 
> key->payload.data[asym_key_ids];
> 146aa8b1 David Howells 2015-10-21  75  }
> 7901c1a8 David Howells 2014-09-16  76  
> 7901c1a8 David Howells 2014-09-16  77  /*
> 
> :: The code at line 74 was first introduced by commit
> :: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
> data with the payload data
> 
> :: TO: David Howells 
> :: CC: David Howells 
> 

The previous patch was broken, re-sending again, sorry.

I think there is something missing in this configuration.
cat .config | grep KEXEC_BZIMAGE_VERIFY_SIG gives nothing.
Anyways, this patch should fix it.

---8<---

From: Tadeusz Struk 

Fix auto build test ERROR on crypto/master

Reported-by: 
Signed-off-by: Tadeusz Struk 

diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 0f8a6bb..23aa625 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -19,9 +19,10 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
 #include 
 #include 
-
+#endif
 #include 
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[3.13.y-ckt stable] Linux 3.13.11-ckt32

[Kamal Mostafa]

I am announcing the release of the Linux 3.13.11-ckt32 kernel.

The updated 3.13.y-ckt tree can be found at: 
  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.13.y

The diff from v3.13.11-ckt31 is posted as a follow-up to this email.

The 3.13.y-ckt extended stable tree is maintained by the Canonical Kernel Team.
For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Kamal

-- 
 Makefile  |  22 +++-
 arch/Kconfig  |  67 +++
 arch/arc/kernel/unwind.c  |  37 +-
 arch/arm/Kconfig  |  13 +--
 arch/arm/Makefile |   4 -
 arch/arm/boot/compressed/misc.c   |  14 +++
 arch/arm/boot/dts/kirkwood-ts219.dtsi |   2 +-
 arch/arm64/include/asm/kvm_emulate.h  |   8 +-
 arch/arm64/kernel/setup.c |   4 +
 arch/arm64/kvm/inject_fault.c |   2 +-
 arch/mips/Kconfig |  14 +--
 arch/mips/Makefile|   4 -
 arch/mips/kvm/kvm_locore.S|  16 ++-
 arch/mips/kvm/kvm_mips.c  |   5 +-
 arch/mips/kvm/kvm_mips_emul.c |   2 +-
 arch/parisc/include/uapi/asm/mman.h   |  10 --
 arch/powerpc/include/asm/reg.h|   1 +
 arch/powerpc/kernel/signal_32.c   |  14 ++-
 arch/powerpc/kernel/signal_64.c   |   4 +
 arch/sh/Kconfig   |  15 +--
 arch/sh/Makefile  |   4 -
 arch/x86/Kconfig  |  17 +--
 arch/x86/Makefile |   8 +-
 arch/x86/kernel/cpu/common.c  |   3 +-
 arch/x86/kernel/signal.c  |  17 +--
 arch/x86/kernel/xsave.c   |  11 +-
 block/blk-core.c  |  21 ++--
 block/partitions/mac.c|  10 +-
 drivers/gpu/drm/radeon/rv730_dpm.c|   2 +-
 drivers/gpu/drm/radeon/rv770_dpm.c|   4 +-
 drivers/iio/adc/ad7793.c  |   2 +-
 drivers/iio/dac/ad5064.c  |  91 ++-
 drivers/isdn/hisax/config.c   |   2 +-
 drivers/isdn/hisax/hfc_pci.c  |   2 +-
 drivers/isdn/hisax/hfc_sx.c   |   2 +-
 drivers/isdn/hisax/q931.c |   6 +-
 drivers/md/dm-mpath.c |   2 +-
 drivers/md/dm.c   |   2 +-
 drivers/mmc/card/block.c  |  11 +-
 drivers/net/can/sja1000/sja1000.c |   3 +
 drivers/net/ethernet/marvell/mvneta.c |   6 +-
 drivers/net/ethernet/mellanox/mlx4/main.c |   8 +-
 drivers/net/phy/broadcom.c|   2 +-
 drivers/net/wan/x25_asy.c |   6 +-
 drivers/remoteproc/remoteproc_debugfs.c   |   2 +-
 drivers/scsi/hosts.c  |  11 ++
 drivers/staging/iio/adc/lpc32xx_adc.c |   4 +-
 drivers/target/iscsi/iscsi_target.c   |  13 ++-
 drivers/target/iscsi/iscsi_target_nego.c  |   1 +
 drivers/target/target_core_sbc.c  |  17 ++-
 drivers/target/target_core_transport.c|  14 ++-
 drivers/tty/n_tty.c   |   6 +-
 drivers/usb/chipidea/debug.c  |   2 +
 drivers/usb/class/usblp.c |   2 +-
 drivers/usb/dwc3/gadget.c |  23 +++-
 drivers/usb/host/xhci-hub.c   |  15 ++-
 drivers/usb/host/xhci.c   |  10 ++
 drivers/usb/musb/musb_core.c  |  10 +-
 drivers/usb/serial/option.c   |  11 ++
 drivers/usb/serial/ti_usb_3410_5052.c |   2 +
 drivers/usb/serial/ti_usb_3410_5052.h |   4 +
 drivers/xen/gntdev.c  |   2 +-
 fs/btrfs/file.c   |  11 +-
 fs/cachefiles/rdwr.c  |   2 +-
 fs/fat/dir.c  |  16 ++-
 fs/nfs/inode.c|   6 +-
 fs/nfs/nfs4client.c   |   2 +-
 fs/splice.c   |   8 ++
 fs/sysv/inode.c   |  10 +-
 include/linux/blkdev.h|   1 -
 include/linux/signal.h|   1 -
 include/net/af_unix.h |   1 +
 include/target/target_core_base.h |   2 +-
 kernel/sched/core.c   |   7 +-
 kernel/signal.c   |   2 +-
 kernel/trace/ring_buffer.c|  12 +-
 net/core/neighbour.c  |   4 +-
 net/ipv4/tcp_ipv4.c   |   3 +-
 net/ipv6/ip6mr.c  |  15 +--
 net/mac80211/mesh_pathtbl.c   |   8 +-
 net/packet/af_packet.c|  60 +-
 net/rds/connection.c  |   6 -
 net/rds/send.c|   4 +-
 net/sctp/auth.c   |   4 +-
 net/unix/af_unix.c| 183 ++
 

Re: [3.13.y-ckt stable] Linux 3.13.11-ckt32

[Kamal Mostafa]

diff --git a/Makefile b/Makefile
index 7606094..4267a0d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 3
 PATCHLEVEL = 13
 SUBLEVEL = 11
-EXTRAVERSION = -ckt31
+EXTRAVERSION = -ckt32
 NAME = King of Alienated Frog Porn
 
 # *DOCUMENTATION*
@@ -597,10 +597,24 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
 
-# Force gcc to behave correct even for buggy distributions
-ifndef CONFIG_CC_STACKPROTECTOR
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
+# Handle stack protector mode.
+ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
+  stackp-flag := -fstack-protector
+  ifeq ($(call cc-option, $(stackp-flag)),)
+$(warning Cannot use CONFIG_CC_STACKPROTECTOR: \
+ -fstack-protector not supported by compiler))
+  endif
+else ifdef CONFIG_CC_STACKPROTECTOR_STRONG
+  stackp-flag := -fstack-protector-strong
+  ifeq ($(call cc-option, $(stackp-flag)),)
+$(warning Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: \
+ -fstack-protector-strong not supported by compiler)
+  endif
+else
+  # Force off for distro compilers that enable stack protector by default.
+  stackp-flag := $(call cc-option, -fno-stack-protector)
 endif
+KBUILD_CFLAGS += $(stackp-flag)
 
 # This warning generated too much noise in a regular build.
 # Use make W=1 to enable this warning (see scripts/Makefile.build)
diff --git a/arch/Kconfig b/arch/Kconfig
index f1cf895..80bbb8c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -336,6 +336,73 @@ config SECCOMP_FILTER
 
  See Documentation/prctl/seccomp_filter.txt for details.
 
+config HAVE_CC_STACKPROTECTOR
+   bool
+   help
+ An arch should select this symbol if:
+ - its compiler supports the -fstack-protector option
+ - it has implemented a stack canary (e.g. __stack_chk_guard)
+
+config CC_STACKPROTECTOR
+   def_bool n
+   help
+ Set when a stack-protector mode is enabled, so that the build
+ can enable kernel-side support for the GCC feature.
+
+choice
+   prompt "Stack Protector buffer overflow detection"
+   depends on HAVE_CC_STACKPROTECTOR
+   default CC_STACKPROTECTOR_NONE
+   help
+ This option turns on the "stack-protector" GCC feature. This
+ feature puts, at the beginning of functions, a canary value on
+ the stack just before the return address, and validates
+ the value just before actually returning.  Stack based buffer
+ overflows (that need to overwrite this return address) now also
+ overwrite the canary, which gets detected and the attack is then
+ neutralized via a kernel panic.
+
+config CC_STACKPROTECTOR_NONE
+   bool "None"
+   help
+ Disable "stack-protector" GCC feature.
+
+config CC_STACKPROTECTOR_REGULAR
+   bool "Regular"
+   select CC_STACKPROTECTOR
+   help
+ Functions will have the stack-protector canary logic added if they
+ have an 8-byte or larger character array on the stack.
+
+ This feature requires gcc version 4.2 or above, or a distribution
+ gcc with the feature backported ("-fstack-protector").
+
+ On an x86 "defconfig" build, this feature adds canary checks to
+ about 3% of all kernel functions, which increases kernel code size
+ by about 0.3%.
+
+config CC_STACKPROTECTOR_STRONG
+   bool "Strong"
+   select CC_STACKPROTECTOR
+   help
+ Functions will have the stack-protector canary logic added in any
+ of the following conditions:
+
+ - local variable's address used as part of the right hand side of an
+   assignment or function argument
+ - local variable is an array (or union containing an array),
+   regardless of array type or length
+ - uses register local variables
+
+ This feature requires gcc version 4.9 or above, or a distribution
+ gcc with the feature backported ("-fstack-protector-strong").
+
+ On an x86 "defconfig" build, this feature adds canary checks to
+ about 20% of all kernel functions, which increases the kernel code
+ size by about 2%.
+
+endchoice
+
 config HAVE_CONTEXT_TRACKING
bool
help
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index e550b11..2d6a36e 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -986,42 +986,13 @@ int arc_unwind(struct unwind_frame_info *frame)
(const u8 *)(fde +
 1) +
*fde, ptrType);
-   if (pc >= endLoc)
+   if (pc >= endLoc) {
fde = NULL;
-   } else
-   fde = NULL;
-   }
-  

Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y

[Stefano Stabellini]

On Wed, 16 Dec 2015, Tomasz Nowicki wrote:
> In drivers/xen/pci.c, there are arch x86 dependent codes when
> CONFIG_PCI_MMCONFIG is enabled, since CONFIG_PCI_MMCONFIG
> depends on ACPI, so this will prevent XEN PCI running on other
> architectures using ACPI with PCI_MMCONFIG enabled (such as ARM64).
> 
> Fortunatly, it can be sloved in a simple way. In drivers/xen/pci.c,
> the only x86 dependent code is if ((pci_probe & PCI_PROBE_MMCONF) == 0),
> and it's defined in asm/pci_x86.h, the code means that
> if the PCI resource is not probed in PCI_PROBE_MMCONF way, just
> ingnore the xen mcfg init. Actually this is duplicate, because
> if PCI resource is not probed in PCI_PROBE_MMCONF way, the
> pci_mmconfig_list will be empty, and the if (list_empty())
> after it will do the same job.
> 
> So just remove the arch related code and the head file, this
> will be no functional change for x86, and also makes xen/pci.c
> usable for other architectures.
> 
> Signed-off-by: Hanjun Guo 
> CC: Konrad Rzeszutek Wilk 
> CC: Boris Ostrovsky 
> Cc: Stefano Stabellini 
> Tested-by: Suravee Suthikulpanit 

Acked-by: Stefano Stabellini 


>  drivers/xen/pci.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 6785ebb..9a8dbe3 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -28,9 +28,6 @@
>  #include 
>  #include 
>  #include "../pci/pci.h"
> -#ifdef CONFIG_PCI_MMCONFIG
> -#include 
> -#endif
>  
>  static bool __read_mostly pci_seg_supported = true;
>  
> @@ -222,9 +219,6 @@ static int __init xen_mcfg_late(void)
>   if (!xen_initial_domain())
>   return 0;
>  
> - if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> - return 0;
> -
>   if (list_empty(_mmcfg_list))
>   return 0;
>  
> -- 
> 1.9.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 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård  wrote:
>> Andy Shevchenko  writes:
>>
>>> +Viresh
>>>
>>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård  wrote:
 Andy Shevchenko  writes:

> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård  wrote:
>> Julian Margetson  writes:
>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
 Julian Margetson  writes:
>
>>> [   48.769671] ata3.00: failed command: READ FPDMA QUEUED
>>
>> Well, that didn't help.  I still think it's part of the problem, but
>> something else must be wrong as well.  The various Master Select fields
>> look like a good place to start.
>
> Master number (which is here would be either 1 or 0) should not affect
> as long as they are connected to the same AHB bus (I would be
> surprised if they are not).

 I think they are not.  The relevant part of the block diagram for the
 460EX looks something like this:

   +-+
   | CPU |
   +-+
  |
  +---+
  |  BUS  |
  +---+
 | |
  +-+   +-+
  | DMA |   | RAM |
  +-+   +-+
 |
  +--+
  | SATA |
  +--+

 The DMA-SATA link is private and ignores the address, which is the only
 reason the driver can possibly work (it's programming a CPU virtual
 address there).
>>>
>>> If you look at the original code the SMS and DMS are programmed
>>> statically independent on DMA direction, so LLP is programmed always
>>> to master 1. I don't think your scheme is reflecting this right. I
>>> could imagine two AHB buses, one of them connects CPU, SATA and RAM,
>>> and the other CPU and DMA.
>>
>> Check the code again.  The original code swaps SMS and DMS depending on
>> direction, and it sets LMS to 1.  Put differently, it always sets the
>> memory side 1 and the device side to 0.  The dw_dma driver sets SMS and
>> DMS to the src/dst_master values provided through dma_request_channel()
>> regardless of the current direction and LMS always zero.
>
> I used to have a patch to implement this in dw_dmac driver. However, I
> dropped it at some point. Seems we need it back and now I possible
> have a good explanation why.

Are you still able to find that patch?  Shouldn't be too hard to do from
scratch if not.

>> If those values didn't matter, why would the fields exist in the
>> first place?
>
> Because someone can have more than one AHB bus on the system and
> connect DMA to all of them (up to 4).

Which apparently these guys did.  Well, not a full-blown AHB bus, but
they seem to be using two master interfaces.

>>> In any case on all Intel SoCs and AVR32, and as far as I can tell on
>>> Spear13xx (Viresh?) there is not a case, that's why I hardly imagine
>>> that the problem is in master numbers by themselves.
>>
>> The 460EX is a PowerPC system.  Expect unusual topologies.
>
> Yeah, that's right.

BTW, there's a good reason for wiring it like this.  If the source and
destination are on different buses, the DMA engine can do a read and a
write in each cycle.  Otherwise the reads and writes have to be issued
alternately.

>> Also, the manual says the LLP_SRC_EN
>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks.
>> The old sata_dwc driver does this whereas dw_dma does not.
>
> Easy to fix, however I can't get how it might affect.

 From the Atmel doc:

   In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0,
   CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are
   illegal, and causes indeterminate or erroneous behavior.
>>>
>>> I will check Synospys documentation later on.
>
> Yes, we have to clear those bits. I will do a patch or you already have one?

I'll send the patch soon.

 Most likely nothing happens, but I think it ought to be fixed.  In fact,
 I have a patch already.
>>>
>>> Good. Send with Fixes tag if it's upstream ready.
>>>
 Come to think of it, I have an AVR32 dev somewhere.  Maybe I should dust
 it off.
>>>
>>> I have ATNGW100.
>>
>> I have an AT32ATK1006.  Can you suggest a good test to exercise the DMA
>> engine?
>
> On that board I tried MMC (the only available user for me), though it
> is not reliable, I also tried the dmatest module.

Hmm, is there anywhere this damn driver actually works?  ;-)

-- 
Måns Rullgård
--
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 v6 1/3] tty: Move serial8250_stop_rx in front of serial8250_start_tx

[Matwey V. Kornilov]

Software RS485 emultaion is to be added in the following commit.
serial8250_start_tx will need to refer serial8250_stop_rx.
Move serial8250_stop_rx in front of serial8250_start_tx in order
to avoid function forward declaration.

Signed-off-by: Matwey V. Kornilov 
---
 drivers/tty/serial/8250/8250_port.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 0bbf340..8ad0b2d 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1280,6 +1280,19 @@ static void autoconfig_irq(struct uart_8250_port *up)
port->irq = (irq > 0) ? irq : 0;
 }
 
+static void serial8250_stop_rx(struct uart_port *port)
+{
+   struct uart_8250_port *up = up_to_u8250p(port);
+
+   serial8250_rpm_get(up);
+
+   up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
+   up->port.read_status_mask &= ~UART_LSR_DR;
+   serial_port_out(port, UART_IER, up->ier);
+
+   serial8250_rpm_put(up);
+}
+
 static inline void __stop_tx(struct uart_8250_port *p)
 {
if (p->ier & UART_IER_THRI) {
@@ -1347,19 +1360,6 @@ static void serial8250_unthrottle(struct uart_port *port)
port->unthrottle(port);
 }
 
-static void serial8250_stop_rx(struct uart_port *port)
-{
-   struct uart_8250_port *up = up_to_u8250p(port);
-
-   serial8250_rpm_get(up);
-
-   up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
-   up->port.read_status_mask &= ~UART_LSR_DR;
-   serial_port_out(port, UART_IER, up->ier);
-
-   serial8250_rpm_put(up);
-}
-
 static void serial8250_disable_ms(struct uart_port *port)
 {
struct uart_8250_port *up =
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 18:58:51 +0100

A few checks would be performed by the mgc_process_recover_log() function
even though it was determined that the passed variable "pages" contained
a null pointer or a call of the alloc_page() function failed.

1. Let us return directly if a call of the kcalloc() function failed.

2. Corresponding implementation details could be improved by adjustments
   for jump targets according to the Linux coding style convention.

3. Delete sanity checks then.

4. Move an assignment for the variable "eof" behind memory allocations.

5. The variable "req" will eventually be set to an appropriate pointer
   from a call of the ptlrpc_request_alloc() function.
   Thus let us omit the explicit initialisation before.

6. Apply a recommendation from the script "checkpatch.pl".

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/mgc/mgc_request.c | 51 +++--
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index da130f4..5f581df 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device 
*mgc,
 static int mgc_process_recover_log(struct obd_device *obd,
   struct config_llog_data *cld)
 {
-   struct ptlrpc_request *req = NULL;
+   struct ptlrpc_request *req;
struct config_llog_instance *cfg = >cld_cfg;
struct mgs_config_body *body;
struct mgs_config_res  *res;
struct ptlrpc_bulk_desc *desc;
struct page **pages;
int nrpages;
-   bool eof = true;
+   bool eof;
bool mne_swab;
int i;
int ealen;
@@ -1309,19 +1309,18 @@ static int mgc_process_recover_log(struct obd_device 
*obd,
nrpages = CONFIG_READ_NRPAGES_INIT;
 
pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL);
-   if (pages == NULL) {
-   rc = -ENOMEM;
-   goto out;
-   }
+   if (!pages)
+   return -ENOMEM;
 
for (i = 0; i < nrpages; i++) {
pages[i] = alloc_page(GFP_KERNEL);
if (pages[i] == NULL) {
rc = -ENOMEM;
-   goto out;
+   goto free_pages;
}
}
 
+   eof = true;
 again:
LASSERT(cld_is_recover(cld));
LASSERT(mutex_is_locked(>cld_lock));
@@ -1329,12 +1328,12 @@ again:
   _MGS_CONFIG_READ);
if (req == NULL) {
rc = -ENOMEM;
-   goto out;
+   goto free_pages;
}
 
rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ);
if (rc)
-   goto out;
+   goto finish_request;
 
/* pack request */
body = req_capsule_client_get(>rq_pill, _MGS_CONFIG_BODY);
@@ -1343,7 +1342,7 @@ again:
if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name))
>= sizeof(body->mcb_name)) {
rc = -E2BIG;
-   goto out;
+   goto finish_request;
}
body->mcb_offset = cfg->cfg_last_idx + 1;
body->mcb_type   = cld->cld_type;
@@ -1355,7 +1354,7 @@ again:
MGS_BULK_PORTAL);
if (desc == NULL) {
rc = -ENOMEM;
-   goto out;
+   goto finish_request;
}
 
for (i = 0; i < nrpages; i++)
@@ -1364,12 +1363,12 @@ again:
ptlrpc_request_set_replen(req);
rc = ptlrpc_queue_wait(req);
if (rc)
-   goto out;
+   goto finish_request;
 
res = req_capsule_server_get(>rq_pill, _MGS_CONFIG_RES);
if (res->mcr_size < res->mcr_offset) {
rc = -EINVAL;
-   goto out;
+   goto finish_request;
}
 
/* always update the index even though it might have errors with
@@ -1383,18 +1382,18 @@ again:
ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0);
if (ealen < 0) {
rc = ealen;
-   goto out;
+   goto finish_request;
}
 
if (ealen > nrpages << PAGE_CACHE_SHIFT) {
rc = -EINVAL;
-   goto out;
+   goto finish_request;
}
 
if (ealen == 0) { /* no logs transferred */
if (!eof)
rc = -EINVAL;
-   goto out;
+   goto finish_request;
}
 
mne_swab = !!ptlrpc_rep_need_swab(req);
@@ -1424,22 +1423,18 @@ again:
 
ealen -= PAGE_CACHE_SIZE;
}
-
-out:
-   if (req)
-   ptlrpc_req_finished(req);
+finish_request:
+   

Re: [PATCH] ath6kl: Use vmalloc to allocate ar->fw for api1 method

[Souptick Joarder]

Hi Brent,

On Tue, Dec 1, 2015 at 11:11 AM, Brent Taylor  wrote:
> Since commit 8437754c83351d6213c1a47ff029c1126d6042a7, ar->fw is expected to 
> be pointing to memory allocated by vmalloc.  If the api1 method (via 
> ath6kl_fetch_fw_api1) is used to allocate memory for ar->fw, then kmemdup is 
> used.  This patch checks if the firmware being loaded is the 'fw' image, then 
> use vmalloc, otherwise use kmalloc.
>
> Signed-off-by: Brent Taylor 
> ---
>  drivers/net/wireless/ath/ath6kl/init.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/init.c 
> b/drivers/net/wireless/ath/ath6kl/init.c
> index 6ae0734..4f2b124d 100644
> --- a/drivers/net/wireless/ath/ath6kl/init.c
> +++ b/drivers/net/wireless/ath/ath6kl/init.c
> @@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const char 
> *filename,
> return ret;
>
> *fw_len = fw_entry->size;
> -   *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> +   if (>fw == fw)
> +   *fw = vmalloc(fw_entry->size);
> +   else
> +   *fw = kmalloc(fw_entry->size, GFP_KERNEL);

  Why vmalloc and kmalloc both are required? can't use either
vmalloc or kmalloc?
>
> if (*fw == NULL)
> ret = -ENOMEM;
> +   else
> +   memcpy(*fw, fw_entry->data, fw_entry->size);
>
> release_firmware(fw_entry);
>
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-Souptick
--
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: IO errors after "block: remove bio_get_nr_vecs()"

[Tejun Heo]

Hello, Artem.

On Mon, Dec 21, 2015 at 12:25:06PM +0500, Artem S. Tashkinov wrote:
> I've applied this patch on top of vanilla 4.3.3 kernel (without Linus'es
> revert). Hopefully it's how you intended it to be.
> 
> Here's the result (I skipped the beginning of dmesg - it's the same as
> always - see bugzilla).

I added some debug messages during init.  It isn't critical but it'd
be great if you attach the full log from now on.  Something seemingly
unrelated surprisingly often turns out to be an important clue.

> [   60.387407] Corrupted low memory at c0001000 (1000 phys) = cba3d25f
...
> [   60.389131] Corrupted low memory at c0001ffc (1ffc phys) = 2712322a

It looks like the controller shat on the entire second page, which is
really puzzling.  Looks like the controller is being fed corrupt DMA
SG table.

...
> [   74.367608] ata1.00: exception Emask 0x3 SAct 0x18 SErr 0x3040400 
> action 0x6 frozen
> [   74.367613] ata1.00: irq_stat 0x4508

The intresting bit here is that the controller is indicating OVERFLOW
which means that it consumed all PRD entries (ahci's DMA SG table) for
the command but the disk is still sending data to the host.

> [   74.367617] ata1: SError: { Proto CommWake TrStaTrns UnrecFIS }
> [   74.367621] ata1.00: failed command: READ FPDMA QUEUED
> [   74.367627] ata1.00: cmd 60/00:98:00:89:21/07:00:04:00:00/40 tag 19 ncq 
> 917504 in
> [   74.367627]  res 40/00:98:00:89:21/00:00:04:00:00/40 Emask 0x3 
> (HSM violation)
> [   74.367630] ata1.00: status: { DRDY }

The followings are the data fed to the controller as seen from the
CPU.

> [   74.367632] XXX cmd=ee9e0260 cmd_tbl=ee9ed600 ahci_sg=ee9ed680
> [   74.367634] XXX opts=140005 st=0 addr=2e9ed600 addr_hi=0 rsvd=0:0:0:0
> [   74.367637] XXX fis=00608027:40218900:0704:0898 
> :::1fff
> [   74.367639] XXX qc->n_elem=20 fis_len=5 prdtl=20
> [   74.367641] XXX sg[0] = 29007000 0 8fff (36864)
> [   74.367643] XXX sg[1] = 29218000 0 7fff (32768)
> [   74.367645] XXX sg[2] = 29298000 0 7fff (32768)
> [   74.367646] XXX sg[3] = 29ad8000 0 7fff (32768)
> [   74.367648] XXX sg[4] = 29338000 0 7fff (32768)
> [   74.367650] XXX sg[5] = 2937 0 2fff (12288)
> [   74.367652] XXX sg[6] = 219000 0 2fff (12288)
> [   74.367653] XXX sg[7] = 23 0 3fff (16384)
> [   74.367655] XXX sg[8] = 29373000 0 4fff (20480)
> [   74.367657] XXX sg[9] = 2913 0  (65536)
> [   74.367659] XXX sg[10] = 2917 0  (65536)
> [   74.367660] XXX sg[11] = 2928 0  (65536)
> [   74.367662] XXX sg[12] = 2920 0  (65536)
> [   74.367664] XXX sg[13] = 2932 0  (65536)
> [   74.367666] XXX sg[14] = 2936 0  (65536)
> [   74.367667] XXX sg[15] = 2934 0  (65536)
> [   74.367669] XXX sg[16] = 2935 0  (65536)
> [   74.367671] XXX sg[17] = 2930 0  (65536)
> [   74.367672] XXX sg[18] = 2931 0  (65536)
> [   74.367674] XXX sg[19] = 2902 0 7fff (32768)

And everything checks out.  Data lenghts are consistent and all the
addresses look kosher - at least nothing should upset the data
transfer itself.

> [   74.367677] ata1.00: failed command: READ FPDMA QUEUED
> [   74.367682] ata1.00: cmd 60/90:a0:c0:fe:23/00:00:04:00:00/40 tag 20 ncq 
> 73728 in
> [   74.367682]  res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x7 
> (timeout)

This one looks like a collateral damage.

...
> [   74.763895] ata1.00: exception Emask 0x3 SAct 0x80 SErr 0x3040400 
> action 0x6
> [   74.763900] ata1.00: irq_stat 0x4508
> [   74.763903] ata1: SError: { Proto CommWake TrStaTrns UnrecFIS }
> [   74.763907] ata1.00: failed command: READ FPDMA QUEUED
> [   74.763913] ata1.00: cmd 60/98:b8:00:c9:20/03:00:04:00:00/40 tag 23 ncq 
> 471040 in
> [   74.763913]  res 40/00:b8:00:c9:20/00:00:04:00:00/40 Emask 0x3 
> (HSM violation)
> [   74.763916] ata1.00: status: { DRDY }
> [   74.763918] XXX cmd=ee9e02e0 cmd_tbl=ee9f0200 ahci_sg=ee9f0280
> [   74.763921] XXX opts=160005 st=0 addr=2e9f0200 addr_hi=0 rsvd=0:0:0:0
> [   74.763924] XXX fis=98608027:4020c900:0304:08b8 
> :::0fff
> [   74.763925] XXX qc->n_elem=22 fis_len=5 prdtl=22
> [   74.763928] XXX sg[0] = 2ab1b000 0 fff (4096)
...
> [   74.763964] XXX sg[21] = 2917 0 dfff (57344)

This is a separate failure and shares the same pattern as before.
Everything looks proper.

The thing is ahci doesn't have much restrictions in terms of its DMA
capabilities.  It can digest pretty much anything.  The only
restriction is that each entry can't be larger than 4M - but our
segment maximum is 64k.  There's no noticeable boundary crossing
happening both in target DMA regions and command tables.  All
addresses are in linear mapped normal area.

If the controller is seeing what the host is seeing in the command
area, I can't see why it would be declaring overflow or dumping stuff
into the lowest pages.

Ming Lei reported a similar issue on 32bit ARM w/ PAE.  I don't
understand why PAE 

Re: [PATCH] dmaengine: dw: clear LLP_[SD]_EN bits in last descriptor of a chain

[Andy Shevchenko]

On Mon, 2015-12-21 at 19:10 +, Mans Rullgard wrote:
> The datasheet requires that the LLP_[SD]_EN bits be cleared whenever
> LLP.LOC is zero, i.e. in the last descriptor of a multi-block chain.
> Make the driver do this.

Acked-by: Andy Shevchenko 

> 
> Signed-off-by: Mans Rullgard 
> ---
>  drivers/dma/dw/core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index 7067b6ddc1db..ca7cafc82f6b 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -751,6 +751,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan,
> dma_addr_t dest, dma_addr_t src,
>   prev->lli.ctllo |= DWC_CTLL_INT_EN;
>  
>   prev->lli.llp = 0;
> + prev->lli.ctllo &= ~(DWC_CTLL_LLP_D_EN | DWC_CTLL_LLP_S_EN);
>   first->txd.flags = flags;
>   first->total_len = len;
>  
> @@ -912,6 +913,7 @@ slave_sg_fromdev_fill_desc:
>   prev->lli.ctllo |= DWC_CTLL_INT_EN;
>  
>   prev->lli.llp = 0;
> + prev->lli.ctllo &= ~(DWC_CTLL_LLP_D_EN | DWC_CTLL_LLP_S_EN);
>   first->total_len = total_len;
>  
>   return >txd;

-- 
Andy Shevchenko 
Intel Finland Oy

--
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 2/2] add new platform driver for PCI RC

[kbuild test robot]

Hi Joao,

[auto build test ERROR on arc/for-next]
[also build test ERROR on v4.4-rc6 next-20151221]

url:
https://github.com/0day-ci/linux/commits/Joao-Pinto/adding-PCI-support-to-AXS10x/20151221-234734
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc for-next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/pci/host/pcie-designware.c: In function 'dw_pcie_host_init':
>> drivers/pci/host/pcie-designware.c:556:7: error: implicit declaration of 
>> function 'pci_has_flag' [-Werror=implicit-function-declaration]
 if (!pci_has_flag(PCI_PROBE_ONLY)) {
  ^
>> drivers/pci/host/pcie-designware.c:556:20: error: 'PCI_PROBE_ONLY' 
>> undeclared (first use in this function)
 if (!pci_has_flag(PCI_PROBE_ONLY)) {
   ^
   drivers/pci/host/pcie-designware.c:556:20: note: each undeclared identifier 
is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/pci_has_flag +556 drivers/pci/host/pcie-designware.c

cbce7900 Zhou Wang   2015-10-29  550  
cbce7900 Zhou Wang   2015-10-29  551  #ifdef CONFIG_ARM
cbce7900 Zhou Wang   2015-10-29  552/* support old dtbs that incorrectly 
describe IRQs */
cbce7900 Zhou Wang   2015-10-29  553pci_fixup_irqs(pci_common_swizzle, 
of_irq_parse_and_map_pci);
0815f957 Yijing Wang 2014-11-11  554  #endif
0815f957 Yijing Wang 2014-11-11  555  
cbce7900 Zhou Wang   2015-10-29 @556if (!pci_has_flag(PCI_PROBE_ONLY)) {
cbce7900 Zhou Wang   2015-10-29  557pci_bus_size_bridges(bus);
cbce7900 Zhou Wang   2015-10-29  558pci_bus_assign_resources(bus);
4b1ced84 Jingoo Han  2013-07-31  559  

:: The code at line 556 was first introduced by commit
:: cbce7900598c26a12652f8ca9c41c5b29034c38d PCI: designware: Make driver 
arch-agnostic

:: TO: Zhou Wang <wangzh...@hisilicon.com>
:: CC: Bjorn Helgaas <bhelg...@google.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] x86/mm: Drop WARN from multi-BAR check

[Laura Abbott]

ioremapping multiple BARs produces a warning with a message "Your kernel is
fine". This message mostly serves to comfort kernel developers. Users do
not read the message, they only see the big scary warning which means
something must be horribly broken with their system. Less dramatically, the
warn also sets the taint flag which makes it difficult to differentiate
problems. If the kernel is actually fine as the warning claims it doesn't
make sense for it to be tainted. Change the WARN_ONCE to a pr_warn with the
caller of the ioremap.

Signed-off-by: Laura Abbott 
---
 arch/x86/mm/ioremap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index b9c78f3..0d8d53d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -194,8 +194,8 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
 * Check if the request spans more than any BAR in the iomem resource
 * tree.
 */
-   WARN_ONCE(iomem_map_sanity_check(unaligned_phys_addr, unaligned_size),
- KERN_INFO "Info: mapping multiple BARs. Your kernel is 
fine.");
+   if (iomem_map_sanity_check(unaligned_phys_addr, unaligned_size))
+   pr_warn("caller %pS mapping multiple BARs\n", caller);
 
return ret_addr;
 err_free_area:
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] serial: 8250_ingenic: allow to be independent of SERIAL_8250_CONSOLE

[Paul Gortmaker]

On Tue, Oct 27, 2015 at 10:20 AM, Peter Hurley  wrote:
> On 10/23/2015 09:31 AM, Masahiro Yamada wrote:
>> This UART driver should not depend on the console.  They should be
>> orthogonal.
>>
>> Surround the earlycon code with CONFIG_SERIAL_EARLYCON conditional
>> and rip off "depends on SERIAL_8250_CONSOLE".

The recent merge of this patch to linux-next allows me to build this driver
for ARM, which in turn trips my local "bool Kconfig driver using modular
functions" test failure.

Any thoughts whether people care if this driver gets moved to tristate
vs. having the unused modular code ripped out?

Paul.
--

>
> Reviewed-by: Peter Hurley 
>
> PS - While reviewing this patch, I noticed another problem in the
> Ingenic earlycon; see below.
>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Currently, SERIAL_8250_FSL also depends on SERIAL_8250_CONSOLE,
>> but I doubt its necessity.
>>
>>
>>  drivers/tty/serial/8250/8250_ingenic.c | 2 ++
>>  drivers/tty/serial/8250/Kconfig| 2 +-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_ingenic.c 
>> b/drivers/tty/serial/8250/8250_ingenic.c
>> index 7c1e4be..44633ee 100644
>> --- a/drivers/tty/serial/8250/8250_ingenic.c
>> +++ b/drivers/tty/serial/8250/8250_ingenic.c
>> @@ -34,6 +34,7 @@ struct ingenic_uart_data {
>>
>>  #define UART_FCR_UME BIT(4)
>>
>> +#ifdef CONFIG_SERIAL_EARLYCON
>
>
>>  static struct earlycon_device *early_device;
>
> The earlycon setup should not be saving the earlycon_device *;
> see early_8250serial_write() for how to deref from console to port.
>
> Regards,
> Peter Hurley
>
>
>>  static uint8_t __init early_in(struct uart_port *port, int offset)
>> @@ -126,6 +127,7 @@ OF_EARLYCON_DECLARE(jz4775_uart, "ingenic,jz4775-uart",
>>  EARLYCON_DECLARE(jz4780_uart, ingenic_early_console_setup);
>>  OF_EARLYCON_DECLARE(jz4780_uart, "ingenic,jz4780-uart",
>>   ingenic_early_console_setup);
>> +#endif /* CONFIG_SERIAL_EARLYCON */
>>
>>  static void ingenic_uart_serial_out(struct uart_port *p, int offset, int 
>> value)
>>  {
>> diff --git a/drivers/tty/serial/8250/Kconfig 
>> b/drivers/tty/serial/8250/Kconfig
>> index 960da95..6f62934 100644
>> --- a/drivers/tty/serial/8250/Kconfig
>> +++ b/drivers/tty/serial/8250/Kconfig
>> @@ -360,7 +360,7 @@ config SERIAL_8250_UNIPHIER
>>
>>  config SERIAL_8250_INGENIC
>>   bool "Support for Ingenic SoC serial ports"
>> - depends on SERIAL_8250_CONSOLE && OF_FLATTREE
>> + depends on OF_FLATTREE
>>   select LIBFDT
>>   help
>> If you have a system using an Ingenic SoC and wish to make use of
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" 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: [PATCHV3 1/3] x86, ras: Add new infrastructure for machine check fixup tables

[Borislav Petkov]

On Mon, Dec 21, 2015 at 11:16:44AM -0800, Dan Williams wrote:
> I suggested we reverse the dependency and have the driver optionally
> "select MCE_KERNEL_RECOVERY".  There may be other drivers outside of
> LIBNVDIMM that want this functionality enabled.

Ah ok, makes sense.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Andy Shevchenko]

On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote:
> On 12/21/2015 2:27 PM, Måns Rullgård wrote:
> > The hard drive is recognized .
> > > These system gets unresponsive with USB devices like the mouse
> > > and
> > > keyboard not responding  when I start Gparted.
> > Did you disable the SATA and DMA debug messages?
> > 
> It is working.

Indeed, thanks, Julian!

I might ask you to test my branch with set of patches when it will be
ready (apparently after Xmas) if you are okay with that.

Måns, also I would ask you to test on your hardware (AVR32) as well if
you have no objections.

-- 
Andy Shevchenko 
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] um: Add full asm/syscall.h support

[Mickaël Salaün]

Add subarchitecture-independent implementation of asm-generic/syscall.h
allowing access to user system call parameters and results:
* syscall_get_nr()
* syscall_rollback()
* syscall_get_error()
* syscall_get_return_value()
* syscall_set_return_value()
* syscall_get_arguments()
* syscall_set_arguments()
* syscall_get_arch() provided by arch/x86/um/asm/syscall.h

This provides the necessary syscall helpers needed by
HAVE_ARCH_SECCOMP_FILTER plus syscall_get_error().

This is inspired from Meredydd Luff's patch
(https://gerrit.chromium.org/gerrit/21425).

Signed-off-by: Mickaël Salaün 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Andy Lutomirski 
Cc: Will Drewry 
Cc: Meredydd Luff 
Cc: David Drysdale 
---
 arch/um/include/asm/syscall-generic.h | 138 ++
 arch/x86/um/asm/syscall.h |   1 +
 2 files changed, 139 insertions(+)
 create mode 100644 arch/um/include/asm/syscall-generic.h

diff --git a/arch/um/include/asm/syscall-generic.h 
b/arch/um/include/asm/syscall-generic.h
new file mode 100644
index 000..9fb9cf8
--- /dev/null
+++ b/arch/um/include/asm/syscall-generic.h
@@ -0,0 +1,138 @@
+/*
+ * Access to user system call parameters and results
+ *
+ * See asm-generic/syscall.h for function descriptions.
+ *
+ * Copyright (C) 2015 Mickaël Salaün 
+ *
+ * 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.
+ */
+
+#ifndef __UM_SYSCALL_GENERIC_H
+#define __UM_SYSCALL_GENERIC_H
+
+#include 
+#include 
+#include 
+#include 
+
+static inline int syscall_get_nr(struct task_struct *task, struct pt_regs 
*regs)
+{
+
+   return PT_REGS_SYSCALL_NR(regs);
+}
+
+static inline void syscall_rollback(struct task_struct *task,
+   struct pt_regs *regs)
+{
+   /* do nothing */
+}
+
+static inline long syscall_get_error(struct task_struct *task,
+struct pt_regs *regs)
+{
+   const long error = regs_return_value(regs);
+
+   return IS_ERR_VALUE(error) ? error : 0;
+}
+
+static inline long syscall_get_return_value(struct task_struct *task,
+   struct pt_regs *regs)
+{
+   return regs_return_value(regs);
+}
+
+static inline void syscall_set_return_value(struct task_struct *task,
+   struct pt_regs *regs,
+   int error, long val)
+{
+   PT_REGS_SET_SYSCALL_RETURN(regs, (long) error ?: val);
+}
+
+static inline void syscall_get_arguments(struct task_struct *task,
+struct pt_regs *regs,
+unsigned int i, unsigned int n,
+unsigned long *args)
+{
+   const struct uml_pt_regs *r = >regs;
+
+   switch (i) {
+   case 0:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG1(r);
+   case 1:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG2(r);
+   case 2:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG3(r);
+   case 3:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG4(r);
+   case 4:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG5(r);
+   case 5:
+   if (!n--)
+   break;
+   *args++ = UPT_SYSCALL_ARG6(r);
+   case 6:
+   if (!n--)
+   break;
+   default:
+   BUG();
+   break;
+   }
+}
+
+static inline void syscall_set_arguments(struct task_struct *task,
+struct pt_regs *regs,
+unsigned int i, unsigned int n,
+const unsigned long *args)
+{
+   struct uml_pt_regs *r = >regs;
+
+   switch (i) {
+   case 0:
+   if (!n--)
+   break;
+   UPT_SYSCALL_ARG1(r) = *args++;
+   case 1:
+   if (!n--)
+   break;
+   UPT_SYSCALL_ARG2(r) = *args++;
+   case 2:
+   if (!n--)
+   break;
+   UPT_SYSCALL_ARG3(r) = *args++;
+   case 3:
+   if (!n--)
+   break;
+   UPT_SYSCALL_ARG4(r) = *args++;
+   case 4:
+   if (!n--)
+   

Re: [PATCH v5 08/17] x86/entry: Add enter_from_user_mode and use it in syscalls

[Sasha Levin]

On 07/03/2015 03:44 PM, Andy Lutomirski wrote:
> Changing the x86 context tracking hooks is dangerous because there
> are no good checks that we track our context correctly.  Add a
> helper to check that we're actually in CONTEXT_USER when we enter
> from user mode and wire it up for syscall entries.
> 
> Subsequent patches will wire this up for all non-NMI entries as
> well.  NMIs are their own special beast and cannot currently switch
> overall context tracking state.  Instead, they have their own
> special RCU hooks.
> 
> This is a tiny speedup if !CONFIG_CONTEXT_TRACKING (removes a
> branch) and a tiny slowdown if CONFIG_CONTEXT_TRACING (adds a layer
> of indirection).  Eventually, we should fix up the core context
> tracking code to supply a function that does what we want (and can
> be much simpler than user_exit), which will enable us to get rid of
> the extra call.

Hey Andy,

I see the following warning in today's -next:

[ 2162.706868] [ cut here ]
[ 2162.708021] WARNING: CPU: 4 PID: 28801 at arch/x86/entry/common.c:44 
enter_from_user_mode+0x1c/0x50()
[ 2162.709466] Modules linked in:
[ 2162.709998] CPU: 4 PID: 28801 Comm: trinity-c375 Tainted: GB   
4.4.0-rc5-next-20151221-sasha-00020-g840272e-dirty #2753
[ 2162.711847]   f17e6fcd 880292d5fe08 
a4045334
[ 2162.713108]  41b58ab3 af66686b a4045289 
880292d5fdc0
[ 2162.714544]   f17e6fcd a23cf466 
0004
[ 2162.715793] Call Trace:
[ 2162.716229] dump_stack (lib/dump_stack.c:52)
[ 2162.719021] warn_slowpath_common (kernel/panic.c:484)
[ 2162.721014] warn_slowpath_null (kernel/panic.c:518)
[ 2162.721950] enter_from_user_mode (arch/x86/entry/common.c:44 (discriminator 
7) include/linux/context_tracking_state.h:30 (discriminator 7) 
include/linux/context_tracking.h:30 (discriminator 7) 
arch/x86/entry/common.c:45 (discriminator 7))
[ 2162.722911] syscall_trace_enter_phase1 (arch/x86/entry/common.c:94)
[ 2162.726914] tracesys (arch/x86/entry/entry_64.S:241)
[ 2162.727704] ---[ end trace 1e5b49c361cbfe8b ]---
[ 2162.728468] BUG: scheduling while atomic: trinity-c375/28801/0x0401
[ 2162.729517] Modules linked in:
[ 2162.730020] Preemption disabled param_attr_store (kernel/params.c:625)
[ 2162.731304]
[ 2162.731579] CPU: 4 PID: 28801 Comm: trinity-c375 Tainted: GB   W   
4.4.0-rc5-next-20151221-sasha-00020-g840272e-dirty #2753
[ 2162.733432]   f17e6fcd 880292d5fe20 
a4045334
[ 2162.734778]  41b58ab3 af66686b a4045289 
880292d5fde0
[ 2162.736036]  ace198f9 f17e6fcd 880292d5fe50 
0282
[ 2162.737309] Call Trace:
[ 2162.737718] dump_stack (lib/dump_stack.c:52)
[ 2162.740566] __schedule_bug (kernel/sched/core.c:3102)
[ 2162.741498] __schedule (./arch/x86/include/asm/preempt.h:27 
kernel/sched/core.c:3116 kernel/sched/core.c:3225)
[ 2162.742391] schedule (kernel/sched/core.c:3312 (discriminator 1))
[ 2162.743221] exit_to_usermode_loop (arch/x86/entry/common.c:246)
[ 2162.744331] syscall_return_slowpath (arch/x86/entry/common.c:282 
include/linux/context_tracking_state.h:30 include/linux/context_tracking.h:24 
arch/x86/entry/common.c:284 arch/x86/entry/common.c:344)
[ 2162.745364] int_ret_from_sys_call (arch/x86/entry/entry_64.S:282)


Thanks,
Sasha
--
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 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 21 December 2015 at 18:11, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 4:49 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++---
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c 
>> b/drivers/tty/serial/amba-pl011.c
>> index 899a771..766ce4f 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, 
>> const struct amba_id *id)
>> if (!uap)
>> return -ENOMEM;
>>
>> -   uap->clk = devm_clk_get(>dev, NULL);
>> -   if (IS_ERR(uap->clk))
>> -   return PTR_ERR(uap->clk);
>> -
>> -   uap->vendor = vendor;
>> -   uap->lcrh_rx = vendor->lcrh_rx;
>> -   uap->lcrh_tx = vendor->lcrh_tx;
>> -   uap->fifosize = vendor->get_fifosize(dev);
>> -   uap->port.irq = dev->irq[0];
>> -   uap->port.ops = _pl011_pops;
>> +   /* ACPI only defines SBSA variant */
>> +   if (ACPI_COMPANION(>dev)) {
>
> has_acpi_companion()
>
>> +   /*
>> +* According to ARM ARMH0011 is currently the only mapping
>> +* of pl011 in ACPI and it's mapped to SBSA UART mode
>> +*/
>> +   uap->vendor = _sbsa;
>> +   uap->fifosize   = 32;
>> +   uap->port.ops   = _uart_pops;
>> +   uap->fixed_baud = 115200;
>
> Shouldn't you match by ID and provide the custom values if any?
> On the other hand have you checked if it's possible to use _DSD in this case?
>
So far I have not seen any use of SBSA UART other than this in real
life. I am a little opposed to providing complexity people are not
going to use.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] Drivers: hv: vmbus: Cleanup vmbus_set_event()

[Greg KH]

On Tue, Dec 15, 2015 at 04:27:28PM -0800, K. Y. Srinivasan wrote:
> 
> Signed-off-by: K. Y. Srinivasan 

No changelog text?  Sorry, I can't take this :(

You know better...
--
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/1] Drivers: hv: vmbus: Cleanup vmbus_set_event()

[K. Y. Srinivasan]

Cleanup vmbus_set_event() by inlining the hypercall to post
the event and since the return value of vmbus_set_event() is not checked,
make it void. As part of this cleanup, get rid of the function
hv_signal_event() as it is only callled from vmbus_set_event().

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/connection.c   |4 ++--
 drivers/hv/hv.c   |   16 
 drivers/hv/hyperv_vmbus.h |4 +---
 3 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 3dc5a9c..4a320e6 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -474,7 +474,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
 /*
  * vmbus_set_event - Send an event notification to the parent
  */
-int vmbus_set_event(struct vmbus_channel *channel)
+void vmbus_set_event(struct vmbus_channel *channel)
 {
u32 child_relid = channel->offermsg.child_relid;
 
@@ -485,5 +485,5 @@ int vmbus_set_event(struct vmbus_channel *channel)
(child_relid >> 5));
}
 
-   return hv_signal_event(channel->sig_event);
+   hv_do_hypercall(HVCALL_SIGNAL_EVENT, channel->sig_event, NULL);
 }
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 1db9556..2ed8e16 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -336,22 +336,6 @@ int hv_post_message(union hv_connection_id connection_id,
return status & 0x;
 }
 
-
-/*
- * hv_signal_event -
- * Signal an event on the specified connection using the hypervisor event IPC.
- *
- * This involves a hypercall.
- */
-int hv_signal_event(void *con_id)
-{
-   u64 status;
-
-   status = hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL);
-
-   return status & 0x;
-}
-
 static int hv_ce_set_next_event(unsigned long delta,
struct clock_event_device *evt)
 {
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 0411b7b..70540d5 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -587,8 +587,6 @@ extern int hv_post_message(union hv_connection_id 
connection_id,
 enum hv_message_type message_type,
 void *payload, size_t payload_size);
 
-extern int hv_signal_event(void *con_id);
-
 extern int hv_synic_alloc(void);
 
 extern void hv_synic_free(void);
@@ -736,7 +734,7 @@ void vmbus_disconnect(void);
 
 int vmbus_post_msg(void *buffer, size_t buflen);
 
-int vmbus_set_event(struct vmbus_channel *channel);
+void vmbus_set_event(struct vmbus_channel *channel);
 
 void vmbus_on_event(unsigned long data);
 
-- 
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: [PATCH] BugFix in XHCI controller driver for scatter gather DMA

[Sergei Shtylyov]

Hello.

On 12/21/2015 03:46 PM, Vikas Bansal wrote:


From: Sumit Batra 

Pre-Condition
URB with Scatter Gather list is queued to bulk OUT endpoint.
Every buffer in scatter gather list is not a multiple of maximum packet
size for that endpoint(short packet).
CHAIN bit is set for all TRBs in a TD so that the DMA happens to all of
them at once.

Issue
DMA operation copies all the CHAINED TRBs at contiguous device memory.
But since the original packet was a short packet, so the actual data is
re-aligned after this DMA operation.
At device end this re-aligned data causes data integrity issue with
applications like ICMP ping.

Solution
Don't set the CHAINED bit for these TRBs, if their buffers are not a
multiple of maximum packet size.
This will reduce the benefit in throughput as required from a scatter
gather implementation, but this reduces the CPU utilization.
And solves the data integrity issue on Device End


Signed-off-by: Sumit Batra 
Signed-off-by: Vikas Bansal 
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..7363dee 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3110,7 +3110,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
 * TRB to indicate it's the last TRB in the chain.
 */
if (num_trbs > 1) {
-   field |= TRB_CHAIN;
+   if (this_sg_len %
+   usb_endpoint_maxp(>ep->desc) == 0)


   Indent with 2 extra tabs ISO 1 please -- it'll be easier on the eyes 
(blends with the next statement otherwise).



+   field |= TRB_CHAIN;
} else {
/* FIXME - add check for ZERO_PACKET flag before this */
td->last_trb = ep_ring->enqueue;


MBR, Sergei

--
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 v6] Fix INT1 Recursion with unregistered breakpoints

[Jeff Merkey]

Let me know if I need to do anything else with this patch.  I am using
git/mutt to send patches from now on and I have my smtp gateway with
gmail properly setup and tested so there won't be any more fritzed
patches.It looks like this is relatively easy to do if you ge the
tools setup correctly.  One problem this patch did not address is
clearing the breakpoints detected as spurious in dr7.The apps that
cause this are likely to just go back and set dr7 active again so
clearing it won't stop it from firing of again, and clearing will most
likely break most of the apps that call the breakpoint API if this
hiccup happens
intermittently.

I very much appreciate you guys patience and help it was fun to work
on this and submit these patches.  Thosmas, I must have misunderstood
the comments about magic numbers but it got corrected.

With regard to the swapgs problem, I may have a fix in the debugger to
get around it by setting the MSR if I detect someone execute one of
the swapxx instructions.  Will solve the stepping problem (tested it),
but doesn;t help with places in the exception handlers where
triggering exceptions causes swapgs to nest unexpectedly.  I will
continue to work on it and see what I can figure out that may not be
so radical as changing all the exception handlers.

Jeff
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Julian Margetson  writes:

> On 12/21/2015 2:27 PM, Måns Rullgård wrote:
>> Julian Margetson  writes:
>>
>>> On 12/21/2015 1:55 PM, Andy Shevchenko wrote:
 On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:
> On 12/21/2015 12:48 PM, Andy Shevchenko wrote:
>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:
>>> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
>>>  wrote:
 On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
 wrote:
 I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
 items on this board, however registers for SATA program it to 64. I
 remember that I got no interrupt when I programmed transfer width
 wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
 on
 Intel SoCs.
>>> One more thing, I have a patch to monitor DMA IO, we may check what
>>> exactly the values are written / read  in DMA. I can share it
>>> tomorrow.
>> As promised the patch I have to debug IO of DW DMA. Didn't check though
>> if it applies cleanly on top of recent vanilla kernel.
 So, the original driver (with patch from Måns) works, right?

>>> The hard drive is recognized .
>>> These system gets unresponsive with USB devices like the mouse and
>>> keyboard not responding  when I start Gparted.
>> Did you disable the SATA and DMA debug messages?
>>
> It is working.

That's good news.  Thanks a lot for helping to test this.

-- 
Måns Rullgård
--
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] ata: sata_dwc_460ex: remove incorrect locking

[Andy Shevchenko]

On Mon, 2015-12-21 at 18:17 +, Mans Rullgard wrote:
> This lock is already taken in ata_scsi_queuecmd() a few levels up the
> call stack so attempting to take it here is an error.  Moreover, it
> is
> pointless in the first place since it only protects a single, atomic
> assignment.
> 
> Enabling lock debugging gives the following output:
> 

+Julian.

I think Julian may give his Tested-by: tag.

> =
> [ INFO: possible recursive locking detected ]
> 4.4.0-rc5+ #189 Not tainted
> -
> kworker/u2:3/37 is trying to acquire lock:
>  (&(>lock)->rlock){-.-...}, at: [<90283294>]
> sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
> 
> but task is already holding lock:
>  (&(>lock)->rlock){-.-...}, at: [<902761ac>]
> ata_scsi_queuecmd+0x2c/0x330
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>    CPU0
>    
>   lock(&(>lock)->rlock);
>   lock(&(>lock)->rlock);
> 
>  *** DEADLOCK ***
>  May be due to missing lock nesting notation
> 
> 4 locks held by kworker/u2:3/37:
>  #0:  ("events_unbound"){.+.+.+}, at: [<9003a0a4>]
> process_one_work+0x12c/0x430
>  #1:  ((>work)){+.+.+.}, at: [<9003a0a4>]
> process_one_work+0x12c/0x430
>  #2:  (>bd_mutex){+.+.+.}, at: [<9011fd54>]
> __blkdev_get+0x50/0x380
>  #3:  (&(>lock)->rlock){-.-...}, at: [<902761ac>]
> ata_scsi_queuecmd+0x2c/0x330
> 
> stack backtrace:
> CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
> Workqueue: events_unbound async_run_entry_fn
> Stack : 90b38e30 0021 0003 9b2a6040  9005f3f0
> 904fc8dc 0025
> 906b96e4  90528648 9b3336c4 904fc8dc 9009bf18
> 0002 0004
>   9b3336c4 9b3336e4 904fc8dc 9003d074
>  9050
> 9005e738     
>  
> 6e657665 755f7374 756f626e 646e  
> 9b00ca00 9b025000
>   ...
> Call Trace:
> [<90009d6c>] show_stack+0x88/0xa4
> [<90057744>] __lock_acquire+0x1ce8/0x2154
> [<900583e4>] lock_acquire+0x64/0x8c
> [<9045ff10>] _raw_spin_lock_irqsave+0x54/0x78
> [<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
> [<90283484>] sata_dwc_qc_issue+0x1a8/0x24c
> [<9026b39c>] ata_qc_issue+0x1f0/0x410
> [<90273c6c>] ata_scsi_translate+0xb4/0x200
> [<90276234>] ata_scsi_queuecmd+0xb4/0x330
> [<9025800c>] scsi_dispatch_cmd+0xd0/0x128
> [<90259934>] scsi_request_fn+0x58c/0x638
> [<901a3e50>] __blk_run_queue+0x40/0x5c
> [<901a83d4>] blk_queue_bio+0x27c/0x28c
> [<901a5914>] generic_make_request+0xf0/0x188
> [<901a5a54>] submit_bio+0xa8/0x194
> [<9011adcc>] submit_bh_wbc.isra.23+0x15c/0x17c
> [<9011c908>] block_read_full_page+0x3e4/0x428
> [<9009e2e0>] do_read_cache_page+0xac/0x210
> [<9009fd90>] read_cache_page+0x18/0x24
> [<901bbd18>] read_dev_sector+0x38/0xb0
> [<901bd174>] msdos_partition+0xb4/0x5c0
> [<901bcb8c>] check_partition+0x140/0x274
> [<901bba60>] rescan_partitions+0xa0/0x2b0
> [<9011ff68>] __blkdev_get+0x264/0x380
> [<901201ac>] blkdev_get+0x128/0x36c
> [<901b9378>] add_disk+0x3c0/0x4bc
> [<90268268>] sd_probe_async+0x100/0x224
> [<90043a44>] async_run_entry_fn+0x50/0x124
> [<9003a11c>] process_one_work+0x1a4/0x430
> [<9003a4f4>] worker_thread+0x14c/0x4fc
> [<900408f4>] kthread+0xd0/0xe8
> [<90004338>] ret_from_kernel_thread+0x14/0x1c
> 
> Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver,
> sata_dwc_460ex")
> Signed-off-by: Mans Rullgard 
> ---
>  drivers/ata/sata_dwc_460ex.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/ata/sata_dwc_460ex.c
> b/drivers/ata/sata_dwc_460ex.c
> index 902034991517..7a7faca0ddcd 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -924,15 +924,13 @@ static void sata_dwc_exec_command_by_tag(struct
> ata_port *ap,
>    struct ata_taskfile *tf,
>    u8 tag, u32 cmd_issued)
>  {
> - unsigned long flags;
>   struct sata_dwc_device_port *hsdevp = HSDEVP_FROM_AP(ap);
>  
>   dev_dbg(ap->dev, "%s cmd(0x%02x): %s tag=%d\n", __func__,
> tf->command,
>   ata_get_cmd_descript(tf->command), tag);
>  
> - spin_lock_irqsave(>host->lock, flags);
>   hsdevp->cmd_issued[tag] = cmd_issued;
> - spin_unlock_irqrestore(>host->lock, flags);
> +
>   /*
>    * Clear SError before executing a new command.
>    * sata_dwc_scr_write and read can not be used here.
> Clearing the PM

-- 
Andy Shevchenko 
Intel Finland Oy

--
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: IO errors after "block: remove bio_get_nr_vecs()"

[Tejun Heo]

Hello, again.

On Mon, Dec 21, 2015 at 03:07:21PM -0500, Tejun Heo wrote:
> Hello, Artem.
> 
> Can you please apply the following patch on top and see whether
> anything changes?  If it does make the issue go away, can you please
> revert the ".can_queue" part and test again?

If the patch doesn't change anything, can you please try the
followings and see which one makes difference?

1. Exclude memory above 4G line with boot param "max_addr=4G".
2. Disable highmem with "highmem=0".
3. Try booting 64bit kernel.

At the moment, the only thing I can think of which can explain the PAE
+ bio_get_nr_vecs() situation is that the bio split code which is
activated by the bio_get_nr_vecs() somehow messes up 64bit or high
addresses on 32bit kernels.  I scanned for the obvious but at bio
layer, memory is represented by struct page, so nothing obvious seems
broken.

Note that for now I'm ignoring the debug dumps from the ahci debug
patch which indicates that the passed in addresses are all fine.  It
is possible that the controller gets confused with certain receiving
addresses and reports failure on later commands or maybe there is a
different sequence of events which can encompass both that we don't
know of yet.

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/

Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Julian Margetson  writes:

> On 12/21/2015 1:55 PM, Andy Shevchenko wrote:
>> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:
>>> On 12/21/2015 12:48 PM, Andy Shevchenko wrote:
 On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:
> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
>  wrote:
>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
>> wrote:
>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
>> items on this board, however registers for SATA program it to 64. I
>> remember that I got no interrupt when I programmed transfer width
>> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
>> on
>> Intel SoCs.
> One more thing, I have a patch to monitor DMA IO, we may check what
> exactly the values are written / read  in DMA. I can share it
> tomorrow.
 As promised the patch I have to debug IO of DW DMA. Didn't check though
 if it applies cleanly on top of recent vanilla kernel.
>> So, the original driver (with patch from Måns) works, right?
>>
> The hard drive is recognized .
> These system gets unresponsive with USB devices like the mouse and
> keyboard not responding  when I start Gparted.

Did you disable the SATA and DMA debug messages?

-- 
Måns Rullgård
--
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] serial: 8250: add gpio support to exar

[Andy Shevchenko]

On Mon, Dec 21, 2015 at 5:19 PM, Sudip Mukherjee
 wrote:

> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 6412f14..ec3d287 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -378,3 +378,11 @@ config SERIAL_8250_MID
>   Selecting this option will enable handling of the extra features
>   present on the UART found on Intel Medfield SOC and various other
>   Intel platforms.
> +
> +config SERIAL_8250_EXAR_GPIO
> +   bool "Support for GPIO pins on XR17V352/354/358"
> +   depends on SERIAL_8250_PCI && GPIOLIB
> +   select GPIO_SYSFS
> +   help
> + Selecting this option will enable handling of GPIO pins present
> + on Exar XR17V352/354/358 chips.
> diff --git a/drivers/tty/serial/8250/Makefile 
> b/drivers/tty/serial/8250/Makefile
> index e177f86..1d0fce0 100644
> --- a/drivers/tty/serial/8250/Makefile
> +++ b/drivers/tty/serial/8250/Makefile
> @@ -28,5 +28,8 @@ obj-$(CONFIG_SERIAL_8250_MT6577)  += 8250_mtk.o
>  obj-$(CONFIG_SERIAL_8250_UNIPHIER) += 8250_uniphier.o
>  obj-$(CONFIG_SERIAL_8250_INGENIC)  += 8250_ingenic.o
>  obj-$(CONFIG_SERIAL_8250_MID)  += 8250_mid.o
> +obj-$(CONFIG_SERIAL_8250_EXAR_GPIO)+= exar_gpio.o
> +exar_gpio-y:= 8250_pci.o 8250_gpio.o
> +
>
>  CFLAGS_8250_ingenic.o += -I$(srctree)/scripts/dtc/libfdt
>
>
> But I am getting:
> ERROR: "xr17v35x_gpio_exit" [drivers/tty/serial/8250/8250_pci.ko] undefined!
> ERROR: "xr17v35x_gpio_init" [drivers/tty/serial/8250/8250_pci.ko] undefined!
>
> I will need little hint for the Makefile, please. Its clear that i have
> messed up.

Yes, read my previous mail.

There are at least two approaches:
 - use 8250_pci, etc as a library (see example: 8250_mid.c)
 - force 8250_pci to use external libraries in some cases (seems your approach)

In the latter you have to extend 8250_pci and rename it. I have no
idea if Greg or anyone else gives a green light for that.

Something like this (forget syntax of ifs in Makefile though
obj-(…8250_PCI) += 8250_pci.o
obj-8250_pci = 8250_pci_orig.o
ifneq (…EXAR_GPIO,)
obj-8250_pci += exar_gpio.o
endif

But what I can recommend is to split exar parts out of 8250_pci first
to a separate driver, do your part as a part of that new driver.
Of course better to gather maintainer's opinion first.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 18:24:45 +0100

The variable "mne_swab" will eventually be set to an appropriate value
from a call of the ptlrpc_rep_need_swab() function.
Thus let us omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index 2c48847..da130f4 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd,
struct page **pages;
int nrpages;
bool eof = true;
-   bool mne_swab = false;
+   bool mne_swab;
int i;
int ealen;
int rc;
-- 
2.6.3

--
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] dmaengine: dw: clear LLP_[SD]_EN bits in last descriptor of a chain

[Mans Rullgard]

The datasheet requires that the LLP_[SD]_EN bits be cleared whenever
LLP.LOC is zero, i.e. in the last descriptor of a multi-block chain.
Make the driver do this.

Signed-off-by: Mans Rullgard 
---
 drivers/dma/dw/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 7067b6ddc1db..ca7cafc82f6b 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -751,6 +751,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, 
dma_addr_t src,
prev->lli.ctllo |= DWC_CTLL_INT_EN;
 
prev->lli.llp = 0;
+   prev->lli.ctllo &= ~(DWC_CTLL_LLP_D_EN | DWC_CTLL_LLP_S_EN);
first->txd.flags = flags;
first->total_len = len;
 
@@ -912,6 +913,7 @@ slave_sg_fromdev_fill_desc:
prev->lli.ctllo |= DWC_CTLL_INT_EN;
 
prev->lli.llp = 0;
+   prev->lli.ctllo &= ~(DWC_CTLL_LLP_D_EN | DWC_CTLL_LLP_S_EN);
first->total_len = total_len;
 
return >txd;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/4] um: Fix ptrace GETREGS/SETREGS bugs

[Mickaël Salaün]

This fix two related bugs:
* PTRACE_GETREGS doesn't get the right orig_ax (syscall) value
* PTRACE_SETREGS can't set the orig_ax value (erased by initial value)

Remove the now useless and error-prone get_syscall().

Fix inconsistent behavior in the ptrace implementation for i386 when
updating orig_eax automatically update the syscall number as well. This
is now updated in handle_syscall().

Signed-off-by: Mickaël Salaün 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: Kees Cook 
Cc: Andy Lutomirski 
Cc: Will Drewry 
Cc: Thomas Meyer 
Cc: Nicolas Iooss 
Cc: Anton Ivanov 
Cc: Meredydd Luff 
Cc: David Drysdale 
---
 arch/um/kernel/skas/syscall.c   | 25 ++---
 arch/um/os-Linux/skas/process.c |  7 ---
 arch/x86/um/ptrace_32.c |  8 +++-
 3 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c
index 1683b8e..0d624e0 100644
--- a/arch/um/kernel/skas/syscall.c
+++ b/arch/um/kernel/skas/syscall.c
@@ -7,29 +7,32 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 void handle_syscall(struct uml_pt_regs *r)
 {
struct pt_regs *regs = container_of(r, struct pt_regs, regs);
-   long result;
int syscall;
 
-   if (syscall_trace_enter(regs)) {
-   result = -ENOSYS;
+   /* Initialize the syscall number and default return value. */
+   UPT_SYSCALL_NR(r) = PT_SYSCALL_NR(r->gp);
+   PT_REGS_SET_SYSCALL_RETURN(regs, -ENOSYS);
+
+   if (syscall_trace_enter(regs))
goto out;
-   }
 
-   syscall = get_syscall(r);
+   /* Update the syscall number after orig_ax has potentially been updated
+* with ptrace.
+*/
+   UPT_SYSCALL_NR(r) = PT_SYSCALL_NR(r->gp);
+   syscall = UPT_SYSCALL_NR(r);
 
-   if ((syscall > __NR_syscall_max) || syscall < 0)
-   result = -ENOSYS;
-   else
-   result = EXECUTE_SYSCALL(syscall, regs);
+   if (syscall >= 0 && syscall <= __NR_syscall_max)
+   PT_REGS_SET_SYSCALL_RETURN(regs,
+   EXECUTE_SYSCALL(syscall, regs));
 
 out:
-   PT_REGS_SET_SYSCALL_RETURN(regs, result);
-
syscall_trace_leave(regs);
 }
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index b856c66..23025d6 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -172,13 +172,6 @@ static void handle_trap(int pid, struct uml_pt_regs *regs,
handle_syscall(regs);
 }
 
-int get_syscall(struct uml_pt_regs *regs)
-{
-   UPT_SYSCALL_NR(regs) = PT_SYSCALL_NR(regs->gp);
-
-   return UPT_SYSCALL_NR(regs);
-}
-
 extern char __syscall_stub_start[];
 
 static int userspace_tramp(void *stack)
diff --git a/arch/x86/um/ptrace_32.c b/arch/x86/um/ptrace_32.c
index a29756f..47c78d5 100644
--- a/arch/x86/um/ptrace_32.c
+++ b/arch/x86/um/ptrace_32.c
@@ -68,6 +68,7 @@ static const int reg_offsets[] = {
[EFL] = HOST_EFLAGS,
[UESP] = HOST_SP,
[SS] = HOST_SS,
+   [ORIG_EAX] = HOST_ORIG_AX,
 };
 
 int putreg(struct task_struct *child, int regno, unsigned long value)
@@ -83,6 +84,7 @@ int putreg(struct task_struct *child, int regno, unsigned 
long value)
case EAX:
case EIP:
case UESP:
+   case ORIG_EAX:
break;
case FS:
if (value && (value & 3) != 3)
@@ -108,9 +110,6 @@ int putreg(struct task_struct *child, int regno, unsigned 
long value)
value &= FLAG_MASK;
child->thread.regs.regs.gp[HOST_EFLAGS] |= value;
return 0;
-   case ORIG_EAX:
-   child->thread.regs.regs.syscall = value;
-   return 0;
default :
panic("Bad register in putreg() : %d\n", regno);
}
@@ -143,8 +142,6 @@ unsigned long getreg(struct task_struct *child, int regno)
 
regno >>= 2;
switch (regno) {
-   case ORIG_EAX:
-   return child->thread.regs.regs.syscall;
case FS:
case GS:
case DS:
@@ -163,6 +160,7 @@ unsigned long getreg(struct task_struct *child, int regno)
case EDI:
case EBP:
case EFL:
+   case ORIG_EAX:
break;
default:
panic("Bad register in getreg() : %d\n", regno);
-- 
2.6.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 3/5] pinctrl: sh-pfc: add missing of_node_put

[Laurent Pinchart]

Hi Julia,

Thank you for the patch.

On Monday 21 December 2015 17:39:46 Julia Lawall wrote:
> for_each_child_of_node performs an of_node_get on each iteration, so a
> goto out of the loop requires an of_node_put.
> 
> A simplified version of the semantic patch that fixes this problem is as
> follows (http://coccinelle.lip6.fr):
> 
> // 
> @@
> local idexpression n;
> expression e,e1;
> identifier l;
> @@
> 
>  for_each_child_of_node(e1,n) {
>...
> (
>of_node_put(n);
> 
>e = n
> 
>return n;
> 
> +  of_node_put(n);
> ?  goto l;
> )
>...
>  }
> l: ... when != n
> // 
> 
> Signed-off-by: Julia Lawall 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/pinctrl/sh-pfc/pinctrl.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c
> b/drivers/pinctrl/sh-pfc/pinctrl.c index 863c3e3..87b0a59 100644
> --- a/drivers/pinctrl/sh-pfc/pinctrl.c
> +++ b/drivers/pinctrl/sh-pfc/pinctrl.c
> @@ -273,8 +273,10 @@ static int sh_pfc_dt_node_to_map(struct pinctrl_dev
> *pctldev, for_each_child_of_node(np, child) {
>   ret = sh_pfc_dt_subnode_to_map(pctldev, child, map, num_maps,
>  );
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(child);
>   goto done;
> + }
>   }
> 
>   /* If no mapping has been found in child nodes try the config node. */

-- 
Regards,

Laurent Pinchart

--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Andy Shevchenko]

On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote:
> Andy Shevchenko  writes:
> 
> > On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote:
> > > Andy Shevchenko  writes:
> > >  
> > > > P.S. I also noticed that original driver enables interrupt per
> > > > each
> > > > block
> > > 
> > > And then ignores all but the transfer complete interrupt.
> > > 
> > > > and sets protection control bits.
> > > 
> > > With no indication what the value it sets is supposed to mean.
> > 
> > Okay, let's summarize what we have:
> > 
> > 0. AR: Get a working reference for PPC 460EX SATA driver
> 
> Do we consider Julian's latest result working?

I think so.

> 
> > 1. AR: Clear LLP_EN bits at the last block of LLP transfer
> 
> Patch sent.

Acked.

> 
> > 2. AR: Rename masters to 'memory' and 'peripheral' and change them
> > per
> > DMA direction
> 
> Good idea.  I'd call them memory and device though to match existing
> dmaengine nomenclature.

I remember how I called in my patch. So, there is no problem to rename,
but will see.

> 
> > 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers
> 
> I started working on a patch for that already.

Thanks.

> 
> > 4. CHECK: PROTCTL bit (documentation says that recommended value is
> > 0x01)
> 
> Any idea what the value of 0x3 used by the old sata driver means?
> Presumably that's decided by the bus.

Nope, documentation says that it is direct representation of hprot[3:1]
wires on the master interface. Also it refers to AMBA spec, so, if you
have access to AMBA spec I think we might get it from there.

> 
> > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE)
> > 6. CHECK: Block interrupts vs. one interrupt at the end of block
> > chain
> > (Måns, I missed how any of them is ignored)
> 
> The interrupt handler looks at the StatusTfr and StatusErr registers
> and
> ignores StatusBlock.

I have to refresh my memory, since BLOCK interrupts should be enabled
(unmasked) separately. I have forgotten which type of interrupt is
generated in this case, BLOCK, or XFER after each block, or only one
XFER at the last block (LLP.LOC = 0) and BLOCK are ignored. So, will
check later.

> 
> > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail,
> > etc
> > (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard
> > SATA)
> 
> I can test on AVR32.  That is as far as I know the only system I have
> with this DMA engine.

If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell,
you have it as well as long you have LPSS block there. (Most of them
are Atoms).

> 
> > I can share my working branch with a set of patches regarding to
> > dw_dmac. We may do our work based on that code and after I'll
> > submit
> > everything to upstream. Does it sound okay for you, guys?
> 
> I'm going away for the holidays, so I won't be able to do any serious
> work on this until January, but I'll keep an eye on emails and may
> even
> reply occasionally.  Before I go, I'll publish my patches so far
> whatever shape they're in.

Okay, thanks! I will include them in my branch which I'm going to
publish on GitHUB.

Happy holidays!

-- 
Andy Shevchenko 
Intel Finland Oy

--
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] crypto: AF_ALG - add support for keys/asymmetric-type

[Stephan Mueller]

Am Montag, 21. Dezember 2015, 12:51:07 schrieb Tadeusz Struk:

Hi Tadeusz,

> From: Tadeusz Struk 
> 
> Created on top of patchset from Stephan Mueller 
> https://patchwork.kernel.org/patch/7877921/
> https://patchwork.kernel.org/patch/7877971/
> https://patchwork.kernel.org/patch/7877961/
> 
> This patch adds support for asymmetric key type to AF_ALG.
> It will work as follows: A new PF_ALG socket options will be
> added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
> ALG_SET_PUBKEY_ID and ALG_SET_KEY_ID for setting public and
> private keys respectively. When these new options will be used
> the user instead of providing the key material, will provide a
> key id and the key itself will be obtained from kernel keyring
> subsystem. The user will use the standard tools (keyctl tool
> or the keyctl syscall) for key instantiation and to obtain the
> key id. The key id can also be obtained by reading the
> /proc/keys file.
> 
> When a key will be found, the request_key() function will
> return a requested key. Next the asymmetric key subtype will be
> used to obtain the public_key, which can be either a public key
> or a private key from the cryptographic point of view, and the
> key payload will be passed to the akcipher pf_alg subtype.
> Pf_alg code will then call crypto API functions, either the
> crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
> depending on the used option. Subsequently the asymmetric key
> will be freed and return code returned back to the user.
> 
> Currently the interface will be restricted only to asymmetric
> ciphers, but it can be extended later to work with symmetric
> ciphers if required.
> 
> The assumption is that access rights for a given user will be
> verified by the key subsystem so the pf_alg interface can call
> the request_key() without checking if the user has appropriate
> rights (Please verify this assumption).
> 
> Signed-off-by: Tadeusz Struk 
> ---
>  crypto/af_alg.c |   41
> + include/uapi/linux/if_alg.h |   
> 2 ++
>  2 files changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 767a134..d2ec357 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -22,6 +22,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  struct alg_type_list {
>   const struct af_alg_type *type;
> @@ -173,7 +175,7 @@ static int alg_bind(struct socket *sock, struct sockaddr
> *uaddr, int addr_len) }
> 
>  static int alg_setkey(struct sock *sk, char __user *ukey,
> -   unsigned int keylen,
> +   unsigned int keylen, bool key_id,
> int (*setkey)(void *private, const u8 *key,
>   unsigned int keylen))
>  {
> @@ -192,7 +194,30 @@ static int alg_setkey(struct sock *sk, char __user
> *ukey, if (copy_from_user(key, ukey, keylen))
>   goto out;
> 
> - err = setkey(ask->private, key, keylen);
> + if (key_id) {

Wouldn't it make sense to rather have a complete separate function for setting 
the key based on the ID? I.e. we have one function for setting the key based 
on a user-given buffer. A second function handles your additional code. As 
both are unrelated, I would not suggest to clutter one function with the logic 
of the other.

> + struct key *keyring;
> + struct public_key *pkey;
> + char key_name[12];
> + u32 keyid = *((u32 *)key);
> +
> + sprintf(key_name, "id:%08x", keyid);
> + keyring = request_key(_type_asymmetric, key_name, NULL);
> +
> + err = -ENOKEY;
> + if (IS_ERR(keyring))
> + goto out;
> +
> + pkey = keyring->payload.data[asym_crypto];
> + if (!pkey) {
> + key_put(keyring);
> + goto out;
> + }
> +
> + err = setkey(ask->private, pkey->key, pkey->keylen);
> + key_put(keyring);
> + } else {
> + err = setkey(ask->private, key, keylen);
> + }
> 
>  out:
>   sock_kzfree_s(sk, key, keylen);
> @@ -207,6 +232,8 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname, struct alg_sock *ask = alg_sk(sk);
>   const struct af_alg_type *type;
>   int err = -ENOPROTOOPT;
> + bool key_id = ((optname == ALG_SET_PUBKEY_ID) ||
> +(optname == ALG_SET_KEY_ID));
> 
>   lock_sock(sk);
>   type = ask->type;
> @@ -216,16 +243,22 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname,
> 
>   switch (optname) {
>   case ALG_SET_KEY:
> + case ALG_SET_KEY_ID:
>   if (sock->state == SS_CONNECTED)
>   goto unlock;
> 
> - err = alg_setkey(sk, optval, optlen, type->setkey);
> + /* ALG_SET_KEY_ID is only 

[PATCH 0/2] blackfin-cpufreq: Fine-tuning for properties of one function

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 22:24:18 +0100

Another update suggestion was taken into account after a patch was applied
from static source code analysis.

Markus Elfring (2):
  Change return type of cpu_set_cclk() to that of clk_set_rate()
  Mark cpu_set_cclk() as static

 drivers/cpufreq/blackfin-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.6.3

--
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-sunxi] Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs

[Danny Milosavljevic]

Hi Maxime,

On Fri, 18 Dec 2015 11:19:43 +0100
Maxime Ripard  wrote:

> It would also be a good idea to open a github issue on allwinner's 
> documentation repo to make them know that the register name doesn't 
> match between the register list and the register documentations.

I did that now. the issue report is at 
https://github.com/allwinner-zh/documents/issues/11

Cheers,
   Danny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] drivers:char:Removed unnecessary braces

[Bhumika Goyal]

Removed braces from single statement if condition.Fixed checkpatch.pl
warning.

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
-Correct the subject and also send to a public mailing list.
---
 drivers/char/raw.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/char/raw.c b/drivers/char/raw.c
index 60316fb..c8bf17b 100644
--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -334,10 +334,8 @@ static int __init raw_init(void)
 
cdev_init(_cdev, _fops);
ret = cdev_add(_cdev, dev, max_raw_minors);
-   if (ret) {
+   if (ret)
goto error_region;
-   }
-
raw_class = class_create(THIS_MODULE, "raw");
if (IS_ERR(raw_class)) {
printk(KERN_ERR "Error creating raw class.\n");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] staging-Lustre: Fine-tuning for some function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 20:00:02 +0100

Several update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete unnecessary goto statements in six functions
  Delete an unnecessary variable initialisation in mgc_process_recover_log()
  Less checks in mgc_process_recover_log() after error detection
  Fix a jump label position in osc_get_info()

 drivers/staging/lustre/lustre/llite/namei.c |  1 -
 drivers/staging/lustre/lustre/mdc/mdc_request.c |  7 
 drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 +++--
 drivers/staging/lustre/lustre/osc/osc_request.c |  2 +-
 4 files changed, 25 insertions(+), 38 deletions(-)

-- 
2.6.3

--
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 4/5] firmware: actually return NULL on failed request_firmware_nowait()

[Luis R. Rodriguez]

On Wed, Dec 09, 2015 at 02:50:28PM -0800, Brian Norris wrote:
> The kerneldoc for request_firmware_nowait() says that it may call the
> provided cont() callback with @fw == NULL, if the firmware request
> fails. However, this is not the case when called with an empty string
> (""). This case is short-circuited by the 'name[0] == '\0'' check
> introduced in commit 471b095dfe0d ("firmware_class: make sure fw requests
> contain a name"), so _request_firmware() never gets to set the fw to
> NULL.
> 
> Noticed while using the new 'trigger_async_request' testing hook:

<-- snip -->

> 
> # printf '\x00' > 
> /sys/devices/virtual/misc/test_firmware/trigger_async_request
> [   32.126322] test_firmware: loading ''
> [   32.129995] test_firmware: failed to async load firmware
> -bash: printf: write error: No such device
> 
> Fixes: 471b095dfe0d ("firmware_class: make sure fw requests contain a name")
> Signed-off-by: Brian Norris 
> Acked-by: Ming Lei 
> Acked-by: Kees Cook 

Acked-by: Luis R. Rodriguez 

  Luis
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Andy Shevchenko]

On Mon, 2015-12-21 at 18:16 +, Måns Rullgård wrote:
> Andy Shevchenko  writes:
> 
> > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård 
> > wrote:
> > > Andy Shevchenko  writes:
> > > 
> > I used to have a patch to implement this in dw_dmac driver.
> > However, I
> > dropped it at some point. Seems we need it back and now I possible
> > have a good explanation why.
> 
> Are you still able to find that patch?  Shouldn't be too hard to do
> from
> scratch if not.

Yes, I found a version of it, let me mock up tomorrow something
working.

> 
> > > If those values didn't matter, why would the fields exist in the
> > > first place?
> > 
> > Because someone can have more than one AHB bus on the system and
> > connect DMA to all of them (up to 4).
> 
> Which apparently these guys did.  Well, not a full-blown AHB bus, but
> they seem to be using two master interfaces.

To different buses? Intel HW uses two masters and they are quite equal
(at least from OS point of view, it might be HW adjusts it).

> 
> > > > In any case on all Intel SoCs and AVR32, and as far as I can
> > > > tell on
> > > > Spear13xx (Viresh?) there is not a case, that's why I hardly
> > > > imagine
> > > > that the problem is in master numbers by themselves.
> > > 
> > > The 460EX is a PowerPC system.  Expect unusual topologies.
> > 
> > Yeah, that's right.
> 
> BTW, there's a good reason for wiring it like this.  If the source
> and
> destination are on different buses, the DMA engine can do a read and
> a
> write in each cycle.  Otherwise the reads and writes have to be
> issued
> alternately.

Okay. We need first to have a confirmation. I would try to set other
bits under question to see if it helps first (CFG register in DMA).

> Most likely nothing happens, but I think it ought to be
> > > > > fixed.  In fact,
> > > > > I have a patch already.
> > > > 
> > > > Good. Send with Fixes tag if it's upstream ready.
> > > > 
> > > > > Come to think of it, I have an AVR32 dev somewhere.  Maybe I
> > > > > should dust
> > > > > it off.
> > > > 
> > > > I have ATNGW100.
> > > 
> > > I have an AT32ATK1006.  Can you suggest a good test to exercise
> > > the DMA
> > > engine?
> > 
> > On that board I tried MMC (the only available user for me), though
> > it
> > is not reliable, I also tried the dmatest module.
> 
> Hmm, is there anywhere this damn driver actually works?  ;-)

Yes, on Intel HW.

-- 
Andy Shevchenko 
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] selftests/seccomp: Remove the need for HAVE_ARCH_TRACEHOOK

[Mickaël Salaün]

Some architectures do not implement PTRACE_GETREGSET nor
PTRACE_SETREGSET (required by HAVE_ARCH_TRACEHOOK) but only implement
PTRACE_GETREGS and PTRACE_SETREGS (e.g. User-mode Linux).

This improve seccomp selftest portability for architectures without
HAVE_ARCH_TRACEHOOK support by defining a new trigger HAVE_GETREGS. For
now, this is only enabled for i386 and x86_64 architectures. This is
required to be able to run this tests on User-mode Linux.

Signed-off-by: Mickaël Salaün 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Kees Cook 
Cc: Andy Lutomirski 
Cc: Will Drewry 
Cc: Shuah Khan 
Cc: Meredydd Luff 
Cc: David Drysdale 
---
 tools/testing/selftests/seccomp/seccomp_bpf.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c 
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 882fe83..b9453b8 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1246,11 +1246,24 @@ TEST_F(TRACE_poke, getpid_runs_normally)
 # error "Do not know how to find your architecture's registers and syscalls"
 #endif
 
+/* Use PTRACE_GETREGS and PTRACE_SETREGS when available. This is useful for
+ * architectures without HAVE_ARCH_TRACEHOOK (e.g. User-mode Linux).
+ */
+#if defined(__x86_64__) || defined(__i386__)
+#define HAVE_GETREGS
+#endif
+
 /* Architecture-specific syscall fetching routine. */
 int get_syscall(struct __test_metadata *_metadata, pid_t tracee)
 {
-   struct iovec iov;
ARCH_REGS regs;
+#ifdef HAVE_GETREGS
+   EXPECT_EQ(0, ptrace(PTRACE_GETREGS, tracee, 0, )) {
+   TH_LOG("PTRACE_GETREGS failed");
+   return -1;
+   }
+#else
+   struct iovec iov;
 
iov.iov_base = 
iov.iov_len = sizeof(regs);
@@ -1258,6 +1271,7 @@ int get_syscall(struct __test_metadata *_metadata, pid_t 
tracee)
TH_LOG("PTRACE_GETREGSET failed");
return -1;
}
+#endif
 
return regs.SYSCALL_NUM;
 }
@@ -1266,13 +1280,16 @@ int get_syscall(struct __test_metadata *_metadata, 
pid_t tracee)
 void change_syscall(struct __test_metadata *_metadata,
pid_t tracee, int syscall)
 {
-   struct iovec iov;
int ret;
ARCH_REGS regs;
-
+#ifdef HAVE_GETREGS
+   ret = ptrace(PTRACE_GETREGS, tracee, 0, );
+#else
+   struct iovec iov;
iov.iov_base = 
iov.iov_len = sizeof(regs);
ret = ptrace(PTRACE_GETREGSET, tracee, NT_PRSTATUS, );
+#endif
EXPECT_EQ(0, ret);
 
 #if defined(__x86_64__) || defined(__i386__) || defined(__powerpc__) || \
@@ -1312,9 +1329,13 @@ void change_syscall(struct __test_metadata *_metadata,
if (syscall == -1)
regs.SYSCALL_RET = 1;
 
+#ifdef HAVE_GETREGS
+   ret = ptrace(PTRACE_SETREGS, tracee, 0, );
+#else
iov.iov_base = 
iov.iov_len = sizeof(regs);
ret = ptrace(PTRACE_SETREGSET, tracee, NT_PRSTATUS, );
+#endif
EXPECT_EQ(0, ret);
 }
 
-- 
2.6.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 v5] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/21/2015 02:01 PM, Sergei Shtylyov wrote:


This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

   config EXTCON_MAX3355
  tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST


If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST?
And no, it shouldn't depend on gpiolib. It has empty stubs for the case
of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers,
I'll look into it.


Yes. When GPIOLIB is disabled, the build issue don't happen.


What? It surely does happen!


because include/linux/gpio/consumer.h implement the dummy function
for all gpio functions if CONFIG_GPIOLIB is disabled.


Linus W. advised to #include this header explicitly -- I'll try and post.


   I see you already #include'd it, thanks. But in that case,  
doesn't seem necessary.



Thanks,
Chanwoo Choi


MBR, Sergei

--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Julian Margetson]

On 12/21/2015 3:27 PM, Måns Rullgård wrote:

Julian Margetson  writes:


On 12/21/2015 2:27 PM, Måns Rullgård wrote:

Julian Margetson  writes:


On 12/21/2015 1:55 PM, Andy Shevchenko wrote:

On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:

On 12/21/2015 12:48 PM, Andy Shevchenko wrote:

On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:

On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
 wrote:

On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
wrote:
I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
items on this board, however registers for SATA program it to 64. I
remember that I got no interrupt when I programmed transfer width
wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
on
Intel SoCs.

One more thing, I have a patch to monitor DMA IO, we may check what
exactly the values are written / read  in DMA. I can share it
tomorrow.

As promised the patch I have to debug IO of DW DMA. Didn't check though
if it applies cleanly on top of recent vanilla kernel.

So, the original driver (with patch from Måns) works, right?


The hard drive is recognized .
These system gets unresponsive with USB devices like the mouse and
keyboard not responding  when I start Gparted.

Did you disable the SATA and DMA debug messages?


It is working.

That's good news.  Thanks a lot for helping to test this.


No problem.
If you can influence anyone of the radeon guys to have a look at the 
ring test failure on the Sam460ex again,

I will  be happy to help test in that area as well .

http://lists.freedesktop.org/archives/dri-devel/2013-September/045050.html
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-February/125060.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 v1 1/4] um: Fix ptrace GETREGS/SETREGS bugs

[Mickaël Salaün]

On 21/12/2015 11:13, Richard Weinberger wrote:
> Am 21.12.2015 um 10:23 schrieb Mickaël Salaün:
> Doesn't this break the support for changing syscall numbers using 
> PTRACE_SETREGS?

 The logic is unchanged except updating the UPT_SYSCALL_NR before 
 syscall_trace_enter(). I did my last tests with the x86_32 subarchitecture 
 and all tests (from selftest/seccomp), including PTRACE_SETREGS for 
 syscall numbers tests, passed. However, 2 of this tests still fail for 
 x86_64 (only).
>>>
>>> No, the logic is different.
>>> syscall_trace_enter(regs) enters the ptrace() path and here registers can 
>>> be changed.
>>> Hence "syscall = UPT_SYSCALL_NR(r);" will see the old syscall number.
>>> UPT_SYSCALL_NR() returns the syscall number before the ptrace() path...
>>
>> The thing is, PTRACE_SETREGS give access to *orig_ax* in the 
>> user_regs_struct from arch/x86/include/asm/user_*.h and selftest/seccomp 
>> only update this (virtual) register, not the EAX/RAX. Am I missing something?
> 
> Sorry, meant orig...
> 
> Please see the attached program. It proves that your patch is breaking stuff.
> The test is extracted from UML's selftests.

OK, I found the origin of this misunderstanding. On x86_32, PTRACE_SETREGS set 
regs->syscall when updating orig_eax, which is not the case on x86_64, hence 
the difference of behavior. I fixed this bug in the v2 series. The ptsc test 
and all the seccomp tests pass for 32 and 64 bits!

Where can we find the UML selftests?

Thanks,
 Mickaël



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 5/8] phy: rockchip-usb: expose the phy-internal PLLs

[Michael Turquette]

Kishon & Heiko,

On Tue, Dec 15, 2015 at 2:53 AM, Kishon Vijay Abraham I  wrote:
> Hi Mike,
>
> On Friday 20 November 2015 02:52 AM, Heiko Stuebner wrote:
>> The USB phys on Rockchip SoCs contain their own internal PLLs to create
>> the 480MHz needed. Additionally this PLL output is also fed back into the
>> core clock-controller as possible source for clocks like the GPU or others.
>>
>> Until now this was modelled incorrectly with a "virtual" factor clock in
>> the clock controller. The one big caveat is that if we turn off the usb phy
>> via the siddq signal, all analog components get turned off, including the
>> PLLs. It is therefore possible that a source clock gets disabled without
>> the clock driver ever knowing, possibly making the system hang.
>>
>> Therefore register the phy-plls as real clocks that the clock driver can
>> then reference again normally, making the clock hirarchy finally reflect
>> the actual hardware.
>>
>> The phy-ops get converted to simply turning that new clock on and off
>> which in turn controls the siddq signal of the phy.
>>
>> Through this the driver gains handling for platform-specific data, to
>> handle the phy->clock name association.
>
> Are you okay with this patch/ Can you give your Acked-by?

Acked-by: Michael Turquette 

>
> Thanks
> Kishon
>
>>
>> Signed-off-by: Heiko Stuebner 
>> Reviewed-by: Douglas Anderson 
>> ---
>>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   1 +
>>  drivers/phy/phy-rockchip-usb.c | 188 
>> ++---
>>  2 files changed, 162 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt 
>> b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
>> index 9b37242..68498d5 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
>> @@ -24,6 +24,7 @@ required properties:
>>  Optional Properties:
>>  - clocks : phandle + clock specifier for the phy clocks
>>  - clock-names: string, clock name, must be "phyclk"
>> +- #clock-cells: for users of the phy-pll, should be 0
>>
>>  Example:
>>
>> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
>> index 16cd533..33a80eb 100644
>> --- a/drivers/phy/phy-rockchip-usb.c
>> +++ b/drivers/phy/phy-rockchip-usb.c
>> @@ -15,12 +15,14 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -36,15 +38,28 @@
>>  #define SIDDQ_ON BIT(13)
>>  #define SIDDQ_OFF(0 << 13)
>>
>> +struct rockchip_usb_phys {
>> + int reg;
>> + const char *pll_name;
>> +};
>> +
>> +struct rockchip_usb_phy_pdata {
>> + struct rockchip_usb_phys *phys;
>> +};
>> +
>>  struct rockchip_usb_phy_base {
>>   struct device *dev;
>>   struct regmap *reg_base;
>> + const struct rockchip_usb_phy_pdata *pdata;
>>  };
>>
>>  struct rockchip_usb_phy {
>>   struct rockchip_usb_phy_base *base;
>> + struct device_node *np;
>>   unsigned intreg_offset;
>>   struct clk  *clk;
>> + struct clk  *clk480m;
>> + struct clk_hw   clk480m_hw;
>>   struct phy  *phy;
>>  };
>>
>> @@ -55,17 +70,59 @@ static int rockchip_usb_phy_power(struct 
>> rockchip_usb_phy *phy,
>>   SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
>>  }
>>
>> -static int rockchip_usb_phy_power_off(struct phy *_phy)
>> +static unsigned long rockchip_usb_phy480m_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>>  {
>> - struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
>> - int ret = 0;
>> + return 48000;
>> +}
>> +
>> +static void rockchip_usb_phy480m_disable(struct clk_hw *hw)
>> +{
>> + struct rockchip_usb_phy *phy = container_of(hw,
>> + struct rockchip_usb_phy,
>> + clk480m_hw);
>>
>>   /* Power down usb phy analog blocks by set siddq 1 */
>> - ret = rockchip_usb_phy_power(phy, 1);
>> - if (ret)
>> + rockchip_usb_phy_power(phy, 1);
>> +}
>> +
>> +static int rockchip_usb_phy480m_enable(struct clk_hw *hw)
>> +{
>> + struct rockchip_usb_phy *phy = container_of(hw,
>> + struct rockchip_usb_phy,
>> + clk480m_hw);
>> +
>> + /* Power up usb phy analog blocks by set siddq 0 */
>> + return rockchip_usb_phy_power(phy, 0);
>> +}
>> +
>> +static int rockchip_usb_phy480m_is_enabled(struct clk_hw *hw)
>> +{
>> + struct rockchip_usb_phy *phy = container_of(hw,
>> + struct rockchip_usb_phy,
>> +  

Re: [PATCH] staging: wilc1000: fix double mutex_unlock on failure path in wilc_wlan_cleanup()

[Greg Kroah-Hartman]

On Mon, Dec 21, 2015 at 12:46:51AM +0300, Alexey Khoroshilov wrote:
> If hif_read_reg() or hif_write_reg() fail in wilc_wlan_cleanup(),
> it calls release_bus() and continues execution. But it leads to double
> release_bus() call that means double unlock of g_linux_wlan->hif_cs mutex.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

Doesn't apply to my tree anymore, can you rebase this on the
staging-testing branch of staging.git?

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 v2 1/1] platform: goldfish: pipe: add devicetree bindings

[Greg Kroah-Hartman]

On Wed, Nov 25, 2015 at 11:59:37AM -0800, Jin Qian wrote:
> From: Greg Hackmann 
> 
> Signed-off-by: Greg Hackmann 
> (cherry picked from commit 3c56d07eb796066530e93a40e74dea3bc59bf4cf)

What is this commit id here for?

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: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, 2015-12-21 at 15:24 +, Måns Rullgård wrote:
>> Julian Margetson  writes:
>> 
>> 
>> Oh, that one again.  My patch still applies.  Here it is as applied
>> to
>> that revision of the file.
>> 
>> From what I can tell, that bug has always been there.  Probably
>> nobody
>> ever tested the driver in a PREEMPT or SMP build, nor with lock
>> debugging enabled.
>
> I guess it's a time to submit this one to upstream with proper Fixes:
> tag (which I suppose the initial commit of the driver).

Done.

-- 
Måns Rullgård
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Julian Margetson]

On 12/21/2015 1:55 PM, Andy Shevchenko wrote:

On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:

On 12/21/2015 12:48 PM, Andy Shevchenko wrote:

On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:

On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
 wrote:

On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
wrote:
I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
items on this board, however registers for SATA program it to 64. I
remember that I got no interrupt when I programmed transfer width
wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
on
Intel SoCs.

One more thing, I have a patch to monitor DMA IO, we may check what
exactly the values are written / read  in DMA. I can share it
tomorrow.

As promised the patch I have to debug IO of DW DMA. Didn't check though
if it applies cleanly on top of recent vanilla kernel.

So, the original driver (with patch from Måns) works, right?


The hard drive is recognized .
These system gets unresponsive with USB devices like the mouse and 
keyboard not responding  when I start Gparted.


--
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: [Intel-gfx] [PATCH] drm, i915: Fix pointer size cast

[Daniel Vetter]

On Mon, Dec 21, 2015 at 07:53:59PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov 
> 
> gcc complains on 32-bit like this:
> 
>   drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
>   drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from 
> \
> integer of different size [-Wint-to-pointer-cast]
> offset = (unsigned char *)vma->node.start;
>  ^
> 
> because vma->node.start is u64 but a pointer on 32-bit is 4 bytes.
> 
> Do the calculations with an unsigned long directly and save us the
> casts.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Borislav Petkov 

This has been fixed already in

commit 44eb0cb9620c6a53ec8e7073262e2af8079b727f
Author: Mika Kuoppala 
Date:   Fri Oct 30 13:26:15 2015 +0200

drm/i915: Avoid pointer arithmetic in calculating plane surface offset

Cheers,
Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 62211abe4922..640cb7c9b7f3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2941,7 +2941,7 @@ unsigned long intel_plane_obj_offset(struct intel_plane 
> *intel_plane,
>  {
>   const struct i915_ggtt_view *view = _ggtt_view_normal;
>   struct i915_vma *vma;
> - unsigned char *offset;
> + unsigned long offset;
>  
>   if (intel_rotation_90_or_270(intel_plane->base.state->rotation))
>   view = _ggtt_view_rotated;
> @@ -2951,14 +2951,14 @@ unsigned long intel_plane_obj_offset(struct 
> intel_plane *intel_plane,
>   view->type))
>   return -1;
>  
> - offset = (unsigned char *)vma->node.start;
> + offset = vma->node.start;
>  
>   if (plane == 1) {
>   offset += vma->ggtt_view.rotation_info.uv_start_page *
> PAGE_SIZE;
>   }
>  
> - return (unsigned long)offset;
> + return offset;
>  }
>  
>  static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
> -- 
> 2.3.5
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Julian Margetson]

On 12/21/2015 2:27 PM, Måns Rullgård wrote:

Julian Margetson  writes:


On 12/21/2015 1:55 PM, Andy Shevchenko wrote:

On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:

On 12/21/2015 12:48 PM, Andy Shevchenko wrote:

On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:

On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
 wrote:

On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
wrote:
I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
items on this board, however registers for SATA program it to 64. I
remember that I got no interrupt when I programmed transfer width
wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
on
Intel SoCs.

One more thing, I have a patch to monitor DMA IO, we may check what
exactly the values are written / read  in DMA. I can share it
tomorrow.

As promised the patch I have to debug IO of DW DMA. Didn't check though
if it applies cleanly on top of recent vanilla kernel.

So, the original driver (with patch from Måns) works, right?


The hard drive is recognized .
These system gets unresponsive with USB devices like the mouse and
keyboard not responding  when I start Gparted.

Did you disable the SATA and DMA debug messages?


It is working.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] um: Add seccomp support

[Mickaël Salaün]

This series add seccomp support to User-mode Linux (i386 and x86_64
subarchitectures) and fix ptrace issues. This apply on v4.4-rc4 and pass all
the 48 tests from selftest/seccomp plus the UML ptsc test.

Changes since v1; addressed Richard Weinberger's comments:
* fix a new PTRACE_SETREGS bug on x86_64 [1/4]
* fix an old PTRACE_SETREGS bug when updating orig_ax on i386 [1/4]

Regards,
 Mickaël

Mickaël Salaün (4):
  um: Fix ptrace GETREGS/SETREGS bugs
  selftests/seccomp: Remove the need for HAVE_ARCH_TRACEHOOK
  um: Add full asm/syscall.h support
  um: Add seccomp support

 .../seccomp/seccomp-filter/arch-support.txt|   2 +-
 arch/um/Kconfig.common |   1 +
 arch/um/Kconfig.um |  16 +++
 arch/um/include/asm/syscall-generic.h  | 138 +
 arch/um/include/asm/thread_info.h  |   2 +
 arch/um/kernel/skas/syscall.c  |  30 +++--
 arch/um/os-Linux/skas/process.c|   7 --
 arch/x86/um/asm/syscall.h  |   1 +
 arch/x86/um/ptrace_32.c|   8 +-
 tools/testing/selftests/seccomp/seccomp_bpf.c  |  27 +++-
 10 files changed, 205 insertions(+), 27 deletions(-)
 create mode 100644 arch/um/include/asm/syscall-generic.h

-- 
2.6.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: IO errors after "block: remove bio_get_nr_vecs()"

[Tejun Heo]

Hello, Artem.

Can you please apply the following patch on top and see whether
anything changes?  If it does make the issue go away, can you please
revert the ".can_queue" part and test again?

Thanks.

---
 drivers/ata/ahci.h|2 +-
 drivers/ata/libahci.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -365,7 +365,7 @@ extern struct device_attribute *ahci_sde
  */
 #define AHCI_SHT(drv_name) \
ATA_NCQ_SHT(drv_name),  \
-   .can_queue  = AHCI_MAX_CMDS - 1,\
+   .can_queue  = 1/*AHCI_MAX_CMDS - 1*/,   \
.sg_tablesize   = AHCI_MAX_SG,  \
.dma_boundary   = AHCI_DMA_BOUNDARY,\
.shost_attrs= ahci_shost_attrs, \
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -420,7 +420,7 @@ void ahci_save_initial_config(struct dev
hpriv->saved_cap2 = cap2 = 0;
 
/* some chips have errata preventing 64bit use */
-   if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {
+   if ((cap & HOST_CAP_64)/* && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)*/) {
dev_info(dev, "controller can't do 64bit DMA, forcing 32bit\n");
cap &= ~HOST_CAP_64;
}

-- 
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/

Re: [PATCH] x86/efi-bgrt: Replace early_memremap() with memremap()

[Josh Triplett]

On Mon, Dec 21, 2015 at 02:12:52PM +, Matt Fleming wrote:
> Môshe reported the following warning triggered on his machine since
> commit 50a0cb565246 ("x86/efi-bgrt: Fix kernel panic when mapping BGRT
> data"),
> 
>   [0.026936] [ cut here ]
>   [0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137 
> __early_ioremap+0x102/0x1bb()
>   [0.026941] Modules linked in:
>   [0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
>   [0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05 
> 07/14/2015
>   [0.026946]   900f03d5a116524d 81c03e60 
> 813a3fff
>   [0.026948]   81c03e98 810a0852 
> d7b76000
>   [0.026949]   0001 0001 
> 017c
>   [0.026951] Call Trace:
>   [0.026955]  [] dump_stack+0x44/0x55
>   [0.026958]  [] warn_slowpath_common+0x82/0xc0
>   [0.026959]  [] warn_slowpath_null+0x1a/0x20
>   [0.026961]  [] __early_ioremap+0x102/0x1bb
>   [0.026962]  [] early_memremap+0x13/0x15
>   [0.026964]  [] efi_bgrt_init+0x162/0x1ad
>   [0.026966]  [] efi_late_init+0x9/0xb
>   [0.026968]  [] start_kernel+0x46f/0x49f
>   [0.026970]  [] ? early_idt_handler_array+0x120/0x120
>   [0.026972]  [] x86_64_start_reservations+0x2a/0x2c
>   [0.026974]  [] x86_64_start_kernel+0x14a/0x16d
>   [0.026977] ---[ end trace f9b3812eb8e24c58 ]---
>   [0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory
> 
> early_memremap() has an upper limit on the size of mapping it can
> handle which is ~200KB. Clearly the BGRT image on Môshe's machine is
> much larger than that.
> 
> There's actually no reason to restrict ourselves to using the early_*
> version of memremap() - the ACPI BGRT driver is invoked late enough in
> boot that we can use the standard version, with the benefit that the
> late version allows mappings of arbitrary size.
> 
> Reported-by: Môshe van der Sterre 
> Tested-by: Môshe van der Sterre 
> Cc: Josh Triplett 
> Cc: Sai Praneeth Prakhya 
> Cc: Borislav Petkov 
> Signed-off-by: Matt Fleming 

Reviewed-by: Josh Triplett 

>  arch/x86/platform/efi/efi-bgrt.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/platform/efi/efi-bgrt.c 
> b/arch/x86/platform/efi/efi-bgrt.c
> index bf51f4c02562..b0970661870a 100644
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -72,14 +72,14 @@ void __init efi_bgrt_init(void)
>   return;
>   }
>  
> - image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header));
> + image = memremap(bgrt_tab->image_address, sizeof(bmp_header), 
> MEMREMAP_WB);
>   if (!image) {
>   pr_err("Ignoring BGRT: failed to map image header memory\n");
>   return;
>   }
>  
>   memcpy(_header, image, sizeof(bmp_header));
> - early_memunmap(image, sizeof(bmp_header));
> + memunmap(image);
>   bgrt_image_size = bmp_header.size;
>  
>   bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
> @@ -89,7 +89,7 @@ void __init efi_bgrt_init(void)
>   return;
>   }
>  
> - image = early_memremap(bgrt_tab->image_address, bmp_header.size);
> + image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
>   if (!image) {
>   pr_err("Ignoring BGRT: failed to map image memory\n");
>   kfree(bgrt_image);
> @@ -98,5 +98,5 @@ void __init efi_bgrt_init(void)
>   }
>  
>   memcpy(bgrt_image, image, bgrt_image_size);
> - early_memunmap(image, bmp_header.size);
> + memunmap(image);
>  }
> -- 
> 2.6.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: mm, vmstat: kernel BUG at mm/vmstat.c:1408!

[Sasha Levin]

On 12/21/2015 03:28 PM, Sasha Levin wrote:
> On 12/21/2015 08:08 AM, Christoph Lameter wrote:
>> > On Fri, 18 Dec 2015, Sasha Levin wrote:
>> > 
 >> > [  531.164630] RIP vmstat_update (mm/vmstat.c:1408)
>> > Hmmm.. Yes we need to fold the diffs first before disabling the timer
>> > otherwise the shepherd task may intervene.
>> > 
>> > Does this patch fix it?
> It didn't. With the patch I'm still seeing:

I've also noticed a new warning from the workqueue code which my scripts
didn't pick up before:

[ 3462.380681] BUG: workqueue lockup - pool cpus=2 node=2 flags=0x4 nice=0 
stuck for 54s!
[ 3462.522041] workqueue vmstat: flags=0xc
[ 3462.527795]   pwq 4: cpus=2 node=2 flags=0x0 nice=0 active=1/256
[ 3462.554836] pending: vmstat_update


Thanks,
Sasha
--
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 v1 2/2] dt-bindings: sound: add devicetree document for rt5616

[Frank Rowand]

On 12/21/2015 6:56 AM, Caesar Wang wrote:
> Add the description for rt5616 codec.
> 
> Signed-off-by: Caesar Wang 
> 
> ---
> 
> Changes in v1:
> - As Heiko comments, remove the not exist option properties.
> 
>  Documentation/devicetree/bindings/sound/rt5616.txt | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt 
> b/Documentation/devicetree/bindings/sound/rt5616.txt
> new file mode 100644
> index 000..2030a22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/rt5616.txt
> @@ -0,0 +1,36 @@
> +RT5616 audio CODEC
> +
> +This device supports I2C only.
> +
> +Required properties:
> +
> +- compatible : "realtek,rt5616".
> +
> +- reg : The I2C address of the device.
> +
> +Pins on the device (for linking into audio routes) for RT5616:
> +
> +  * IN1P
> +  * IN2P
> +  * IN2N
> +  * LOUTL
> +  * LOUTR
> +  * CPN2
> +  * CPP2
> +  * CPN1
> +  * CPP1
> +  * HPO_R
> +  * HPO_L
> +  * ADCDAT1
> +  * DACDAT1
> +  * LRCK1
> +  * BCLK1
> +  * MCLK
> +  * GPIO1
> +
> +Example:
> +
> +rt5616 {

The node name should be rt5616@1b (including the reg value
from the node).

> + compatible = "realtek,rt5616";
> + reg = <0x1b>;
> +};
> 

--
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] blackfin-cpufreq: Change return type of cpu_set_cclk() to that of clk_set_rate()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 21:56:27 +0100

The return type "unsigned long" was used by the cpu_set_cclk() function
while the type "int" is provided by the clk_set_rate() function.
Let us make this usage consistent.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
Acked-by: Viresh Kumar 
---
 drivers/cpufreq/blackfin-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/blackfin-cpufreq.c 
b/drivers/cpufreq/blackfin-cpufreq.c
index a9f8e5b..2a6f3ac 100644
--- a/drivers/cpufreq/blackfin-cpufreq.c
+++ b/drivers/cpufreq/blackfin-cpufreq.c
@@ -112,7 +112,7 @@ static unsigned int bfin_getfreq_khz(unsigned int cpu)
 }
 
 #ifdef CONFIG_BF60x
-unsigned long cpu_set_cclk(int cpu, unsigned long new)
+int cpu_set_cclk(int cpu, unsigned long new)
 {
struct clk *clk;
int ret;
-- 
2.6.3

--
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] blackfin-cpufreq: Mark cpu_set_cclk() as static

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 22:12:26 +0100

The cpu_set_cclk() function was only used in a single source file so far.
Indicate this setting also by the corresponding linkage specifier.

Signed-off-by: Markus Elfring 
Acked-by: Viresh Kumar 
---
 drivers/cpufreq/blackfin-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/blackfin-cpufreq.c 
b/drivers/cpufreq/blackfin-cpufreq.c
index 2a6f3ac..12e97d8 100644
--- a/drivers/cpufreq/blackfin-cpufreq.c
+++ b/drivers/cpufreq/blackfin-cpufreq.c
@@ -112,7 +112,7 @@ static unsigned int bfin_getfreq_khz(unsigned int cpu)
 }
 
 #ifdef CONFIG_BF60x
-int cpu_set_cclk(int cpu, unsigned long new)
+static int cpu_set_cclk(int cpu, unsigned long new)
 {
struct clk *clk;
int ret;
-- 
2.6.3

--
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-after-free in skcipher_sock_destruct

[Stephan Mueller]

Am Donnerstag, 17. Dezember 2015, 13:56:12 schrieb Dmitry Vyukov:

Hi Dmitry,

> Hello,
> 
> The following program triggers use-after-free in skcipher_sock_destruct:

This issue is not evident after applying  Herbert's patch converting the 
algif_skcipher from using ablkcipher to skcipher API.
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> struct sockaddr_alg {
> unsigned short   salg_family;
> charsalg_type[14];
> unsigned   salg_feat;
> unsigned   salg_mask;
> charsalg_name[64];
> };
> 
> int fd;
> 
> void *thr0(void *arg)
> {
> struct sockaddr_alg sa = {};
> sa.salg_family = 0x26;
> memcpy(sa.salg_type,
> "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14);
> sa.salg_feat = 0xf;
> sa.salg_mask = 0x100;
> memcpy(sa.salg_name,
> "\x65\x63\x62\x28\x73\x65\x72\x70\x65\x6e\x74\x29\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00", 64);
> bind(fd, (struct sockaddr*), sizeof(sa));
> return 0;
> }
> 
> void *thr1(void *arg)
> {
> accept4(fd, 0, 0, 0x800ul);
> return 0;
> }
> 
> int main()
> {
> fd = socket(PF_ALG, SOCK_SEQPACKET, 0);
> pthread_t th[4];
> pthread_create([0], 0, thr0, 0);
> pthread_create([1], 0, thr1, 0);
> pthread_create([2], 0, thr0, 0);
> pthread_create([3], 0, thr1, 0);
> pthread_join(th[0], 0);
> pthread_join(th[1], 0);
> pthread_join(th[2], 0);
> pthread_join(th[3], 0);
> return 0;
> }
> 
> 
> ==
> BUG: KASAN: use-after-free in skcipher_sock_destruct+0x39c/0x3e0 at
> addr 8800387a2d38
> Read of size 4 by task executor/27423
> 
> = BUG kmalloc-96 (Not tainted): kasan: bad access detected
> 
> -
> 
> Disabling lock debugging due to kernel taint
> INFO: Allocated in __crypto_alloc_tfm+0xd9/0x470 age=36 cpu=0 pid=27396
> [<  none  >] __kmalloc+0x2d9/0x480 mm/slub.c:3532
> [< inline >] kmalloc include/linux/slab.h:463
> [< inline >] kzalloc include/linux/slab.h:602
> [<  none  >] __crypto_alloc_tfm+0xd9/0x470 crypto/api.c:374
> [<  none  >] crypto_alloc_ablkcipher+0x7b/0x1f0
> crypto/ablkcipher.c:699 [<  none  >] skcipher_bind+0x25/0x30
> crypto/algif_skcipher.c:754 [<  none  >] alg_bind+0x1a9/0x410
> crypto/af_alg.c:155
> [<  none  >] SYSC_bind+0x20a/0x2c0 net/socket.c:1383
> [<  none  >] SyS_bind+0x24/0x30 net/socket.c:1369
> [<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> INFO: Freed in kzfree+0x28/0x30 age=26 cpu=2 pid=27421
> [<  none  >] kfree+0x26f/0x3e0 mm/slub.c:3632
> [<  none  >] kzfree+0x28/0x30 mm/slab_common.c:1270
> [<  none  >] crypto_destroy_tfm+0xdd/0x1e0 crypto/api.c:596
> [< inline >] crypto_free_tfm include/linux/crypto.h:623
> [< inline >] crypto_free_ablkcipher include/linux/crypto.h:769
> [<  none  >] skcipher_release+0x18/0x20 crypto/algif_skcipher.c:759
> [< inline >] alg_do_release crypto/af_alg.c:116
> [<  none  >] alg_bind+0x26a/0x410 crypto/af_alg.c:170
> [<  none  >] SYSC_bind+0x20a/0x2c0 net/socket.c:1383
> [<  none  >] SyS_bind+0x24/0x30 net/socket.c:1369
> [<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> INFO: Slab 0xeae1e880 objects=19 used=8 fp=0x8800387a3380
> flags=0x1fffc004080
> INFO: Object 0x8800387a2d00 @offset=3328 fp=0x8800387a3520
> CPU: 0 PID: 27423 Comm: executor Tainted: GB   4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  880035c67700 82e0f4b8 41b58ab3
> 87a9a265 82e0f406 880037f15a00 87abb3aa
> 88003e804780 0008 8800387a2d00 880035c67700
> 
> Call Trace:
>  [] __asan_report_load4_noabort+0x54/0x70
> mm/kasan/report.c:294
>  [< inline >] crypto_ablkcipher_ivsize include/linux/crypto.h:807
>  [] skcipher_sock_destruct+0x39c/0x3e0
> crypto/algif_skcipher.c:787
>  [] sk_destruct+0xa5/0x5f0 net/core/sock.c:1446
>  [] __sk_free+0x8c/0x260 net/core/sock.c:1474
>  [] sk_free+0x30/0x40 net/core/sock.c:1485
>  [< inline >] sock_put include/net/sock.h:1625
>  [] af_alg_release+0x60/0x90 crypto/af_alg.c:123
>  [] sock_release+0x96/0x260 net/socket.c:571
>  [] sock_close+0x16/0x20 net/socket.c:1022
>  [] __fput+0x244/0x860 

Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Catalin Marinas]

On Fri, Dec 18, 2015 at 01:47:55PM +0100, Arnd Bergmann wrote:
> On Friday 18 December 2015 11:42:19 Catalin Marinas wrote:
> > On Thu, Dec 17, 2015 at 12:14:20PM -0800, Andrew Pinski wrote:
> > > Well (just like LP64 on AARCH64), when passing a 32bit value to a
> > > function, the upper 32bits are undefined.  I ran into this when I was
> > > debugging the GCC go library on ILP32 (though reproduced with pure C
> > > code) and the assembly functions inside glibc where pointers are
> > > passed with the upper 32bits as undefined.
> > > So we have an issue if called with syscall function or using pure
> > > assembly to create the syscall functions (which glibc does).
> > 
> > I think the ILP32 syscall ABI should follow the PCS convention where the
> > top 32-bit of a register is not guaranteed 0 when the size of the
> > argument is 32-bit. So take the read(2) syscall:
> > 
> > ssize_t read(int fd, void *buf, size_t count);
> > 
> > From the ILP32 code perspective, void * and size_t are both 32-bit. It
> > would call into the kernel leaving the top 32-bit as undefined (if we
> > follow the PCS). Normally, calling a function with the same size
> > arguments is not a problem since the compiler generates the callee code
> > accordingly. However, we route the syscall directly into the native
> > sys_read() where void * and size_t are 64-bit with the top 32-bit left
> > undefined.
> > 
> > We have three options here:
> > 
> > 1. Always follow PCS convention across user/kernel call and add wrappers
> >in the kernel (preferred)
> 
> Yes, I also think this is best.
> 
> > 2. Follow the PCS up to glibc and get glibc to zero the top part (not
> >always safe with hand-written assembly, though we already do this for
> >AArch32 where the PCS only specifies 4 arguments in registers, the
> >rest go on the stack)
> 
> I assume this needs special handling for syscalls with 64-bit arguments
> in both glibc and kernel.

I think glibc only should suffice, if it is its responsibility to zero
the top 32-bit part.

> > 3. Follow the PCS up to glibc but always pass syscall arguments in W
> >registers, like AArch32 compat support (the least preferred option,
> >the only advantage is a single wrapper for all syscalls but it would
> >be doing unnecessary zeroing even for syscalls where it isn't needed)
> 
> This would mean we cannot pass 64-bit arguments in registers, right?

Not in a single register but two (like we do on AArch32).

> > My preference, as stated above, is (1). You can write the wrappers in C
> > directly and let the compiler upgrade the types when calling the native
> > syscall. But any other option would be fine (take some inspiration from
> > other architectures). Unfortunately we don't have COMPAT_SYSCALL_DEFINE
> > for all functions that we need to wrap, it would have been easier (so we
> > need to add them but probably in the arch/arm64 code).
> 
> It would be nice to have that code architecture-independent, so we can
> share it with s390 and only need to update one place when new syscalls
> get added.

We could indeed move things like:

COMPAT_SYSCALL_DEFINE3(s390_read, unsigned int, fd, char __user *, buf, 
compat_size_t, count)

to the core code and share them between s390 and arm64/ILP32. So let's
stick to option 1.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/4] staging: lustre: Delete unnecessary goto statements in six functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 21 Dec 2015 18:15:45 +0100

Six goto statements referred to a source code position
directly behind them.
Thus omit such unnecessary jumps.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/llite/namei.c | 1 -
 drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ---
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 64db5e8..2113dd4 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, 
struct dentry *dentry,
retval = NULL;
else
retval = dentry;
-   goto out;
  out:
if (req)
ptlrpc_req_finished(req);
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 294c050..920b1e9 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp,
ptlrpc_request_set_replen(req);
 
rc = mdc_queue_wait(req);
-   goto out;
 out:
ptlrpc_req_finished(req);
return rc;
@@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import 
*imp, __u32 archives)
ptlrpc_request_set_replen(req);
 
rc = mdc_queue_wait(req);
-   goto out;
 out:
ptlrpc_req_finished(req);
return rc;
@@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import 
*imp)
ptlrpc_request_set_replen(req);
 
rc = mdc_queue_wait(req);
-   goto out;
 out:
ptlrpc_req_finished(req);
return rc;
@@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp,
ptlrpc_request_set_replen(req);
 
rc = mdc_queue_wait(req);
-   goto out;
-
 out:
ptlrpc_req_finished(req);
return rc;
@@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp,
ptlrpc_request_set_replen(req);
 
rc = mdc_queue_wait(req);
-   goto out;
-
 out:
ptlrpc_req_finished(req);
return rc;
-- 
2.6.3

--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Julian Margetson]

On 12/21/2015 2:27 PM, Måns Rullgård wrote:

Julian Margetson  writes:


On 12/21/2015 1:55 PM, Andy Shevchenko wrote:

On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:

On 12/21/2015 12:48 PM, Andy Shevchenko wrote:

On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:

On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
 wrote:

On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
wrote:
I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
items on this board, however registers for SATA program it to 64. I
remember that I got no interrupt when I programmed transfer width
wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
on
Intel SoCs.

One more thing, I have a patch to monitor DMA IO, we may check what
exactly the values are written / read  in DMA. I can share it
tomorrow.

As promised the patch I have to debug IO of DW DMA. Didn't check though
if it applies cleanly on top of recent vanilla kernel.

So, the original driver (with patch from Måns) works, right?


The hard drive is recognized .
These system gets unresponsive with USB devices like the mouse and
keyboard not responding  when I start Gparted.

Did you disable the SATA and DMA debug messages?


Ah. Will try with debug disabled.


--
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: [PATCHV3 1/3] x86, ras: Add new infrastructure for machine check fixup tables

[Dan Williams]

On Mon, Dec 21, 2015 at 10:18 AM, Borislav Petkov  wrote:
> On Tue, Dec 15, 2015 at 05:29:30PM -0800, Tony Luck wrote:
>> Copy the existing page fault fixup mechanisms to create a new table
>> to be used when fixing machine checks. Note:
>> 1) At this time we only provide a macro to annotate assembly code
>> 2) We assume all fixups will in code builtin to the kernel.
>> 3) Only for x86_64
>> 4) New code under CONFIG_MCE_KERNEL_RECOVERY (default 'n')
>>
>> Signed-off-by: Tony Luck 
>> ---
>>  arch/x86/Kconfig  | 10 ++
>>  arch/x86/include/asm/asm.h| 10 --
>>  arch/x86/include/asm/mce.h| 14 ++
>>  arch/x86/kernel/cpu/mcheck/mce.c  | 16 
>>  arch/x86/kernel/vmlinux.lds.S |  6 +-
>>  arch/x86/mm/extable.c | 19 +++
>>  include/asm-generic/vmlinux.lds.h | 12 +++-
>>  7 files changed, 79 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 96d058a87100..42d26b4d1ec4 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1001,6 +1001,16 @@ config X86_MCE_INJECT
>> If you don't know what a machine check is and you don't do kernel
>> QA it is safe to say n.
>>
>> +config MCE_KERNEL_RECOVERY
>> + bool "Recovery from machine checks in special kernel memory copy 
>> functions"
>> + default n
>> + depends on X86_MCE && X86_64
>
> Still no dependency on CONFIG_LIBNVDIMM.

I suggested we reverse the dependency and have the driver optionally
"select MCE_KERNEL_RECOVERY".  There may be other drivers outside of
LIBNVDIMM that want this functionality enabled.
--
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: vt: use memdup_user to reuse the code

[Dmitry Torokhov]

On Sun, Dec 20, 2015 at 12:15:33AM +0530, Rahul Pathak wrote:
> Fixing coccicheck warning which recommends to use memdup_user instead
> to reimplement its code, using memdup_user simplifies the code
> 
> ./drivers/tty/vt/keyboard.c:1709:9-16: WARNING opportunity for memdup_user
> ./drivers/tty/vt/keyboard.c:1752:9-16: WARNING opportunity for memdup_user
> 
> Signed-off-by: Rahul Pathak 

Acked-by: Dmitry Torokhov 

(assuming Greg will pick it up, otherwise I can take it through my
tree).

Thanks.

> ---
>  drivers/tty/vt/keyboard.c | 28 
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index 6f0336f..ec05360 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -1706,16 +1706,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
> int perm)
>   return -EINVAL;
>  
>   if (ct) {
> - dia = kmalloc(sizeof(struct kbdiacr) * ct,
> - GFP_KERNEL);
> - if (!dia)
> - return -ENOMEM;
> -
> - if (copy_from_user(dia, a->kbdiacr,
> - sizeof(struct kbdiacr) * ct)) {
> - kfree(dia);
> - return -EFAULT;
> - }
> + dia = memdup_user(a->kbdiacr,
> + sizeof(struct kbdiacr) * ct);
> + if (IS_ERR(dia))
> + return PTR_ERR(dia);
>   }
>  
>   spin_lock_irqsave(_event_lock, flags);
> @@ -1749,16 +1743,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
> int perm)
>   return -EINVAL;
>  
>   if (ct) {
> - buf = kmalloc(ct * sizeof(struct kbdiacruc),
> - GFP_KERNEL);
> - if (buf == NULL)
> - return -ENOMEM;
> -
> - if (copy_from_user(buf, a->kbdiacruc,
> - ct * sizeof(struct kbdiacruc))) {
> - kfree(buf);
> - return -EFAULT;
> - }
> + buf = memdup_user(a->kbdiacruc,
> + sizeof(struct kbdiacruc) * ct);
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
>   } 
>   spin_lock_irqsave(_event_lock, flags);
>   if (ct)
> -- 
> 2.1.4
> 

-- 
Dmitry
--
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] crypto: AF_ALG - add support for keys/asymmetric-type

[Tadeusz Struk]

From: Tadeusz Struk 

Created on top of patchset from Stephan Mueller 
https://patchwork.kernel.org/patch/7877921/
https://patchwork.kernel.org/patch/7877971/
https://patchwork.kernel.org/patch/7877961/

This patch adds support for asymmetric key type to AF_ALG.
It will work as follows: A new PF_ALG socket options will be
added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
ALG_SET_PUBKEY_ID and ALG_SET_KEY_ID for setting public and
private keys respectively. When these new options will be used
the user instead of providing the key material, will provide a
key id and the key itself will be obtained from kernel keyring
subsystem. The user will use the standard tools (keyctl tool
or the keyctl syscall) for key instantiation and to obtain the
key id. The key id can also be obtained by reading the
/proc/keys file.

When a key will be found, the request_key() function will
return a requested key. Next the asymmetric key subtype will be
used to obtain the public_key, which can be either a public key
or a private key from the cryptographic point of view, and the
key payload will be passed to the akcipher pf_alg subtype.
Pf_alg code will then call crypto API functions, either the
crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
depending on the used option. Subsequently the asymmetric key
will be freed and return code returned back to the user.

Currently the interface will be restricted only to asymmetric
ciphers, but it can be extended later to work with symmetric
ciphers if required.

The assumption is that access rights for a given user will be
verified by the key subsystem so the pf_alg interface can call
the request_key() without checking if the user has appropriate
rights (Please verify this assumption).

Signed-off-by: Tadeusz Struk 
---
 crypto/af_alg.c |   41 +
 include/uapi/linux/if_alg.h |2 ++
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 767a134..d2ec357 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct alg_type_list {
const struct af_alg_type *type;
@@ -173,7 +175,7 @@ static int alg_bind(struct socket *sock, struct sockaddr 
*uaddr, int addr_len)
 }
 
 static int alg_setkey(struct sock *sk, char __user *ukey,
- unsigned int keylen,
+ unsigned int keylen, bool key_id,
  int (*setkey)(void *private, const u8 *key,
unsigned int keylen))
 {
@@ -192,7 +194,30 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
if (copy_from_user(key, ukey, keylen))
goto out;
 
-   err = setkey(ask->private, key, keylen);
+   if (key_id) {
+   struct key *keyring;
+   struct public_key *pkey;
+   char key_name[12];
+   u32 keyid = *((u32 *)key);
+
+   sprintf(key_name, "id:%08x", keyid);
+   keyring = request_key(_type_asymmetric, key_name, NULL);
+
+   err = -ENOKEY;
+   if (IS_ERR(keyring))
+   goto out;
+
+   pkey = keyring->payload.data[asym_crypto];
+   if (!pkey) {
+   key_put(keyring);
+   goto out;
+   }
+
+   err = setkey(ask->private, pkey->key, pkey->keylen);
+   key_put(keyring);
+   } else {
+   err = setkey(ask->private, key, keylen);
+   }
 
 out:
sock_kzfree_s(sk, key, keylen);
@@ -207,6 +232,8 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
struct alg_sock *ask = alg_sk(sk);
const struct af_alg_type *type;
int err = -ENOPROTOOPT;
+   bool key_id = ((optname == ALG_SET_PUBKEY_ID) ||
+  (optname == ALG_SET_KEY_ID));
 
lock_sock(sk);
type = ask->type;
@@ -216,16 +243,22 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
 
switch (optname) {
case ALG_SET_KEY:
+   case ALG_SET_KEY_ID:
if (sock->state == SS_CONNECTED)
goto unlock;
 
-   err = alg_setkey(sk, optval, optlen, type->setkey);
+   /* ALG_SET_KEY_ID is only for akcipher */
+   if (!strcmp(type->name, "akcipher") && key_id)
+   goto unlock;
+
+   err = alg_setkey(sk, optval, optlen, key_id, type->setkey);
break;
case ALG_SET_PUBKEY:
+   case ALG_SET_PUBKEY_ID:
if (sock->state == SS_CONNECTED)
goto unlock;
 
-   err = alg_setkey(sk, optval, optlen, type->setpubkey);
+   err = alg_setkey(sk, optval, optlen, key_id, type->setpubkey);

Re: [PATCH v3 1/3] ACPI: amba bus probing support

[G Gregory]

On 21 December 2015 at 18:19, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 6:41 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> On ARM64 some devices use the AMBA device and not the platform bus for
>> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
>> does not have a suitable clock representation and to keep the core
>> AMBA bus code unchanged between probing methods.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/acpi/Makefile|   1 +
>>  drivers/acpi/acpi_amba.c | 149 
>> +++
>>  drivers/acpi/internal.h  |   5 ++
>>  3 files changed, 155 insertions(+)
>>  create mode 100644 drivers/acpi/acpi_amba.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 675eaf3..3cf732f 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -43,6 +43,7 @@ acpi-y+= pci_root.o 
>> pci_link.o pci_irq.o
>>  acpi-y += acpi_lpss.o acpi_apd.o
>>  acpi-y += acpi_platform.o
>>  acpi-y += acpi_pnp.o
>> +acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
>>  acpi-y += int340x_thermal.o
>>  acpi-y += power.o
>>  acpi-y += event.o
>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>> new file mode 100644
>> index 000..ebc8913
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_amba.c
>> @@ -0,0 +1,149 @@
>> +
>> +/*
>> + * ACPI support for platform bus type.
>> + *
>> + * Copyright (C) 2015, Linaro Ltd
>> + * Authors: Graeme Gregory 
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "internal.h"
>> +
>> +static const struct acpi_device_id amba_id_list[] = {
>> +   {"ARMH0011", 0}, /* PL011 SBSA Uart */
>> +   {"ARMH0061", 0}, /* PL061 GPIO Device */
>> +   {"", 0},
>> +};
>> +
>> +static struct clk *amba_dummy_clk;
>> +
>> +static void amba_register_dummy_clk(void)
>> +{
>> +   struct clk *clk;
>> +
>> +   /* If clock already registered */
>> +   if (amba_dummy_clk)
>> +   return;
>> +
>> +   clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 
>> 0);
>> +   clk_register_clkdev(clk, "apb_pclk", NULL);
>> +
>> +   amba_dummy_clk = clk;
>> +}
>> +
>> +static int amba_handler_attach(struct acpi_device *adev,
>> +   const struct acpi_device_id *id)
>> +{
>> +   struct amba_device *dev = NULL;
>> +   struct acpi_device *acpi_parent;
>> +   struct resource_entry *rentry;
>> +   struct list_head resource_list;
>> +   struct resource *resources = NULL;
>> +   bool address_found = false;
>> +   int ret, count, irq_no = 0;
>> +
>> +   /* If the ACPI node already has a physical device attached, skip it. 
>> */
>> +   if (adev->physical_node_count)
>> +   return 0;
>> +
>> +   amba_register_dummy_clk();
>> +
>> +   dev = amba_device_alloc(NULL, 0, 0);
>> +   if (!dev) {
>> +   pr_err("%s(): amba_device_alloc() failed for %s\n",
>
> Can it be dev_err(>dev, …); ?
> Same for below cases.
>
Yes it probably can, I took the code directly from DT version and
didn't think of using adev->dev directly.

Graeme

>> +  __func__, dev_name(>dev));
>> +   return 0;
>> +   }
>> +
>> +   INIT_LIST_HEAD(_list);
>
>> +   count = acpi_dev_get_resources(adev, _list, NULL, NULL);
>> +   if (count < 0) {
>> +   return 0;
>> +   } else if (count > 0) {
>> +   resources = kmalloc_array(count, sizeof(struct resource),
>> +   GFP_KERNEL);
>> +   if (!resources) {
>> +   acpi_dev_free_resource_list(_list);
>> +   return 0;
>> +   }
>> +   count = 0;
>> +   list_for_each_entry(rentry, _list, node) {
>> +   switch (resource_type(rentry->res)) {
>> +   case IORESOURCE_MEM:
>> +   if (!address_found) {
>> +   dev->res = *rentry->res;
>> +   address_found = true;
>> +   }
>> +   break;
>> +   case IORESOURCE_IRQ:
>> +   if (irq_no < AMBA_NR_IRQS)
>> +  

Re: [PATCH 4/5] pinctrl: rockchip: add missing of_node_put

[Heiko Stübner]

Hi Julia,

Am Montag, 21. Dezember 2015, 17:39:47 schrieb Julia Lawall:
> for_each_child_of_node performs an of_node_get on each iteration, so a
> return from the loop requires an of_node_put.
> 
> A simplified version of the semantic patch that fixes this problem is as
> follows (http://coccinelle.lip6.fr):
> 
> // 
> @@
> local idexpression n;
> expression e,e1;
> @@
> 
>  for_each_child_of_node(e1,n) {
>...
> (
>of_node_put(n);
> 
>e = n
> 
>return n;
> 
> +  of_node_put(n);
> ?  return ...;
> )
>...
>  }
> // 
> 
> Signed-off-by: Julia Lawall 

thanks for catching this :-)

I still remember how we talked about that same issue in the phy driver and the 
things for_each_child_of_node does when running, so

Reviewed-by: Heiko Stuebner 


Thanks
Heiko
--
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] ata: sata_dwc_460ex: remove incorrect locking

[Mans Rullgard]

This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error.  Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.

Enabling lock debugging gives the following output:

=
[ INFO: possible recursive locking detected ]
4.4.0-rc5+ #189 Not tainted
-
kworker/u2:3/37 is trying to acquire lock:
 (&(>lock)->rlock){-.-...}, at: [<90283294>] 
sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c

but task is already holding lock:
 (&(>lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(&(>lock)->rlock);
  lock(&(>lock)->rlock);

 *** DEADLOCK ***
 May be due to missing lock nesting notation

4 locks held by kworker/u2:3/37:
 #0:  ("events_unbound"){.+.+.+}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #1:  ((>work)){+.+.+.}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #2:  (>bd_mutex){+.+.+.}, at: [<9011fd54>] __blkdev_get+0x50/0x380
 #3:  (&(>lock)->rlock){-.-...}, at: [<902761ac>] 
ata_scsi_queuecmd+0x2c/0x330

stack backtrace:
CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
Workqueue: events_unbound async_run_entry_fn
Stack : 90b38e30 0021 0003 9b2a6040  9005f3f0 904fc8dc 0025
906b96e4  90528648 9b3336c4 904fc8dc 9009bf18 0002 0004
  9b3336c4 9b3336e4 904fc8dc 9003d074  9050
9005e738       
6e657665 755f7374 756f626e 646e   9b00ca00 9b025000
  ...
Call Trace:
[<90009d6c>] show_stack+0x88/0xa4
[<90057744>] __lock_acquire+0x1ce8/0x2154
[<900583e4>] lock_acquire+0x64/0x8c
[<9045ff10>] _raw_spin_lock_irqsave+0x54/0x78
[<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
[<90283484>] sata_dwc_qc_issue+0x1a8/0x24c
[<9026b39c>] ata_qc_issue+0x1f0/0x410
[<90273c6c>] ata_scsi_translate+0xb4/0x200
[<90276234>] ata_scsi_queuecmd+0xb4/0x330
[<9025800c>] scsi_dispatch_cmd+0xd0/0x128
[<90259934>] scsi_request_fn+0x58c/0x638
[<901a3e50>] __blk_run_queue+0x40/0x5c
[<901a83d4>] blk_queue_bio+0x27c/0x28c
[<901a5914>] generic_make_request+0xf0/0x188
[<901a5a54>] submit_bio+0xa8/0x194
[<9011adcc>] submit_bh_wbc.isra.23+0x15c/0x17c
[<9011c908>] block_read_full_page+0x3e4/0x428
[<9009e2e0>] do_read_cache_page+0xac/0x210
[<9009fd90>] read_cache_page+0x18/0x24
[<901bbd18>] read_dev_sector+0x38/0xb0
[<901bd174>] msdos_partition+0xb4/0x5c0
[<901bcb8c>] check_partition+0x140/0x274
[<901bba60>] rescan_partitions+0xa0/0x2b0
[<9011ff68>] __blkdev_get+0x264/0x380
[<901201ac>] blkdev_get+0x128/0x36c
[<901b9378>] add_disk+0x3c0/0x4bc
[<90268268>] sd_probe_async+0x100/0x224
[<90043a44>] async_run_entry_fn+0x50/0x124
[<9003a11c>] process_one_work+0x1a4/0x430
[<9003a4f4>] worker_thread+0x14c/0x4fc
[<900408f4>] kthread+0xd0/0xe8
[<90004338>] ret_from_kernel_thread+0x14/0x1c

Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Signed-off-by: Mans Rullgard 
---
 drivers/ata/sata_dwc_460ex.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 902034991517..7a7faca0ddcd 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -924,15 +924,13 @@ static void sata_dwc_exec_command_by_tag(struct ata_port 
*ap,
 struct ata_taskfile *tf,
 u8 tag, u32 cmd_issued)
 {
-   unsigned long flags;
struct sata_dwc_device_port *hsdevp = HSDEVP_FROM_AP(ap);
 
dev_dbg(ap->dev, "%s cmd(0x%02x): %s tag=%d\n", __func__, tf->command,
ata_get_cmd_descript(tf->command), tag);
 
-   spin_lock_irqsave(>host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
-   spin_unlock_irqrestore(>host->lock, flags);
+
/*
 * Clear SError before executing a new command.
 * sata_dwc_scr_write and read can not be used here. Clearing the PM
-- 
2.6.3

--
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 v6 3/3] tty: 8250_omap: Use software emulated RS485 direction control

[Matwey V. Kornilov]

Use software emulated RS485 direction control to provide RS485 API existed in
omap_serial driver. Note that 8250_omap issues interrupt on shift register
empty which is single prerequesite for using software emulated RS485.

Signed-off-by: Matwey V. Kornilov 
---
 drivers/tty/serial/8250/8250_omap.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
index 826c5c4..323c0a4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -698,6 +698,23 @@ static void omap_8250_throttle(struct uart_port *port)
pm_runtime_put_autosuspend(port->dev);
 }
 
+static int omap_8250_rs485_config(struct uart_port *port, struct serial_rs485 
*rs485)
+{
+   struct uart_8250_port *up = up_to_u8250p(port);
+
+   if (rs485->flags & SER_RS485_ENABLED && !serial8250_em485_enabled(up)) {
+   port->rs485 = *rs485;
+   return serial8250_em485_init(up);
+   }
+
+   if (serial8250_em485_enabled(up) && !(rs485->flags & SER_RS485_ENABLED))
+   serial8250_em485_destroy(up);
+
+   port->rs485 = *rs485;
+
+   return 0;
+}
+
 static void omap_8250_unthrottle(struct uart_port *port)
 {
unsigned long flags;
@@ -1144,6 +1161,7 @@ static int omap8250_probe(struct platform_device *pdev)
up.port.shutdown = omap_8250_shutdown;
up.port.throttle = omap_8250_throttle;
up.port.unthrottle = omap_8250_unthrottle;
+   up.port.rs485_config = omap_8250_rs485_config;
 
if (pdev->dev.of_node) {
const struct of_device_id *id;
-- 
2.6.3

--
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/1] Drivers: hv: vmbus: fix the building warning with hyperv-keyboard

[K. Y. Srinivasan]

From: Dexuan Cui 

With the recent change af3ff643ea91ba64dd8d0b1cbed54d44512f96cd
(Drivers: hv: vmbus: Use uuid_le type consistently), we always get this
warning:

  CC [M]  drivers/input/serio/hyperv-keyboard.o
drivers/input/serio/hyperv-keyboard.c:427:2: warning: missing braces around
initializer [-Wmissing-braces]
  { HV_KBD_GUID, },
  ^
drivers/input/serio/hyperv-keyboard.c:427:2: warning: (near initialization
for .id_table[0].guid.b.) [-Wmissing-braces]

The patch fixes the warning.

Signed-off-by: Dexuan Cui 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/input/serio/hyperv-keyboard.c |   10 --
 include/linux/hyperv.h|8 
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/input/serio/hyperv-keyboard.c 
b/drivers/input/serio/hyperv-keyboard.c
index e74e5d6..c948866 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -412,16 +412,6 @@ static int hv_kbd_remove(struct hv_device *hv_dev)
return 0;
 }
 
-/*
- * Keyboard GUID
- * {f912ad6d-2b17-48ea-bd65-f927a61c7684}
- */
-#define HV_KBD_GUID \
-   .guid = { \
-   0x6d, 0xad, 0x12, 0xf9, 0x17, 0x2b, 0xea, 0x48, \
-   0xbd, 0x65, 0xf9, 0x27, 0xa6, 0x1c, 0x76, 0x84 \
-   }
-
 static const struct hv_vmbus_device_id id_table[] = {
/* Keyboard guid */
{ HV_KBD_GUID, },
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 179ff33..753dbad 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1079,6 +1079,14 @@ u64 hv_do_hypercall(u64 control, void *input, void 
*output);
0x8b, 0xa1, 0xa1, 0xf3, 0xf9, 0x5a)
 
 /*
+ * Keyboard GUID
+ * {f912ad6d-2b17-48ea-bd65-f927a61c7684}
+ */
+#define HV_KBD_GUID \
+   .guid = UUID_LE(0xf912ad6d, 0x2b17, 0x48ea, 0xbd, 0x65, \
+   0xf9, 0x27, 0xa6, 0x1c, 0x76, 0x84)
+
+/*
  * VSS (Backup/Restore) GUID
  */
 #define HV_VSS_GUID \
-- 
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: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Andy Shevchenko]

On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote:
> Andy Shevchenko  writes:
> 
> > P.S. I also noticed that original driver enables interrupt per each
> > block
> 
> And then ignores all but the transfer complete interrupt.
> 
> > and sets protection control bits.
> 
> With no indication what the value it sets is supposed to mean.

Okay, let's summarize what we have:

0. AR: Get a working reference for PPC 460EX SATA driver
1. AR: Clear LLP_EN bits at the last block of LLP transfer
2. AR: Rename masters to 'memory' and 'peripheral' and change them per
DMA direction
3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers
4. CHECK: PROTCTL bit (documentation says that recommended value is
0x01)
5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE)
6. CHECK: Block interrupts vs. one interrupt at the end of block chain
(Måns, I missed how any of them is ignored)
7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, etc
(SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard SATA)


I can share my working branch with a set of patches regarding to
dw_dmac. We may do our work based on that code and after I'll submit
everything to upstream. Does it sound okay for you, guys?

-- 
Andy Shevchenko 
Intel Finland Oy

--
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] ipv6/addrlabel: fix ip6addrlbl_get()

[Cong Wang]

On Mon, Dec 21, 2015 at 1:54 AM, Andrey Ryabinin
 wrote:
> ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
> ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
> ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>
> Fix this by inverting ip6addrlbl_hold() check.
>
> Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address 
> selection policy table.")
> Signed-off-by: Andrey Ryabinin 

Good catch!

Reviewed-by: Cong Wang 
--
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: mm, vmstat: kernel BUG at mm/vmstat.c:1408!

[Sasha Levin]

On 12/21/2015 08:08 AM, Christoph Lameter wrote:
> On Fri, 18 Dec 2015, Sasha Levin wrote:
> 
>> > [  531.164630] RIP vmstat_update (mm/vmstat.c:1408)
> Hmmm.. Yes we need to fold the diffs first before disabling the timer
> otherwise the shepherd task may intervene.
> 
> Does this patch fix it?

It didn't. With the patch I'm still seeing:

[ 1997.674112] kernel BUG at mm/vmstat.c:1408!
[ 1997.674930] invalid opcode:  [#1] PREEMPT SMP KASAN
[ 1997.676252] Modules linked in:
[ 1997.676880] CPU: 4 PID: 14713 Comm: kworker/4:0 Not tainted 
4.4.0-rc5-next-20151221-sasha-00020-g840272e-dirty #2753
[ 1997.679262] Workqueue: vmstat vmstat_update
[ 1997.680109] task: 88015bca ti: 88015bcb8000 task.ti: 
88015bcb8000
[ 1997.681279] RIP: 0010:[]  [] 
vmstat_update+0x178/0x1a0
[ 1997.682810] RSP: 0018:88015bcbfc00  EFLAGS: 00010297
[ 1997.683611] RAX: 0004 RBX: 8803d2801a18 RCX: 
[ 1997.684689] RDX: 0007 RSI: ad098220 RDI: bc8be724
[ 1997.685750] RBP: 88015bcbfc20 R08:  R09: 88015bca0230
[ 1997.686812] R10: ad098220 R11: 880180a1be78 R12: 880180a1be60
[ 1997.688087] R13: 880157b27908 R14: 880180a21000 R15: 880157b27900
[ 1997.689120] FS:  () GS:880180a0() 
knlGS:
[ 1997.690290] CS:  0010 DS:  ES:  CR0: 8005003b
[ 1997.691141] CR2: 7f05e569 CR3: 000158699000 CR4: 06a0
[ 1997.692189] Stack:
[ 1997.692496]  880180a21000 880157b27918 880180a1be60 
880157b27908
[ 1997.693689]  88015bcbfd40 a23aa40f af66686b 
880157b27948
[ 1997.694851]  880180a1be68 8801 880157b27910 
880157b27920
[ 1997.696013] Call Trace:
[ 1997.696542]  [] process_one_work+0xacf/0x12a0
[ 1997.697516]  [] ? cancel_delayed_work_sync+0x10/0x10
[ 1997.698889]  [] ? __schedule+0x1127/0x14c0
[ 1997.699738]  [] ? get_parent_ip+0xd/0x40
[ 1997.700547]  [] ? preempt_count_add+0xe9/0x140
[ 1997.701426]  [] worker_thread+0xcb8/0x1090
[ 1997.702259]  [] ? load_mm_ldt+0x1f0/0x1f0
[ 1997.703084]  [] ? update_rq_clock+0x123/0x2e0
[ 1997.703962]  [] ? process_one_work+0x12a0/0x12a0
[ 1997.704896]  [] ? process_one_work+0x12a0/0x12a0
[ 1997.705804]  [] kthread+0x31e/0x330
[ 1997.706551]  [] ? finish_task_switch+0x6c5/0x970
[ 1997.707481]  [] ? kthread_worker_fn+0x680/0x680
[ 1997.708374]  [] ? kthread_worker_fn+0x680/0x680
[ 1997.709269]  [] ret_from_fork+0x3f/0x70
[ 1997.710067]  [] ? kthread_worker_fn+0x680/0x680
[ 1997.710964] Code: 75 1e be 79 00 00 00 48 c7 c7 40 16 10 ad 89 45 e4 e8 2d 
88 cd ff 8b 45 e4 c6 05 a0 a9 13 1a 01 89 c0 f0 48 0f ab 03 72 02 eb 0e <0f> 0b 
48 c7 c7 c0 21 48 b1 e8 45 d6 ad 01 48 83 c4 08 5b 41 5c
[ 1997.714961] RIP  [] vmstat_update+0x178/0x1a0
[ 1997.715852]  RSP 


Thanks,
Sasha
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Julian Margetson]

On 12/21/2015 4:25 PM, Andy Shevchenko wrote:

On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote:

On 12/21/2015 2:27 PM, Måns Rullgård wrote:

The hard drive is recognized .

These system gets unresponsive with USB devices like the mouse
and
keyboard not responding  when I start Gparted.

Did you disable the SATA and DMA debug messages?


It is working.

Indeed, thanks, Julian!

I might ask you to test my branch with set of patches when it will be
ready (apparently after Xmas) if you are okay with that.

Måns, also I would ask you to test on your hardware (AVR32) as well if
you have no objections.


I have no problem testing.

Regards
Julian


--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

>> > 4. CHECK: PROTCTL bit (documentation says that recommended value is
>> > 0x01)
>> 
>> Any idea what the value of 0x3 used by the old sata driver means?
>> Presumably that's decided by the bus.
>
> Nope, documentation says that it is direct representation of hprot[3:1]
> wires on the master interface. Also it refers to AMBA spec, so, if you
> have access to AMBA spec I think we might get it from there.

That's assuming AMCC didn't change something.

>> > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE)
>> > 6. CHECK: Block interrupts vs. one interrupt at the end of block
>> > chain
>> > (Måns, I missed how any of them is ignored)
>> 
>> The interrupt handler looks at the StatusTfr and StatusErr registers
>> and ignores StatusBlock.
>
> I have to refresh my memory, since BLOCK interrupts should be enabled
> (unmasked) separately. I have forgotten which type of interrupt is
> generated in this case, BLOCK, or XFER after each block, or only one
> XFER at the last block (LLP.LOC = 0) and BLOCK are ignored. So, will
> check later.

I interpreted the, admittedly a bit vague, documentation as meaning
BLOCK interrupts are signalled after each block and XFER interrupts
after the last block.

>> > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail,
>> > etc (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard
>> > SATA)
>> 
>> I can test on AVR32.  That is as far as I know the only system I have
>> with this DMA engine.
>
> If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell,
> you have it as well as long you have LPSS block there. (Most of them
> are Atoms).

I don't have any of those (or any Atom hardware).

-- 
Måns Rullgård
--
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/1] Drivers: hv: vmbus: Add vendor and device atttributes

[Greg KH]

On Thu, Dec 17, 2015 at 03:51:29PM -0800, K. Y. Srinivasan wrote:
> Add vendor and device attributes to VMBUS devices. These will be used
> by Hyper-V tools as well user-level RDMA libraries that will use the
> vendor/device tuple to discover the RDMA device.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  Documentation/ABI/stable/sysfs-bus-vmbus |   14 ++
>  drivers/hv/vmbus_drv.c   |   21 +
>  include/linux/hyperv.h   |2 ++
>  3 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus 
> b/Documentation/ABI/stable/sysfs-bus-vmbus
> index 636e938..5d0125f 100644
> --- a/Documentation/ABI/stable/sysfs-bus-vmbus
> +++ b/Documentation/ABI/stable/sysfs-bus-vmbus
> @@ -27,3 +27,17 @@ Description:   The mapping of which primary/sub 
> channels are bound to which
>   Virtual Processors.
>   Format: 
>  Users:   tools/hv/lsvmbus
> +
> +What:/sys/bus/vmbus/devices/vmbus_*/device

Shouldn't that be 'device_id' as 'device' is a symlink in the sysfs
tree?

> +Date:Dec. 2015
> +KernelVersion:   4.5
> +Contact: K. Y. Srinivasan 
> +Description: The 16 bit device ID of the device
> +Users:   tools/hv/lsvmbus and user level RDMA libraries
> +
> +What:/sys/bus/vmbus/devices/vmbus_*/vendor

'vendor_id'?


> +Date:Dec. 2015
> +KernelVersion:   4.5
> +Contact: K. Y. Srinivasan 
> +Description: The 16 bit vendor ID of the device
> +Users:   tools/hv/lsvmbus and user level RDMA libraries
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 328e4c3..3668a95 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -477,6 +477,24 @@ static ssize_t channel_vp_mapping_show(struct device 
> *dev,
>  }
>  static DEVICE_ATTR_RO(channel_vp_mapping);
>  
> +static ssize_t vendor_show(struct device *dev,
> +struct device_attribute *dev_attr,
> +char *buf)
> +{
> + struct hv_device *hv_dev = device_to_hv_device(dev);
> + return sprintf(buf, "0x%x\n", hv_dev->vendor_id);
> +}
> +static DEVICE_ATTR_RO(vendor);
> +
> +static ssize_t device_show(struct device *dev,
> +struct device_attribute *dev_attr,
> +char *buf)
> +{
> + struct hv_device *hv_dev = device_to_hv_device(dev);
> + return sprintf(buf, "0x%x\n", hv_dev->device_id);
> +}
> +static DEVICE_ATTR_RO(device);
> +
>  /* Set up per device attributes in /sys/bus/vmbus/devices/ */
>  static struct attribute *vmbus_attrs[] = {
>   _attr_id.attr,
> @@ -502,6 +520,8 @@ static struct attribute *vmbus_attrs[] = {
>   _attr_in_read_bytes_avail.attr,
>   _attr_in_write_bytes_avail.attr,
>   _attr_channel_vp_mapping.attr,
> + _attr_vendor.attr,
> + _attr_device.attr,
>   NULL,
>  };
>  ATTRIBUTE_GROUPS(vmbus);
> @@ -957,6 +977,7 @@ struct hv_device *vmbus_device_create(const uuid_le *type,
>   memcpy(_device_obj->dev_type, type, sizeof(uuid_le));
>   memcpy(_device_obj->dev_instance, instance,
>  sizeof(uuid_le));
> + child_device_obj->vendor_id = 0x1414; /* MSFT vendor ID */

So this is always the same value?

And device_id is never set?  What does it default to?  Why include it in
this patch if it's never used?

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: mm, vmstat: kernel BUG at mm/vmstat.c:1408!

[Christoph Lameter]

On Mon, 21 Dec 2015, Sasha Levin wrote:

> I've also noticed a new warning from the workqueue code which my scripts
> didn't pick up before:
>
> [ 3462.380681] BUG: workqueue lockup - pool cpus=2 node=2 flags=0x4 nice=0 
> stuck for 54s!
> [ 3462.522041] workqueue vmstat: flags=0xc
> [ 3462.527795]   pwq 4: cpus=2 node=2 flags=0x0 nice=0 active=1/256
> [ 3462.554836] pending: vmstat_update

Does that mean that vmstat_update locks up or something that schedules it?

Also what workload triggers the BUG()?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

[Tejun Heo]

On Mon, Dec 21, 2015 at 07:14:43PM +0800, Dongsheng Yang wrote:
> Sometimes, cpuacct.usage is not detialed enough to user
> to see how much usage a group used. We want to know how
> much time it used in user mode and how much in kernel mode.

cpuusage is being phased out.  If you need these stats, please
implement it on cpu side.

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/

[PATCH v6 2/3] tty: Add software emulated RS485 support for 8250

[Matwey V. Kornilov]

Implementation of software emulation of RS485 direction handling is based
on omap_serial driver.
Before and after transmission RTS is set to the appropriate value.

Note that before calling serial8250_em485_init the caller has to
ensure that UART will interrupt when shift register empty. Otherwise,
emultaion cannot be used.

Both serial8250_em485_init and serial8250_em485_destroy are
idempotent functions.

Signed-off-by: Matwey V. Kornilov 
---
 drivers/tty/serial/8250/8250.h  |   6 ++
 drivers/tty/serial/8250/8250_port.c | 161 +++-
 include/linux/serial_8250.h |   7 ++
 3 files changed, 170 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index d54dcd8..0189cb3 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -117,6 +117,12 @@ static inline void serial_dl_write(struct uart_8250_port 
*up, int value)
 struct uart_8250_port *serial8250_get_port(int line);
 void serial8250_rpm_get(struct uart_8250_port *p);
 void serial8250_rpm_put(struct uart_8250_port *p);
+int serial8250_em485_init(struct uart_8250_port *p);
+void serial8250_em485_destroy(struct uart_8250_port *p);
+static inline bool serial8250_em485_enabled(struct uart_8250_port *p)
+{
+   return p->em485 && (p->port.rs485.flags & SER_RS485_ENABLED);
+}
 
 #if defined(__alpha__) && !defined(CONFIG_PCI)
 /*
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 8ad0b2d..d67a848 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -504,6 +505,31 @@ static void serial8250_clear_fifos(struct uart_8250_port 
*p)
}
 }
 
+static inline void serial8250_em485_rts_on_send(struct uart_8250_port *p)
+{
+   unsigned char mcr = serial_in(p, UART_MCR);
+
+   if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND)
+   mcr |= UART_MCR_RTS;
+   else
+   mcr &= ~UART_MCR_RTS;
+   serial_out(p, UART_MCR, mcr);
+}
+
+static inline void serial8250_em485_rts_after_send(struct uart_8250_port *p)
+{
+   unsigned char mcr = serial_in(p, UART_MCR);
+
+   if (p->port.rs485.flags & SER_RS485_RTS_AFTER_SEND)
+   mcr |= UART_MCR_RTS;
+   else
+   mcr &= ~UART_MCR_RTS;
+   serial_out(p, UART_MCR, mcr);
+}
+
+static void serial8250_em485_handle_start_tx(unsigned long arg);
+static void serial8250_em485_handle_stop_tx(unsigned long arg);
+
 void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p)
 {
serial8250_clear_fifos(p);
@@ -528,6 +554,42 @@ void serial8250_rpm_put(struct uart_8250_port *p)
 }
 EXPORT_SYMBOL_GPL(serial8250_rpm_put);
 
+int serial8250_em485_init(struct uart_8250_port *p)
+{
+   if (p->em485 != NULL)
+   return 0;
+
+   p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_KERNEL);
+   if (p->em485 == NULL)
+   return -ENOMEM;
+
+   init_timer(>em485->stop_tx_timer);
+   p->em485->stop_tx_timer.function = serial8250_em485_handle_stop_tx;
+   p->em485->stop_tx_timer.data = (unsigned long)p;
+   p->em485->stop_tx_timer.flags |= TIMER_IRQSAFE;
+   init_timer(>em485->start_tx_timer);
+   p->em485->start_tx_timer.function = serial8250_em485_handle_start_tx;
+   p->em485->start_tx_timer.data = (unsigned long)p;
+   p->em485->start_tx_timer.flags |= TIMER_IRQSAFE;
+
+   serial8250_em485_rts_after_send(p);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(serial8250_em485_init);
+void serial8250_em485_destroy(struct uart_8250_port *p)
+{
+   if (p->em485 == NULL)
+   return;
+
+   del_timer_sync(>em485->start_tx_timer);
+   del_timer_sync(>em485->stop_tx_timer);
+
+   kfree(p->em485);
+   p->em485 = NULL;
+}
+EXPORT_SYMBOL_GPL(serial8250_em485_destroy);
+
 /*
  * These two wrappers ensure that enable_runtime_pm_tx() can be called more 
than
  * once and disable_runtime_pm_tx() will still disable RPM because the fifo is
@@ -1293,7 +1355,61 @@ static void serial8250_stop_rx(struct uart_port *port)
serial8250_rpm_put(up);
 }
 
-static inline void __stop_tx(struct uart_8250_port *p)
+static __u32 __start_tx_rs485(struct uart_8250_port *p)
+{
+   if (!serial8250_em485_enabled(p))
+   return 0;
+
+   if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
+   serial8250_stop_rx(>port);
+
+   del_timer_sync(>em485->stop_tx_timer);
+
+   if (!!(p->port.rs485.flags & SER_RS485_RTS_ON_SEND) != !!(serial_in(p, 
UART_MCR) & UART_MCR_RTS)) {
+   serial8250_em485_rts_on_send(p);
+   return p->port.rs485.delay_rts_before_send;
+   }
+
+   return 0;
+}
+
+static inline void __do_stop_tx_rs485(struct uart_8250_port *p)
+{
+   if (!serial8250_em485_enabled(p))
+   return;
+
+   

[PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration

[Javier Martinez Canillas]

The omapfb is failing to build in -next due missing declarations for
dss_feat_get_supported_displays() and dss_feat_get_supported_outputs():

 CC [M]  drivers/video/fbdev/omap2//omapfb/dss/dss.o
drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context':
drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit declaration 
of function 'dss_feat_get_supported_displays' 
[-Werror=implicit-function-declaration]

Add the declaration for these functions in the dss_features.h header
file to fix this compile error.

Also, remove the functions export since are not used outside the driver.

Signed-off-by: Javier Martinez Canillas 

---

Hello Tomi,

This seems to be caused by a wrong order in which some commits from
the omapdss tree [0] were merged, or rather a wrong base used for
the dss-drm-merge (4.4.0-rc4) and the for-next (4.4.0-rc5) branches.

The problem is that commit 2ea164a9af9c ("drm/omap: move omapdss &
displays under omapdrm") moves the dss_features.h header from the
drivers/video/fbdev/omap2/dss/ dir to drivers/gpu/drm/omapdrm}/dss.

And then commit 8b987a111b1a ("omapfb: copy omapdss & displays for
omapfb" copies the hader from the omapdrm dir to the omapfb one.

Now, since commit 66c78ddd7a2e ("OMAPDSS: make a two dss feat funcs
internal to omapdss") is the one that moves the function declaration
from the public include/video/omapdss.h header to the internal one,
this means that git will be smart enough to identify that the header
that was drivers/video/fbdev/omap2/dss/dss_features.h now is the one
in the omapdrm directory but that means that the omapfb files won't
get the changes since the move & copy happened before.

This happens AFAIU because dss-drm-merge having an older base so the
patches in for-next are rebased on top of dss-drm-merge when merging.

The issue can easily be avoided by first merging the patch that does
the feat funcs declaration move and then merging the ones that do the
per driver omapdss refactoring.

But I'm posting this patch anyways in case you can't redo your branches
and need a fix to apply on top of your current for-next.

[0]: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git

Best regards,
Javier

 drivers/video/fbdev/omap2/omapfb/dss/dss_features.c | 2 --
 drivers/video/fbdev/omap2/omapfb/dss/dss_features.h | 3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
index b0b6dfd657bf..a2e26b8d6ded 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -844,13 +844,11 @@ enum omap_display_type 
dss_feat_get_supported_displays(enum omap_channel channel
 {
return omap_current_dss_features->supported_displays[channel];
 }
-EXPORT_SYMBOL(dss_feat_get_supported_displays);
 
 enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel 
channel)
 {
return omap_current_dss_features->supported_outputs[channel];
 }
-EXPORT_SYMBOL(dss_feat_get_supported_outputs);
 
 enum omap_color_mode dss_feat_get_supported_color_modes(enum omap_plane plane)
 {
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h 
b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
index 100f7a2d0638..4474ebff8607 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
@@ -102,4 +102,7 @@ bool dss_feat_rotation_type_supported(enum 
omap_dss_rotation_type rot_type);
 bool dss_has_feature(enum dss_feat_id id);
 void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end);
 void dss_features_init(enum omapdss_version version);
+
+enum omap_display_type dss_feat_get_supported_displays(enum omap_channel 
channel);
+enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel 
channel);
 #endif
-- 
2.4.3

--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson  wrote:
>> On 12/21/2015 12:48 PM, Andy Shevchenko wrote:
>>>
>>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:

 On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
  wrote:
>
> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 
> wrote:
> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
> items on this board, however registers for SATA program it to 64. I
> remember that I got no interrupt when I programmed transfer width
> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used
> on
> Intel SoCs.

 One more thing, I have a patch to monitor DMA IO, we may check what
 exactly the values are written / read  in DMA. I can share it
 tomorrow.
>>>
>>> As promised the patch I have to debug IO of DW DMA. Didn't check though
>>> if it applies cleanly on top of recent vanilla kernel.
>
> So, the original driver (with patch from Måns) works, right?

Looks that way to me.  At least it's able to read the partition table.
What happens after that is hard to tell, but I don't see any obvious
errors.

-- 
Måns Rullgård
--
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 v6 0/3] tty: Introduce software RS485 direction control support

[Matwey V. Kornilov]

Changes from v5:
 - rs485_emul variable has been renamed to em485 to follow function names 
convention
Changes from v4:
 - Add commit message to 1/3
Changes from v3:
 - Completely redesigned.
Changes from v2:
 - Introduced SER_RS485_SOFTWARE to show that software implementation is being 
used
 - serial8250_rs485_config is located as required
 - Timers are used to implement delay_before and delay_after timeouts

Signed-off-by: Matwey V. Kornilov 
--
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] drm, i915: Fix pointer size cast

[Borislav Petkov]

From: Borislav Petkov 

gcc complains on 32-bit like this:

  drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
  drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from \
  integer of different size [-Wint-to-pointer-cast]
offset = (unsigned char *)vma->node.start;
 ^

because vma->node.start is u64 but a pointer on 32-bit is 4 bytes.

Do the calculations with an unsigned long directly and save us the
casts.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: intel-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Borislav Petkov 
---
 drivers/gpu/drm/i915/intel_display.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62211abe4922..640cb7c9b7f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2941,7 +2941,7 @@ unsigned long intel_plane_obj_offset(struct intel_plane 
*intel_plane,
 {
const struct i915_ggtt_view *view = _ggtt_view_normal;
struct i915_vma *vma;
-   unsigned char *offset;
+   unsigned long offset;
 
if (intel_rotation_90_or_270(intel_plane->base.state->rotation))
view = _ggtt_view_rotated;
@@ -2951,14 +2951,14 @@ unsigned long intel_plane_obj_offset(struct intel_plane 
*intel_plane,
view->type))
return -1;
 
-   offset = (unsigned char *)vma->node.start;
+   offset = vma->node.start;
 
if (plane == 1) {
offset += vma->ggtt_view.rotation_info.uv_start_page *
  PAGE_SIZE;
}
 
-   return (unsigned long)offset;
+   return offset;
 }
 
 static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
-- 
2.3.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: Is PROT_SOCK still relevant?

[Jason Newton]

I can only assume from lack of criticism that either:

1)  This is a completely great idea with no cons and thus worthy of
time to implement

or

2) The topic has been ignored

Is it reasonable to allocate a 8KiB buffer for a bit vector covering
2*16 ports?  Should I instead just focus on a list/container to have a
smaller foot print in the average case?

Regards,
Jason

On Wed, Dec 16, 2015 at 9:52 AM, Jason Newton  wrote:
> How about changing how this mechanism works from a range of the lowest
> N ports and instead have it as a user specifiable set?  Towards more
> proper security, this allows distros/admins to put any ports they
> consider important to have security feature going well beyond the
> current limit without recompiling the kernel.
>
> It may make more sense to make this protocol specific too but I'm not
> sure if that would be so simple to implement and manage.
>
> Do we need a default list?  What would the contents be if so?  [0,
> 1024)?  {22, ...}? {}?
>
> Would there be any special considerations needed for the set
> container?  How about a hash table? 2^16-1 uchar bool vector?
>
> In terms of setting/initializing - sysctl?
>
> -Jason
>
> On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton  wrote:
>> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>>  wrote:
 Perhaps lets consider this in another way if it is strongly held that
 this is worth while in the default configuration: can it default off
 in the context of selinux / other security frameworks (preferably
 based on their detection and/or controllably settable at runtime)?
 Those allow more powerful and finer grain control and don't need this
 to be there as they already provide auditing on what operations and
 port numbers should be allowed by what programs.
>>>
>>> That would be a regression and a very very bad one to have. The defaults
>>> need to always be the same as before - or stronger and never go back
>>> towards insecurity, otherwise they could make things less safe.
>>
>> Even if you don't think it should be default, there's still a case
>> having a knob for leaving it to the auditing framework to deal with
>> it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
>> of the workarounds mentioned have to be invoked and tuned, which
>> increases maintenance and setup burden.  On some systems, these
>> methods may not be available, too.  Android is one that comes to mind.
>>
>> I openly stated this issue has been brought up for me *this time* due
>> to Android, but it still does keep coming up.  It's on my Linux Kernel
>> bucket list to get it addressed/tunable.  This isn't isn't going to be
>> changed and make it to where it matters for me this occurrence with
>> any practical timing - but I'm trying to prevent the next occurrence
>> I'll have with it - and its not in my expectations it'll be Android at
>> that point.
>>
>>>
 Or how about letting port number concerns be handled by those security
 frameworks all together considering it is limited security?
>>>
>>> There are already half a dozen different ways to handle it from xinetd
>>> through setcap, to systemd spawning it, to iptables.
>>
>> Most (all?) of those methods have sacrifices as previously noted:
>> Systemd isn't everywhere still and may never be, setcap doesn't work
>> with java/python and the like, iptables has significant performance
>> loss when scalability is important and increased configuration
>> detail... never tried with xinetd.  Is one of these the sure fire way
>> or should we be happy we have so many choices with each their own
>> caveats?
>>
>> -Jason
--
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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Andy Shevchenko  writes:

> On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote:
>> Andy Shevchenko  writes:
>> 
>> > P.S. I also noticed that original driver enables interrupt per each
>> > block
>> 
>> And then ignores all but the transfer complete interrupt.
>> 
>> > and sets protection control bits.
>> 
>> With no indication what the value it sets is supposed to mean.
>
> Okay, let's summarize what we have:
>
> 0. AR: Get a working reference for PPC 460EX SATA driver

Do we consider Julian's latest result working?

> 1. AR: Clear LLP_EN bits at the last block of LLP transfer

Patch sent.

> 2. AR: Rename masters to 'memory' and 'peripheral' and change them per
> DMA direction

Good idea.  I'd call them memory and device though to match existing
dmaengine nomenclature.

> 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers

I started working on a patch for that already.

> 4. CHECK: PROTCTL bit (documentation says that recommended value is
> 0x01)

Any idea what the value of 0x3 used by the old sata driver means?
Presumably that's decided by the bus.

> 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE)
> 6. CHECK: Block interrupts vs. one interrupt at the end of block chain
> (Måns, I missed how any of them is ignored)

The interrupt handler looks at the StatusTfr and StatusErr registers and
ignores StatusBlock.

> 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, etc
> (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard SATA)

I can test on AVR32.  That is as far as I know the only system I have
with this DMA engine.

> I can share my working branch with a set of patches regarding to
> dw_dmac. We may do our work based on that code and after I'll submit
> everything to upstream. Does it sound okay for you, guys?

I'm going away for the holidays, so I won't be able to do any serious
work on this until January, but I'll keep an eye on emails and may even
reply occasionally.  Before I go, I'll publish my patches so far
whatever shape they're in.

-- 
Måns Rullgård
--
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 4/7] dax: add support for fsync/sync

[Dan Williams]

On Mon, Dec 21, 2015 at 9:05 AM, Ross Zwisler
 wrote:
> On Sat, Dec 19, 2015 at 10:37:46AM -0800, Dan Williams wrote:
>> On Fri, Dec 18, 2015 at 9:22 PM, Ross Zwisler
>>  wrote:
>> > To properly handle fsync/msync in an efficient way DAX needs to track dirty
>> > pages so it is able to flush them durably to media on demand.
>> >
>> > The tracking of dirty pages is done via the radix tree in struct
>> > address_space.  This radix tree is already used by the page writeback
>> > infrastructure for tracking dirty pages associated with an open file, and
>> > it already has support for exceptional (non struct page*) entries.  We
>> > build upon these features to add exceptional entries to the radix tree for
>> > DAX dirty PMD or PTE pages at fault time.
>> >
>> > Signed-off-by: Ross Zwisler 
>> [..]
>> > +static void dax_writeback_one(struct address_space *mapping, pgoff_t 
>> > index,
>> > +   void *entry)
>> > +{
>> > +   struct radix_tree_root *page_tree = >page_tree;
>> > +   int type = RADIX_DAX_TYPE(entry);
>> > +   struct radix_tree_node *node;
>> > +   void **slot;
>> > +
>> > +   if (type != RADIX_DAX_PTE && type != RADIX_DAX_PMD) {
>> > +   WARN_ON_ONCE(1);
>> > +   return;
>> > +   }
>> > +
>> > +   spin_lock_irq(>tree_lock);
>> > +   /*
>> > +* Regular page slots are stabilized by the page lock even
>> > +* without the tree itself locked.  These unlocked entries
>> > +* need verification under the tree lock.
>> > +*/
>> > +   if (!__radix_tree_lookup(page_tree, index, , ))
>> > +   goto unlock;
>> > +   if (*slot != entry)
>> > +   goto unlock;
>> > +
>> > +   /* another fsync thread may have already written back this entry */
>> > +   if (!radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_TOWRITE))
>> > +   goto unlock;
>> > +
>> > +   radix_tree_tag_clear(page_tree, index, PAGECACHE_TAG_TOWRITE);
>> > +
>> > +   if (type == RADIX_DAX_PMD)
>> > +   wb_cache_pmem(RADIX_DAX_ADDR(entry), PMD_SIZE);
>> > +   else
>> > +   wb_cache_pmem(RADIX_DAX_ADDR(entry), PAGE_SIZE);
>>
>> Hi Ross, I should have realized this sooner, but what guarantees that
>> the address returned by RADIX_DAX_ADDR(entry) is still valid at this
>> point?  I think we need to store the sector in the radix tree and then
>> perform a new dax_map_atomic() operation to either lookup a valid
>> address or fail the sync request.  Otherwise, if the device is gone
>> we'll crash, or write into some other random vmalloc address space.
>
> Ah, good point, thank you.  v4 of this series is based on a version of
> DAX where we aren't properly dealing with PMEM device removal.  I've got an
> updated version that merges with your dax_map_atomic() changes, and I'll add
> this change into v5 which I will send out today.  Thank you for the
> suggestion.

To make the merge simpler you could skip the rebase for now and just
call blk_queue_enter() / blk_queue_exit() around the calls to
wb_cache_pmem.
--
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] Input: xpad - use LED API when identifying wireless controllers

[Dmitry Torokhov]

On Sun, Dec 20, 2015 at 01:49:25PM +0100, Pavel Rojtberg wrote:
> 2015-12-20 8:55 GMT+01:00 Dmitry Torokhov :
> > On Sat, Dec 19, 2015 at 10:17:09PM +0100, Clement Calmels wrote:
> >> On Wed, 16 Dec 2015 14:44:08 -0800
> >> Dmitry Torokhov  wrote:
> >>
> >> > When lighting up the segment identifying wireless controller, Instead
> >> > of sending command directly to the controller, let's do it via LED
> >> > API (usinf led_set_brightness) so that LED object state is in sync
> >> > with controller state and we'll light up the correct segment on
> >> > resume as well.
> >> >
> >> > Signed-off-by: Dmitry Torokhov 
> >> > ---
> >> >
> >> > I do not have the hardware so please try this out.
> >> >
> >> >  drivers/input/joystick/xpad.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/input/joystick/xpad.c
> >> > b/drivers/input/joystick/xpad.c index 36328b3..00a766b 100644
> >> > --- a/drivers/input/joystick/xpad.c
> >> > +++ b/drivers/input/joystick/xpad.c
> >> > @@ -1118,7 +1118,7 @@ static void xpad_send_led_command(struct
> >> > usb_xpad *xpad, int command) */
> >> >  static void xpad_identify_controller(struct usb_xpad *xpad)
> >> >  {
> >> > -   xpad_send_led_command(xpad, (xpad->pad_nr % 4) + 2);
> >> > +   led_set_brightness(>led->led_cdev, (xpad->pad_nr % 4)
> >> > + 2); }
> >> >
> >> >  static void xpad_led_set(struct led_classdev *led_cdev,
> >>
> >> Hi Dimitri,
> >
> > Hi Clement,
> >
> >>
> >> My hardware: two wireless xpad 360 using a single usb receiver.
> >>
> >> Power on the first gamepad => light the "1" led.
> >> Power on the second gamepad => light the "2" led.
> >>
> >> Suspend the PC (systemctl suspend): the two gamepads are "disconnected"
> >> => blinking circle.
> >>
> >> Resume the PC, the two gamepads keep blinking but are working (tested
> >> with jstest).
> >>
> >> Power off and on the gamepad => still blinking.
> >> Reload (rmmod/modprobe) the xpad module => still blinking.
> >>
> >> That said, without your patch, the behavior is exactly the same.
> >> It seems that the suspend/resume broke the led feature. Even using
> >> the /sys/class/leds/xpad0/brigthness sysfs entry does not work.
> >>
> >
> > OK, so the patch does work (the device is still correctly identified),
> > but resume requires additional patches. Could you try 'xpad' branch of
> > my tree on kernel.org [1] and let me know if it works for you?
> at least on my machine your follow up patch was also required which I merged 
> at:
> https://github.com/paroj/xpad/tree/dtor
> 
> with this patch the controllers still continue blinking after resume,
> however the URB
> will still work so they respond to subsequent LED commands triggered
> via sysfs (or if they are powered off and on).
> 
> I also verified that a LED command is triggered upon resume - however
> the controller ignores that.
> Maybe it is sent too early/ in the wrong order.

I wonder if below helps this.

-- 
Dmitry


Input: xpad - try waiting for output URB to complete

From: Dmitry Torokhov 

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/joystick/xpad.c |   41 +
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 30b2fa8..dd7a2af 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -346,9 +346,10 @@ struct usb_xpad {
dma_addr_t idata_dma;
 
struct urb *irq_out;/* urb for interrupt out report */
+   struct usb_anchor irq_out_anchor;
bool irq_out_active;/* we must not use an active URB */
-   unsigned char *odata;   /* output data */
u8 odata_serial;/* serial number for xbox one protocol 
*/
+   unsigned char *odata;   /* output data */
dma_addr_t odata_dma;
spinlock_t odata_lock;
 
@@ -764,11 +765,13 @@ static int xpad_try_sending_next_out_packet(struct 
usb_xpad *xpad)
int error;
 
if (!xpad->irq_out_active && xpad_prepare_next_out_packet(xpad)) {
+   usb_anchor_urb(xpad->irq_out, >irq_out_anchor);
error = usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
if (error) {
dev_err(>intf->dev,
"%s - usb_submit_urb failed with result %d\n",
__func__, error);
+   usb_unanchor_urb(xpad->irq_out);
return -EIO;
}
 
@@ -811,11 +814,13 @@ static void xpad_irq_out(struct urb *urb)
}
 
if (xpad->irq_out_active) {
+   usb_anchor_urb(urb, >irq_out_anchor);
error = usb_submit_urb(urb, GFP_ATOMIC);
if (error) {
dev_err(dev,

Re: [PATCH 1/1] staging: android: ion: fixes spars warning cast to restricted gfp_t

[Laura Abbott]

On 12/21/2015 03:24 AM, Bijosh Thykkoottathil wrote:

From: Bijosh Thykkoottathil 

This patch fixes following sparse warnings:

drivers/staging/android/ion/ion.c:1475:21: warning: incorrect type in 
assignment (different base types)
drivers/staging/android/ion/ion.c:1475:21:expected restricted gfp_t 
[usertype] gfp_mask
drivers/staging/android/ion/ion.c:1475:21:got int
drivers/staging/android/ion/ion.c:1493:21: warning: incorrect type in 
assignment (different base types)
drivers/staging/android/ion/ion.c:1493:21:expected restricted gfp_t 
[usertype] gfp_mask
drivers/staging/android/ion/ion.c:1493:21:got int

Signed-off-by: Bijosh Thykkoottathil 
---
  drivers/staging/android/ion/ion.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e237e9f..f986a58 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1472,7 +1472,7 @@ static int debug_shrink_set(void *data, u64 val)
struct shrink_control sc;
int objs;

-   sc.gfp_mask = -1;
+   sc.gfp_mask = (__force gfp_t)(-1);
sc.nr_to_scan = val;


-1 doesn't actually make much sense here. I'd rather see this changed to be an
appropriate GFP flag rather than just casting it away, probably
GFP_HIGHUSER. If you'd like to fix this up, make sure to double check
that the shrinking behavior remains the same (similar number of low and high
pages are reclaimed).

Thanks,
Laura

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mm, oom: introduce oom reaper

[Paul Gortmaker]

On Tue, Dec 15, 2015 at 1:36 PM, Michal Hocko  wrote:
> From: Michal Hocko 
>
> This is based on the idea from Mel Gorman discussed during LSFMM 2015 and
> independently brought up by Oleg Nesterov.
>

[...]

Since this is built-in always, can we

> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 5314b206caa5..48025a21f8c4 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -35,6 +35,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

...use  instead above, and then...

> +
> +#include 
> +#include "internal.h"
>

[...]

> +* Make sure our oom reaper thread will get scheduled when
> +* ASAP and that it won't get preempted by malicious 
> userspace.
> +*/
> +   sched_setscheduler(oom_reaper_th, SCHED_FIFO, );
> +   }
> +   return 0;
> +}
> +module_init(oom_init)

...use one of the non-modular initcalls here?   I'm trying to clean up most of
the non-modular uses of modular macros etc. since:

 (1) it is easy to accidentally code up an unused module_exit function
 (2) it can be misleading when reading the source, thinking it can be
  modular when the Makefile and/or Kconfig prohibit it
 (3) it requires the include of the module.h header file which in turn
 includes nearly everything else, thus increasing CPP overhead.

I figured no point in sending a follow on patch since this came in via
the akpm tree into next and that gets rebased/updated regularly.

Thanks,
Paul.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/