Re: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core

On Fri, Apr 27, 2018 at 11:20 AM, Masahiro Yamada wrote: > Hi Rob, > > > 2018-04-26 0:21 GMT+09:00 Rob Herring : > >>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt >>> b/Documentation/devicetree/bindings/usb/dwc3.txt >>> index

Re: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core

On Fri, Apr 27, 2018 at 11:20 AM, Masahiro Yamada wrote: > Hi Rob, > > > 2018-04-26 0:21 GMT+09:00 Rob Herring : > >>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt >>> b/Documentation/devicetree/bindings/usb/dwc3.txt >>> index 0dbd308..feb1cc33 100644 >>> ---

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Fri, Apr 27, 2018 at 11:39:43AM -0600, Lina Iyer wrote: > On Wed, Apr 25 2018 at 15:41 -0600, Matthias Kaehlcke wrote: > > On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: > > > Sleep and wake requests are sent when the application processor > > > subsystem of the SoC is entering deep

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Fri, Apr 27, 2018 at 11:39:43AM -0600, Lina Iyer wrote: > On Wed, Apr 25 2018 at 15:41 -0600, Matthias Kaehlcke wrote: > > On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: > > > Sleep and wake requests are sent when the application processor > > > subsystem of the SoC is entering deep

Re: [PATCH v6 04/24] ASoC: qdsp6: dt-bindings: Add q6afe dt bindings

On Fri, Apr 27, 2018 at 9:58 AM, Srinivas Kandagatla wrote: > Thanks for the review. > > > On 27/04/18 15:13, Rob Herring wrote: >> >> On Thu, Apr 26, 2018 at 10:45:46AM +0100, srinivas.kandaga...@linaro.org >> wrote: >>> >>> From: Srinivas Kandagatla

Re: [PATCH v6 04/24] ASoC: qdsp6: dt-bindings: Add q6afe dt bindings

On Fri, Apr 27, 2018 at 9:58 AM, Srinivas Kandagatla wrote: > Thanks for the review. > > > On 27/04/18 15:13, Rob Herring wrote: >> >> On Thu, Apr 26, 2018 at 10:45:46AM +0100, srinivas.kandaga...@linaro.org >> wrote: >>> >>> From: Srinivas Kandagatla >>> >>> This patch add DT bindings for AFE

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On 04/26/2018 06:26 PM, Moritz Fischer wrote: > From: Alan Tull > > Change fpga_mgr_register to not set or use drvdata. This supports > the case where a PCIe device has more than one manager. > > Add fpga_mgr_create/free functions. Change fpga_mgr_register and >

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On 04/26/2018 06:26 PM, Moritz Fischer wrote: > From: Alan Tull > > Change fpga_mgr_register to not set or use drvdata. This supports > the case where a PCIe device has more than one manager. > > Add fpga_mgr_create/free functions. Change fpga_mgr_register and > fpga_mgr_unregister functions

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > The RFBI driver has not worked nor compiled for many years. There are What is the build failure you are seeing? When removing the

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > The RFBI driver has not worked nor compiled for many years. There are What is the build failure you are seeing? When removing the

copy_file_range and user space tools to do copy fastest

Are there any user space tools (other than our test tools and xfs_io etc.) that support copy_file_range? Looks like at least cp and rsync and dd don't. That syscall which now has been around a couple years, and was reminded about at the LSF/MM summit a few days ago, presumably is the 'best' way

copy_file_range and user space tools to do copy fastest

Are there any user space tools (other than our test tools and xfs_io etc.) that support copy_file_range? Looks like at least cp and rsync and dd don't. That syscall which now has been around a couple years, and was reminded about at the LSF/MM summit a few days ago, presumably is the 'best' way

Applied "ASoC: tas6424: Add support for the mute pin" to the asoc tree

The patch ASoC: tas6424: Add support for the mute pin has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: tas6424: Add support for the standby pin" to the asoc tree

The patch ASoC: tas6424: Add support for the standby pin has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Applied "ASoC: tas6424: Add support for the mute pin" to the asoc tree

The patch ASoC: tas6424: Add support for the mute pin has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: tas6424: Add support for the standby pin" to the asoc tree

The patch ASoC: tas6424: Add support for the standby pin has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: [PATCH] ACPI / scan: Fix regression related to X-Gene UARTs

On Sun, 2018-04-22 at 11:34 +0200, Rafael J. Wysocki wrote: > On Fri, Apr 20, 2018 at 5:29 AM, Mark Salter wrote: > > Commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART > > devices") caused a regression with some X-Gene based platforms (Mustang > > and M400)

Re: [PATCH] ACPI / scan: Fix regression related to X-Gene UARTs

On Sun, 2018-04-22 at 11:34 +0200, Rafael J. Wysocki wrote: > On Fri, Apr 20, 2018 at 5:29 AM, Mark Salter wrote: > > Commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART > > devices") caused a regression with some X-Gene based platforms (Mustang > > and M400) with invalid DSDT. >

Re: [PATCH] IB/rxe: add RXE_START_MASK for rxe_opcode IB_OPCODE_RC_SEND_ONLY_INV

On Thu, 2018-04-26 at 12:02 +0800, Yanjun Zhu wrote: > On 2018/4/26 11:52, Jianchao Wang wrote: > > w/o RXE_START_MASK, the last_psn of IB_OPCODE_RC_SEND_ONLY_INV > > will not be updated in update_wqe_psn, and the corresponding > > wqe will not be acked in rxe_completer due to its last_psn is > >

Re: [PATCH] IB/rxe: add RXE_START_MASK for rxe_opcode IB_OPCODE_RC_SEND_ONLY_INV

On Thu, 2018-04-26 at 12:02 +0800, Yanjun Zhu wrote: > On 2018/4/26 11:52, Jianchao Wang wrote: > > w/o RXE_START_MASK, the last_psn of IB_OPCODE_RC_SEND_ONLY_INV > > will not be updated in update_wqe_psn, and the corresponding > > wqe will not be acked in rxe_completer due to its last_psn is > >

Re: [PATCH] RDMA/iwpm: fix memory leak on map_info

On Wed, 2018-04-25 at 17:24 +0100, Colin King wrote: > From: Colin Ian King > > In the cases where iwpm_hash_bucket is NULL and where function > get_mapinfo_hash_bucket returns NULL then the map_info is never added > to hash_bucket_head and hence there is a leak of

Re: [PATCH] RDMA/iwpm: fix memory leak on map_info

On Wed, 2018-04-25 at 17:24 +0100, Colin King wrote: > From: Colin Ian King > > In the cases where iwpm_hash_bucket is NULL and where function > get_mapinfo_hash_bucket returns NULL then the map_info is never added > to hash_bucket_head and hence there is a leak of map_info. Fix this > by

Re: [PATCH 4.16 00/81] 4.16.6-stable review

On 04/27/2018 07:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.6 release. > There are 81 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 00/81] 4.16.6-stable review

On 04/27/2018 07:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.6 release. > There are 81 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/50] 4.4.130-stable review

On 04/27/2018 07:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.130 release. > There are 50 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/50] 4.4.130-stable review

On 04/27/2018 07:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.130 release. > There are 50 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/80] 4.14.38-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.38 release. > There are 80 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/80] 4.14.38-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.38 release. > There are 80 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/74] 4.9.97-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.97 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/74] 4.9.97-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.97 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 07:58:28PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote: > > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove

Re: [PATCH 3.18 00/24] 3.18.107-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.107 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 07:58:28PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote: > > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove

Re: [PATCH 3.18 00/24] 3.18.107-stable review

On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.107 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on

On Fri, Apr 27, 2018 at 9:37 AM, Steven Rostedt wrote: > On Fri, 27 Apr 2018 09:30:05 -0700 > Joel Fernandes wrote: > >> On Fri, Apr 27, 2018 at 7:47 AM, Steven Rostedt wrote: >> > On Fri, 27 Apr 2018 10:26:29 -0400 (EDT) >> > Mathieu

Re: [PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on

On Fri, Apr 27, 2018 at 9:37 AM, Steven Rostedt wrote: > On Fri, 27 Apr 2018 09:30:05 -0700 > Joel Fernandes wrote: > >> On Fri, Apr 27, 2018 at 7:47 AM, Steven Rostedt wrote: >> > On Fri, 27 Apr 2018 10:26:29 -0400 (EDT) >> > Mathieu Desnoyers wrote: >> > >> >> The general approach and the

Re: [PATCH] PCI: Add Intel 7th & 8th Gen mobile to ACS quirks

On Wed, Apr 25, 2018 at 02:27:37PM -0600, Alex Williamson wrote: > The specification update indicates these have the same errate for > implementing non-standard ACS capabilities. > > Signed-off-by: Alex Williamson Applied to pci/virtualization for v4.18, thanks! I'm

Re: [PATCH] PCI: Add Intel 7th & 8th Gen mobile to ACS quirks

On Wed, Apr 25, 2018 at 02:27:37PM -0600, Alex Williamson wrote: > The specification update indicates these have the same errate for > implementing non-standard ACS capabilities. > > Signed-off-by: Alex Williamson Applied to pci/virtualization for v4.18, thanks! I'm guessing a stable tag would

Re: [PATCH] IB/ipoib: fix ipoib_start_xmit()'s return type

On Wed, 2018-04-25 at 18:35 +0300, Leon Romanovsky wrote: > On Tue, Apr 24, 2018 at 03:15:47PM +0200, Luc Van Oostenryck wrote: > > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > > which is a typedef for an enum type, but the implementation in this > > driver returns an

Re: [PATCH] IB/ipoib: fix ipoib_start_xmit()'s return type

On Wed, 2018-04-25 at 18:35 +0300, Leon Romanovsky wrote: > On Tue, Apr 24, 2018 at 03:15:47PM +0200, Luc Van Oostenryck wrote: > > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > > which is a typedef for an enum type, but the implementation in this > > driver returns an

[PATCH] crypto: ghash-clmulni: fix spelling mistake: "acclerated" -> "accelerated"

From: Colin Ian King Trivial fix to spelling mistake in module description text Signed-off-by: Colin Ian King --- arch/x86/crypto/ghash-clmulni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] crypto: ghash-clmulni: fix spelling mistake: "acclerated" -> "accelerated"

From: Colin Ian King Trivial fix to spelling mistake in module description text Signed-off-by: Colin Ian King --- arch/x86/crypto/ghash-clmulni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c

Re: [PATCH] IB/nes: fix nes_netdev_start_xmit()'s return type

On Wed, 2018-04-25 at 18:35 +0300, Leon Romanovsky wrote: > On Tue, Apr 24, 2018 at 08:36:12PM +0300, Leon Romanovsky wrote: > > On Tue, Apr 24, 2018 at 03:15:45PM +0200, Luc Van Oostenryck wrote: > > > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > > > which is a typedef

Re: [PATCH] IB/nes: fix nes_netdev_start_xmit()'s return type

On Wed, 2018-04-25 at 18:35 +0300, Leon Romanovsky wrote: > On Tue, Apr 24, 2018 at 08:36:12PM +0300, Leon Romanovsky wrote: > > On Tue, Apr 24, 2018 at 03:15:45PM +0200, Luc Van Oostenryck wrote: > > > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > > > which is a typedef

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On 23/04/18 21:43, Jacob Pan wrote: [...] >> The last name is a bit unfortunate. Since the Arm architecture uses >> the name "context" for what a PASID points to, "Device cache" would >> suit us better but it's not important. >> > or call it device context cache. actually so far context cache is

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On 23/04/18 21:43, Jacob Pan wrote: [...] >> The last name is a bit unfortunate. Since the Arm architecture uses >> the name "context" for what a PASID points to, "Device cache" would >> suit us better but it's not important. >> > or call it device context cache. actually so far context cache is

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

Michal Hocko writes: > On Thu 26-04-18 21:28:18, Michal Hocko wrote: >> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote: >> > Michal Hocko writes: >> > >> > > I've had a patch to remove owner few years back. It needed some work >> > > to finish but maybe

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

Michal Hocko writes: > On Thu 26-04-18 21:28:18, Michal Hocko wrote: >> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote: >> > Michal Hocko writes: >> > >> > > I've had a patch to remove owner few years back. It needed some work >> > > to finish but maybe that would be a better than try to

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

On 04/27/2018 11:01 AM, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Randy Dunlap [mailto:rdun...@infradead.org] >> Sent: Friday, April 27, 2018 12:56 PM >> To: kbuild test robot; Limonciello, Mario >> Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

On 04/27/2018 11:01 AM, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Randy Dunlap [mailto:rdun...@infradead.org] >> Sent: Friday, April 27, 2018 12:56 PM >> To: kbuild test robot; Limonciello, Mario >> Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart

RE: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

> -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Friday, April 27, 2018 12:56 PM > To: kbuild test robot; Limonciello, Mario > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware) > Subject: Re: drivers/platform/x86/dell-smbios-wmi.c:66:

RE: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

> -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Friday, April 27, 2018 12:56 PM > To: kbuild test robot; Limonciello, Mario > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware) > Subject: Re: drivers/platform/x86/dell-smbios-wmi.c:66:

Re: [net-next] ipv6: sr: Extract the right key values for "seg6_make_flowlabel"

From: Ahmed Abdelsalam Date: Thu, 26 Apr 2018 16:11:11 +0200 > @@ -119,6 +119,9 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct > ipv6_sr_hdr *osrh, int proto) > int hdrlen, tot_len, err; > __be32 flowlabel; > > + inner_hdr = ipv6_hdr(skb); You have

Re: [net-next] ipv6: sr: Extract the right key values for "seg6_make_flowlabel"

From: Ahmed Abdelsalam Date: Thu, 26 Apr 2018 16:11:11 +0200 > @@ -119,6 +119,9 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct > ipv6_sr_hdr *osrh, int proto) > int hdrlen, tot_len, err; > __be32 flowlabel; > > + inner_hdr = ipv6_hdr(skb); You have to make this

Re: [PATCH] video: fbdev: omap2: remove rfbi

On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote: > Hi, > > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > > > The RFBI driver has not worked nor compiled for many years. There

Re: [PATCH] video: fbdev: omap2: remove rfbi

On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote: > Hi, > > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > > > The RFBI driver has not worked nor compiled for many years. There

[PATCH v3] clk: at91: PLL recalc_rate() now using cached MUL+DIV values

Stephen Boyd , linux-...@vger.kernel.org, linux-arm-ker...@lists.infradead.org, linux-kernel@vger.kernel.org Bcc: Subject: [PATCH v3] clk: at91: PLL recalc_rate() now using cached MUL and DIV values Reply-To: When a USB device is connected to the USB host port on the SAM9N12

[PATCH v3] clk: at91: PLL recalc_rate() now using cached MUL+DIV values

Stephen Boyd , linux-...@vger.kernel.org, linux-arm-ker...@lists.infradead.org, linux-kernel@vger.kernel.org Bcc: Subject: [PATCH v3] clk: at91: PLL recalc_rate() now using cached MUL and DIV values Reply-To: When a USB device is connected to the USB host port on the SAM9N12 then you get "-62"

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 10:20:25AM -0700, Martin KaFai Lau wrote: > On Fri, Apr 27, 2018 at 05:04:59PM +0300, Dan Carpenter wrote: > > We know "err" is zero so we can remove these and pull the code in one > > indent level. > > > > Signed-off-by: Dan Carpenter > Thanks

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 10:20:25AM -0700, Martin KaFai Lau wrote: > On Fri, Apr 27, 2018 at 05:04:59PM +0300, Dan Carpenter wrote: > > We know "err" is zero so we can remove these and pull the code in one > > indent level. > > > > Signed-off-by: Dan Carpenter > Thanks for the simplification! >

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

On 04/27/2018 06:43 AM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 0644f186fc9d77bb5bd198369e59fb28927a3692 > commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: > Link all dell-smbios-* modules

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

On 04/27/2018 06:43 AM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 0644f186fc9d77bb5bd198369e59fb28927a3692 > commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: > Link all dell-smbios-* modules

Re: [PATCH net-next] geneve: fix build with modular IPV6

From: Tobias Regnery Date: Thu, 26 Apr 2018 12:36:36 +0200 > Commit c40e89fd358e ("geneve: configure MTU based on a lower device") added > an IS_ENABLED(CONFIG_IPV6) to geneve, leading to the following link error > with CONFIG_GENEVE=y and CONFIG_IPV6=m: > >

Re: [PATCH net-next] geneve: fix build with modular IPV6

From: Tobias Regnery Date: Thu, 26 Apr 2018 12:36:36 +0200 > Commit c40e89fd358e ("geneve: configure MTU based on a lower device") added > an IS_ENABLED(CONFIG_IPV6) to geneve, leading to the following link error > with CONFIG_GENEVE=y and CONFIG_IPV6=m: > > drivers/net/geneve.o: In function

[PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes

Hi x86 maintainers, This set is basically unchanged from the last post. There was some previous discussion about other ways to fix this with the ppc folks (Ram Pai), but we've concluded that this x86-specific fix is fine. I think Ram had a different fix for ppc. Changes from v2: * Clarified

[PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes

Hi x86 maintainers, This set is basically unchanged from the last post. There was some previous discussion about other ways to fix this with the ppc folks (Ram Pai), but we've concluded that this x86-specific fix is fine. I think Ram had a different fix for ppc. Changes from v2: * Clarified

[PATCH 2/9] x86, pkeys, selftests: save off 'prot' for allocations

From: Dave Hansen This makes it possible to to tell what 'prot' a given allocation is supposed to have. That way, if we want to change just the pkey, we know what 'prot' to pass to mprotect_pkey(). Also, keep a record of the most recent allocation so the tests can

[PATCH 2/9] x86, pkeys, selftests: save off 'prot' for allocations

From: Dave Hansen This makes it possible to to tell what 'prot' a given allocation is supposed to have. That way, if we want to change just the pkey, we know what 'prot' to pass to mprotect_pkey(). Also, keep a record of the most recent allocation so the tests can easily find it.

Re: pull-request: wireless-drivers 2018-04-26

From: Kalle Valo Date: Thu, 26 Apr 2018 13:12:54 +0300 > here's a pull request to net tree, more info below. Please let me know > if you have any problems. Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2018-04-26

From: Kalle Valo Date: Thu, 26 Apr 2018 13:12:54 +0300 > here's a pull request to net tree, more info below. Please let me know > if you have any problems. Pulled, thanks Kalle.

[PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

From: Dave Hansen I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the

[PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

From: Dave Hansen I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is

[PATCH 1/9] x86, pkeys: do not special case protection key 0

From: Dave Hansen mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user

[PATCH 1/9] x86, pkeys: do not special case protection key 0

From: Dave Hansen mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user visible effect of this is that

[PATCH 5/9] x86, pkeys, selftests: fix pointer math

From: Dave Hansen We dump out the entire area of the siginfo where the si_pkey_ptr is supposed to be. But, we do some math on the poitner, which is a u32. We intended to do byte math, not u32 math on the pointer. Cast it over to a u8* so it works. Also, move this

[PATCH 5/9] x86, pkeys, selftests: fix pointer math

From: Dave Hansen We dump out the entire area of the siginfo where the si_pkey_ptr is supposed to be. But, we do some math on the poitner, which is a u32. We intended to do byte math, not u32 math on the pointer. Cast it over to a u8* so it works. Also, move this block of code to below th

[PATCH 8/9] x86, pkeys, selftests: add allow faults on unknown keys

From: Dave Hansen The exec-only pkey is allocated inside the kernel and userspace is not told what it is. So, allow PK faults to occur that have an unknown key. Signed-off-by: Dave Hansen Cc: Ram Pai Cc: Thomas

[PATCH 8/9] x86, pkeys, selftests: add allow faults on unknown keys

From: Dave Hansen The exec-only pkey is allocated inside the kernel and userspace is not told what it is. So, allow PK faults to occur that have an unknown key. Signed-off-by: Dave Hansen Cc: Ram Pai Cc: Thomas Gleixner Cc: Dave Hansen Cc: Michael Ellermen Cc: Ingo Molnar Cc: Andrew

[PATCH 6/9] x86, pkeys, selftests: fix pkey exhaustion test off-by-one

From: Dave Hansen In our "exhaust all pkeys" test, we make sure that there is the expected number available. Turns out that the test did not cover the execute-only key, but discussed it anyway. It did *not* discuss the test-allocated key. Now that we have a test

[PATCH 6/9] x86, pkeys, selftests: fix pkey exhaustion test off-by-one

From: Dave Hansen In our "exhaust all pkeys" test, we make sure that there is the expected number available. Turns out that the test did not cover the execute-only key, but discussed it anyway. It did *not* discuss the test-allocated key. Now that we have a test for the mprotect(PROT_EXEC)

[PATCH 7/9] x86, pkeys, selftests: factor out "instruction page"

From: Dave Hansen We currently have an execute-only test, but it is for the explicit mprotect_pkey() interface. We will soon add a test for the implicit mprotect(PROT_EXEC) enterface. We need this code in both tests. Signed-off-by: Dave Hansen

[PATCH 9/9] x86, pkeys, selftests: add PROT_EXEC test

From: Dave Hansen Under the covers, implement executable-only memory with protection keys when userspace calls mprotect(PROT_EXEC). But, we did not have a selftest for that. Now we do. Signed-off-by: Dave Hansen Cc: Ram Pai

[PATCH 9/9] x86, pkeys, selftests: add PROT_EXEC test

From: Dave Hansen Under the covers, implement executable-only memory with protection keys when userspace calls mprotect(PROT_EXEC). But, we did not have a selftest for that. Now we do. Signed-off-by: Dave Hansen Cc: Ram Pai Cc: Thomas Gleixner Cc: Dave Hansen Cc: Michael Ellermen Cc:

[PATCH 7/9] x86, pkeys, selftests: factor out "instruction page"

From: Dave Hansen We currently have an execute-only test, but it is for the explicit mprotect_pkey() interface. We will soon add a test for the implicit mprotect(PROT_EXEC) enterface. We need this code in both tests. Signed-off-by: Dave Hansen Cc: Ram Pai Cc: Thomas Gleixner Cc: Dave

[PATCH 3/9] x86, pkeys, selftests: add a test for pkey 0

From: Dave Hansen Protection key 0 is the default key for all memory and will not normally come back from pkey_alloc(). But, you might still want pass it to mprotect_pkey(). This check ensures that you can use pkey 0. Signed-off-by: Dave Hansen

[PATCH 3/9] x86, pkeys, selftests: add a test for pkey 0

From: Dave Hansen Protection key 0 is the default key for all memory and will not normally come back from pkey_alloc(). But, you might still want pass it to mprotect_pkey(). This check ensures that you can use pkey 0. Signed-off-by: Dave Hansen Cc: Ram Pai Cc: Thomas Gleixner Cc: Dave

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > The RFBI driver has not worked nor compiled for many years. There are > very few boards out there that use RFBI, and no one has stepped

Re: [PATCH] video: fbdev: omap2: remove rfbi

Hi, On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > The RFBI driver has not worked nor compiled for many years. There are > very few boards out there that use RFBI, and no one has stepped

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

On 04/27/2018 06:56 PM, Robin Murphy wrote: Hi Thomas, On 25/04/18 14:21, Thomas Hellstrom wrote: Hi, Robin, Thanks for the patch. It was some time since I put together that code, but I remember hitting something similar to

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

On 04/27/2018 06:56 PM, Robin Murphy wrote: Hi Thomas, On 25/04/18 14:21, Thomas Hellstrom wrote: Hi, Robin, Thanks for the patch. It was some time since I put together that code, but I remember hitting something similar to

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Wed, Apr 25 2018 at 15:41 -0600, Matthias Kaehlcke wrote: On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: Sleep and wake requests are sent when the application processor subsystem of the SoC is entering deep sleep states like in suspend. These requests help lower the system power

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Wed, Apr 25 2018 at 15:41 -0600, Matthias Kaehlcke wrote: On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: Sleep and wake requests are sent when the application processor subsystem of the SoC is entering deep sleep states like in suspend. These requests help lower the system power

Re: [RFC PATCH 0/9] Enable THP migration for all possible architectures

On Thu, 26 Apr 2018 10:27:55 -0400 Zi Yan wrote: > From: Zi Yan > > Hi all, > > THP migration is only enabled on x86_64 with a special > ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for > all architectures that uses transparent

Re: [RFC PATCH 0/9] Enable THP migration for all possible architectures

On Thu, 26 Apr 2018 10:27:55 -0400 Zi Yan wrote: > From: Zi Yan > > Hi all, > > THP migration is only enabled on x86_64 with a special > ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for > all architectures that uses transparent hugepage, so that special macro can > be

Re: kernel-4.9.94 compile error: 'KMOD_DECOMP_LEN' undeclared

[adding some Cc:] On 04/14/2018 02:41 AM, Teck Choon Giam wrote: > Hi, > > Compile linux-4.9.94 will have error related to KMOD_DECOMP_LEN > undeclared. Searching string related to KMOD_DECOMP_LEN in > linux-4.9.94 and linux-4.15.17 sources as below: > > sh-4.2# grep -r KMOD_DECOMP_LEN

Re: kernel-4.9.94 compile error: 'KMOD_DECOMP_LEN' undeclared

[adding some Cc:] On 04/14/2018 02:41 AM, Teck Choon Giam wrote: > Hi, > > Compile linux-4.9.94 will have error related to KMOD_DECOMP_LEN > undeclared. Searching string related to KMOD_DECOMP_LEN in > linux-4.9.94 and linux-4.15.17 sources as below: > > sh-4.2# grep -r KMOD_DECOMP_LEN

Re: [PATCH] NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2

From: SZ Lin (林上智) Date: Thu, 26 Apr 2018 14:30:13 +0800 > This patch adds support for PID 0x90b2 of ublox R410M. > > qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer > [/dev/cdc-wdm0] Device manufacturer retrieved: > Manufacturer: 'u-blox' > > qmicli -d /dev/cdc-wdm0

Re: [PATCH] NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2

From: SZ Lin (林上智) Date: Thu, 26 Apr 2018 14:30:13 +0800 > This patch adds support for PID 0x90b2 of ublox R410M. > > qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer > [/dev/cdc-wdm0] Device manufacturer retrieved: > Manufacturer: 'u-blox' > > qmicli -d /dev/cdc-wdm0 --dms-get-model >

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 05:04:59PM +0300, Dan Carpenter wrote: > We know "err" is zero so we can remove these and pull the code in one > indent level. > > Signed-off-by: Dan Carpenter Thanks for the simplification! Acked-by: Martin KaFai Lau > --- >

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 05:04:59PM +0300, Dan Carpenter wrote: > We know "err" is zero so we can remove these and pull the code in one > indent level. > > Signed-off-by: Dan Carpenter Thanks for the simplification! Acked-by: Martin KaFai Lau > --- > This applies to the BPF tree (linux-next) >

<    1   2   3   4   5   6   7   8   9   10   >