[tip:irq/urgent] irqchip/mbigen: Fix potential NULL dereferencing

Commit-ID: ad7cc3c0c57d77b442db323056354d0e49833569 Gitweb: http://git.kernel.org/tip/ad7cc3c0c57d77b442db323056354d0e49833569 Author: Hanjun Guo AuthorDate: Fri, 12 May 2017 11:55:27 +0800 Committer: Thomas Gleixner CommitDate: Fri, 12 May

[tip:irq/urgent] irqchip/mbigen: Fix potential NULL dereferencing

Commit-ID: ad7cc3c0c57d77b442db323056354d0e49833569 Gitweb: http://git.kernel.org/tip/ad7cc3c0c57d77b442db323056354d0e49833569 Author: Hanjun Guo AuthorDate: Fri, 12 May 2017 11:55:27 +0800 Committer: Thomas Gleixner CommitDate: Fri, 12 May 2017 10:25:37 +0200 irqchip/mbigen: Fix

Re: [PATCH] brcmfmac: btcoex: replace init_timer with setup_timer

as compile checked with: x86_64_defconfig + CONFIG_BRCMFMAC=y + CONFIG_BRCMFMAC_USB=y + CONFIG_BRCMFMAC_PCIE=y + CONFIG_BRCM_TRACING=y + CONFIG_BRCMDBG=y Kernel version: 4.11.0 (localversion-next is next-20170512) How is this different from the first version? https://patchwork.kernel.org/patch/9

Re: [PATCH] brcmfmac: btcoex: replace init_timer with setup_timer

+ CONFIG_BRCMFMAC_PCIE=y + CONFIG_BRCM_TRACING=y + CONFIG_BRCMDBG=y Kernel version: 4.11.0 (localversion-next is next-20170512) How is this different from the first version? https://patchwork.kernel.org/patch/9709467/ Hi Kalle, This is actually the third version. You are referring

[tip:irq/urgent] irqchip/mbigen: Fix memory mapping code

Commit-ID: 5ba9b0a14132d0b8d97affe909f324045a968d03 Gitweb: http://git.kernel.org/tip/5ba9b0a14132d0b8d97affe909f324045a968d03 Author: Hanjun Guo AuthorDate: Fri, 12 May 2017 11:55:26 +0800 Committer: Thomas Gleixner CommitDate: Fri, 12 May

[tip:irq/urgent] irqchip/mbigen: Fix memory mapping code

Commit-ID: 5ba9b0a14132d0b8d97affe909f324045a968d03 Gitweb: http://git.kernel.org/tip/5ba9b0a14132d0b8d97affe909f324045a968d03 Author: Hanjun Guo AuthorDate: Fri, 12 May 2017 11:55:26 +0800 Committer: Thomas Gleixner CommitDate: Fri, 12 May 2017 10:25:37 +0200 irqchip/mbigen: Fix

Re: [alsa-devel] future of sounds/oss

On Fri, May 12, 2017 at 09:27:56AM +0200, Takashi Iwai wrote: > But, looking at the tree again, I noticed that ALSA isn't built yet at > all for m68k. I don't remember why it's disabled. > Jaroslav, do you know the reason behind it? Might also just be because the m68k port had been dead in

Re: [alsa-devel] future of sounds/oss

On Fri, May 12, 2017 at 09:27:56AM +0200, Takashi Iwai wrote: > But, looking at the tree again, I noticed that ALSA isn't built yet at > all for m68k. I don't remember why it's disabled. > Jaroslav, do you know the reason behind it? Might also just be because the m68k port had been dead in

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu 11-05-17 14:59:43, J. Bruce Fields wrote: > On Wed, Apr 05, 2017 at 02:14:09PM -0400, J. Bruce Fields wrote: > > On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote: > > > 1) Keep i_version as is, make clients also check for i_ctime. > > > > That would be a protocol revision, which

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu 11-05-17 14:59:43, J. Bruce Fields wrote: > On Wed, Apr 05, 2017 at 02:14:09PM -0400, J. Bruce Fields wrote: > > On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote: > > > 1) Keep i_version as is, make clients also check for i_ctime. > > > > That would be a protocol revision, which

Re: Clarification for general change acceptance

> Developer reputation matters for somewhat controversial > patches being applied as well as non-controversial and > obviously correct patches being ignored. I am aware that there are more factors involved. > Your reputation means most all of your patches fall into > the latter category. I

Re: Clarification for general change acceptance

> Developer reputation matters for somewhat controversial > patches being applied as well as non-controversial and > obviously correct patches being ignored. I am aware that there are more factors involved. > Your reputation means most all of your patches fall into > the latter category. I

Re: [PATCH v2 1/8] drm: Add crtc/encoder/bridge->mode_valid() callbacks

Hi Daniel, On Wednesday 10 May 2017 10:03:37 Daniel Vetter wrote: > On Tue, May 09, 2017 at 06:00:08PM +0100, Jose Abreu wrote: > > This adds a new callback to crtc, encoder and bridge helper functions > > called mode_valid(). This callback shall be implemented if the > > corresponding component

Re: [PATCH v2 1/8] drm: Add crtc/encoder/bridge->mode_valid() callbacks

Hi Daniel, On Wednesday 10 May 2017 10:03:37 Daniel Vetter wrote: > On Tue, May 09, 2017 at 06:00:08PM +0100, Jose Abreu wrote: > > This adds a new callback to crtc, encoder and bridge helper functions > > called mode_valid(). This callback shall be implemented if the > > corresponding component

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:11 AM, Al Viro wrote: > Anyway, what's special about modules? IDGI... One of the arguments that came up earlier was code in external modules being mostly unaudited, sometimes without any source code available at all but still used in devices.

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:11 AM, Al Viro wrote: > Anyway, what's special about modules? IDGI... One of the arguments that came up earlier was code in external modules being mostly unaudited, sometimes without any source code available at all but still used in devices. If modules can't do

Re: [PATCH] pinctrl: when claiming hog, skip maps not served by same device

>> +/* >> + * If pctldev is not null, we are claiming hog for it, >> + * that means, setting that is served by pctldev by itself. >> + * >> + * Thus we must skip map that is for this device but is served >> + * by other

Re: [PATCH] pinctrl: when claiming hog, skip maps not served by same device

>> +/* >> + * If pctldev is not null, we are claiming hog for it, >> + * that means, setting that is served by pctldev by itself. >> + * >> + * Thus we must skip map that is for this device but is served >> + * by other

Re: [PATCH] brcmfmac: btcoex: replace init_timer with setup_timer

t; > Patch was compile checked with: x86_64_defconfig + CONFIG_BRCMFMAC=y + > CONFIG_BRCMFMAC_USB=y + CONFIG_BRCMFMAC_PCIE=y + CONFIG_BRCM_TRACING=y + > CONFIG_BRCMDBG=y > > Kernel version: 4.11.0 (localversion-next is next-20170512) How is this different from the first version? https://

Re: [PATCH] brcmfmac: btcoex: replace init_timer with setup_timer

IG_BRCMFMAC_USB=y + CONFIG_BRCMFMAC_PCIE=y + CONFIG_BRCM_TRACING=y + > CONFIG_BRCMDBG=y > > Kernel version: 4.11.0 (localversion-next is next-20170512) How is this different from the first version? https://patchwork.kernel.org/patch/9709467/ Always add patch version "[PATCH v2]" and a

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 01:11:26AM -0700, Christoph Hellwig wrote: > But it won't help against exploits modifying addr_limit manually. Or the ones setting current->cred to that of init. Your point being?

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 01:11:26AM -0700, Christoph Hellwig wrote: > But it won't help against exploits modifying addr_limit manually. Or the ones setting current->cred to that of init. Your point being?

Re: [PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

On Thu, 11 May 2017 11:31:26 -0700 Eric Anholt wrote: > Another 100 lines of boilerplate gone. Bridges aren't supported yet, > but will be trivial to add later. > > Signed-off-by: Eric Anholt > --- > [...] > @@ -1082,28 +993,13 @@ int ltdc_load(struct

Re: [PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

On Thu, 11 May 2017 11:31:26 -0700 Eric Anholt wrote: > Another 100 lines of boilerplate gone. Bridges aren't supported yet, > but will be trivial to add later. > > Signed-off-by: Eric Anholt > --- > [...] > @@ -1082,28 +993,13 @@ int ltdc_load(struct drm_device *ddev) > >

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, May 10, 2017 at 3:48 PM, Jeff Layton wrote: > I was thinking that you'd need some well-defined way to tell whether the > string should be replaced. If the thing just hangs out across syscalls, > then you don't know when it got put there. Is it a leftover from a >

Re: [PATCH 3/9] VFS: Introduce a mount context

On Wed, May 10, 2017 at 3:48 PM, Jeff Layton wrote: > I was thinking that you'd need some well-defined way to tell whether the > string should be replaced. If the thing just hangs out across syscalls, > then you don't know when it got put there. Is it a leftover from a > previous syscall or did

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Eliminate _what_? ->read()

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Eliminate _what_? ->read()

Re: [PATCH] mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform

On Tue, 09 May 2017, Andy Shevchenko wrote: > On Tue, 2017-05-09 at 06:40 +0200, Jan Kiszka wrote: > > The SIMATIC IOT2000 is derived from the Galileo Gen2 board and shares > > its I2C frequency. > > > > Signed-off-by: Jan Kiszka > > > Signed-off-by: Sascha Weisenberger

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Should be fairly doable and

Re: [PATCH] mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform

On Tue, 09 May 2017, Andy Shevchenko wrote: > On Tue, 2017-05-09 at 06:40 +0200, Jan Kiszka wrote: > > The SIMATIC IOT2000 is derived from the Galileo Gen2 board and shares > > its I2C frequency. > > > > Signed-off-by: Jan Kiszka > > > Signed-off-by: Sascha Weisenberger > > Hmm... I thought

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:43:40AM +0200, Arnd Bergmann wrote: > How realistic and how useful would it be to first completely eliminate > the ones that are in loadable modules and then wrapping the definition > in #ifndef MODULE (or even make it an extern function)? Should be fairly doable and

Re: [PATCH] mm/madvise: Dont poison entire HugeTLB page for single page errors

On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote: > Currently soft_offline_page() migrates the entire HugeTLB page, then > dequeues it from the active list by making it a dangling HugeTLB page > which ofcourse can not be used further and marks the entire HugeTLB > page as

Re: [PATCH] mm/madvise: Dont poison entire HugeTLB page for single page errors

On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote: > Currently soft_offline_page() migrates the entire HugeTLB page, then > dequeues it from the active list by making it a dangling HugeTLB page > which ofcourse can not be used further and marks the entire HugeTLB > page as

[PATCH 3/3] mdacon: replace MDA_ADDR macro by inline function

MDA_ADDR is one of those macros which could be an inline function. So convert MDA_ADDR to mda_addr. Note that we take x and y as unsigned now. But they are absolute coordinates, so this is no problem. Signed-off-by: Jiri Slaby Cc: Tomi Valkeinen Cc:

[PATCH 3/3] mdacon: replace MDA_ADDR macro by inline function

MDA_ADDR is one of those macros which could be an inline function. So convert MDA_ADDR to mda_addr. Note that we take x and y as unsigned now. But they are absolute coordinates, so this is no problem. Signed-off-by: Jiri Slaby Cc: Tomi Valkeinen Cc: --- drivers/video/console/mdacon.c | 19

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

On Sun, May 07, 2017 at 02:56:36PM +0200, Guillaume Brogi wrote: > On Sat, Apr 08, 2017 at 08:32:36PM +0200, Guillaume Brogi wrote: > > On Sat, Apr 08, 2017 at 12:31:25PM +0200, Greg Kroah-Hartman wrote: > > > On Sun, Mar 26, 2017 at 12:24:14AM +0100, Guillaume Brogi wrote: > > > > > > > > This

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

On Sun, May 07, 2017 at 02:56:36PM +0200, Guillaume Brogi wrote: > On Sat, Apr 08, 2017 at 08:32:36PM +0200, Guillaume Brogi wrote: > > On Sat, Apr 08, 2017 at 12:31:25PM +0200, Greg Kroah-Hartman wrote: > > > On Sun, Mar 26, 2017 at 12:24:14AM +0100, Guillaume Brogi wrote: > > > > > > > > This

[PATCH 2/3] mdacon: make mda_vram_base u16 *

Given every user of mda_vram_base expects a pointer, let mda_vram_base be a pointer to u16. The offset calculation in mda_detect had to be adjusted by / 2 (due to different pointer arithmetic now). We introduce a cast to a value returned from VGA_MAP_MEM. But I will change VGA_MAP_MEM to return

[PATCH 2/3] mdacon: make mda_vram_base u16 *

Given every user of mda_vram_base expects a pointer, let mda_vram_base be a pointer to u16. The offset calculation in mda_detect had to be adjusted by / 2 (due to different pointer arithmetic now). We introduce a cast to a value returned from VGA_MAP_MEM. But I will change VGA_MAP_MEM to return

Re: [PATCH 1/2] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

Hello Song On 05/12/2017 03:51 AM, Song Xiaowei wrote: > From: songxiaowei > > Hisilicon PCIe Driver shares the common functions fo PCIe dw-host > > The poweron functions is developed on hi3660 SoC, while Others Functions > are common for Kirin series SoCs. > >

Re: [PATCH 1/2] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

Hello Song On 05/12/2017 03:51 AM, Song Xiaowei wrote: > From: songxiaowei > > Hisilicon PCIe Driver shares the common functions fo PCIe dw-host > > The poweron functions is developed on hi3660 SoC, while Others Functions > are common for Kirin series SoCs. > > Lowpower(L1ss and SR), hotplug

[PATCH 1/3] mdacon: align code in mda_detect properly

This is just a whitespace cleanup. The code was a mess having multiple commands on one line like: scr_writew(0xAA55, p); if (scr_readw(p) == 0xAA55) count++; Indent that properly and make it nicer for reading. Signed-off-by: Jiri Slaby Cc: Tomi Valkeinen

Re: [PATCH v3 3/3] drivers:power:twl4030-charger: remove nonstandard max_current sysfs attribute

Hi Pavel, > Am 12.05.2017 um 00:35 schrieb Pavel Machek : > > On Fri 2017-04-14 20:25:57, H. Nikolaus Schaller wrote: >> Signed-off-by: H. Nikolaus Schaller > > You should explain how to obtain equivalent functionality without that > attribute. By using the

[PATCH 1/3] mdacon: align code in mda_detect properly

This is just a whitespace cleanup. The code was a mess having multiple commands on one line like: scr_writew(0xAA55, p); if (scr_readw(p) == 0xAA55) count++; Indent that properly and make it nicer for reading. Signed-off-by: Jiri Slaby Cc: Tomi Valkeinen Cc: ---

Re: [PATCH v3 3/3] drivers:power:twl4030-charger: remove nonstandard max_current sysfs attribute

Hi Pavel, > Am 12.05.2017 um 00:35 schrieb Pavel Machek : > > On Fri 2017-04-14 20:25:57, H. Nikolaus Schaller wrote: >> Signed-off-by: H. Nikolaus Schaller > > You should explain how to obtain equivalent functionality without that > attribute. By using the standard attribute as defined here:

Re: [PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings.

First off, why the "Re:" in the subject? Second, your subject sucks :) Try making it a bit more descriptive as to what you are doing, "fixing sparse warnings" is very vague. On Wed, May 10, 2017 at 03:15:38PM +0200, Karim Eshapa wrote: > Change the types of capture header, finally we need the

Re: [PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings.

First off, why the "Re:" in the subject? Second, your subject sucks :) Try making it a bit more descriptive as to what you are doing, "fixing sparse warnings" is very vague. On Wed, May 10, 2017 at 03:15:38PM +0200, Karim Eshapa wrote: > Change the types of capture header, finally we need the

Re: [PATCH v2 4/7] drm/mediatek: Use the panel-bridge helper.

On Thu, 11 May 2017 11:31:25 -0700 Eric Anholt wrote: > Avoids a bunch of connector boilerplate. Note that this causes panel > prepare() to be moved before mtk_dsi_poweron() and unprepare() to be > after poweroff(). I think this is the expected usage of the panel API > (enable

Re: [PATCH v2 4/7] drm/mediatek: Use the panel-bridge helper.

On Thu, 11 May 2017 11:31:25 -0700 Eric Anholt wrote: > Avoids a bunch of connector boilerplate. Note that this causes panel > prepare() to be moved before mtk_dsi_poweron() and unprepare() to be > after poweroff(). I think this is the expected usage of the panel API > (enable should be when

[PATCH 1/1] sisusb_con: fix coccinelle warning

After commit d705ff3818 (tty: vt, cleanup and document con_scroll), in the coccinelle output, we can see: drivers/usb/misc/sisusbvga/sisusb_con.c:852:8-9: WARNING: return of 0/1 in function 'sisusbcon_scroll_area' with return type bool Return true instead of 1 in the function returning bool

[PATCH 1/1] sisusb_con: fix coccinelle warning

After commit d705ff3818 (tty: vt, cleanup and document con_scroll), in the coccinelle output, we can see: drivers/usb/misc/sisusbvga/sisusb_con.c:852:8-9: WARNING: return of 0/1 in function 'sisusbcon_scroll_area' with return type bool Return true instead of 1 in the function returning bool

[RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

A new section, secdata, in the setup header is introduced to store the distro-specific security version which is designed to help the bootloader to warn the user when loading a less secure or vulnerable kernel. The secdata section can be presented as the following: struct sec_hdr { __u16

[RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

A new section, secdata, in the setup header is introduced to store the distro-specific security version which is designed to help the bootloader to warn the user when loading a less secure or vulnerable kernel. The secdata section can be presented as the following: struct sec_hdr { __u16

Re: [Bridge] [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls

IP MTU and L2 MTU are different animals. IMHO IP MTU is for fragmentation at sender of a link. There is no need dropping IP packets at receiver with size > configured IP MTU. IP packets with size > receiver L2 MTU will be dropped at sub-IP layer. For this patch: if veth has some notion on L2

Re: [Bridge] [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls

IP MTU and L2 MTU are different animals. IMHO IP MTU is for fragmentation at sender of a link. There is no need dropping IP packets at receiver with size > configured IP MTU. IP packets with size > receiver L2 MTU will be dropped at sub-IP layer. For this patch: if veth has some notion on L2

Re: [PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper.

On Thu, 11 May 2017 11:31:24 -0700 Eric Anholt wrote: > Another 100 lines of boilerplate gone, while allowing for bridges to > be connected in the display chain. > > Signed-off-by: Eric Anholt Reviewed-by: Boris Brezillon

Re: [PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper.

On Thu, 11 May 2017 11:31:24 -0700 Eric Anholt wrote: > Another 100 lines of boilerplate gone, while allowing for bridges to > be connected in the display chain. > > Signed-off-by: Eric Anholt Reviewed-by: Boris Brezillon > --- > drivers/gpu/drm/vc4/vc4_dpi.c | 164 >

Re: [PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support bridges.

On Thu, 11 May 2017 11:31:23 -0700 Eric Anholt wrote: > The newer version of the RPi panel driver is going to be a combination > of a bridge and a panel, but we should also support panels without a > bridge, so the panel-bridge layer lets us do that cleanly. > > v2: Drop "dev"

Re: [PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support bridges.

On Thu, 11 May 2017 11:31:23 -0700 Eric Anholt wrote: > The newer version of the RPi panel driver is going to be a combination > of a bridge and a panel, but we should also support panels without a > bridge, so the panel-bridge layer lets us do that cleanly. > > v2: Drop "dev" argument. > >

Re: [alsa-devel] future of sounds/oss

On Fri, 12 May 2017 09:30:04 +0200, Geert Uytterhoeven wrote: > > Hi Iwai-san, > > On Fri, May 12, 2017 at 9:27 AM, Takashi Iwai wrote: > > On Fri, 12 May 2017 09:17:35 +0200, > > Geert Uytterhoeven wrote: > >> On Fri, May 12, 2017 at 9:10 AM, Takashi Iwai wrote:

Re: [alsa-devel] future of sounds/oss

On Fri, 12 May 2017 09:30:04 +0200, Geert Uytterhoeven wrote: > > Hi Iwai-san, > > On Fri, May 12, 2017 at 9:27 AM, Takashi Iwai wrote: > > On Fri, 12 May 2017 09:17:35 +0200, > > Geert Uytterhoeven wrote: > >> On Fri, May 12, 2017 at 9:10 AM, Takashi Iwai wrote: > >> > On Fri, 12 May 2017

[PATCH v3 7/9] arm: dts: mt7623: enable the usb device on the mt7623n rfb

From: John Crispin All versions of the mt7623n RFB have an USB port so enable the device. There is a gpio that gets used to power up the port supply. Add support for this gpio using the fixed-regulator driver. Signed-off-by: John Crispin Signed-off-by: Sean

[PATCH v3 7/9] arm: dts: mt7623: enable the usb device on the mt7623n rfb

From: John Crispin All versions of the mt7623n RFB have an USB port so enable the device. There is a gpio that gets used to power up the port supply. Add support for this gpio using the fixed-regulator driver. Signed-off-by: John Crispin Signed-off-by: Sean Wang ---

Re: [PATCH v2 0/3] irqchip/mbigen: bugfixs

On 12/05/17 04:55, Hanjun Guo wrote: > From: Hanjun Guo > > Here are 3 bugfixes for mbigen: > > Patch 1 is a critical bugfix which to fix the mbigen probe failure, > commit 216646e4d82e ("irqchip/mbigen: Fix return value check in > mbigen_device_probe()") introduced this

Re: [PATCH v2 0/3] irqchip/mbigen: bugfixs

On 12/05/17 04:55, Hanjun Guo wrote: > From: Hanjun Guo > > Here are 3 bugfixes for mbigen: > > Patch 1 is a critical bugfix which to fix the mbigen probe failure, > commit 216646e4d82e ("irqchip/mbigen: Fix return value check in > mbigen_device_probe()") introduced this breakage; > > Patch 2

[PATCH v3 5/9] ARM: mediatek: add MT7623a smp bringup code

From: Sean Wang Add support for booting secondary CPUs on MT7623a. Signed-off-by: Sean Wang --- arch/arm/mach-mediatek/mediatek.c | 2 ++ arch/arm/mach-mediatek/platsmp.c | 1 + 2 files changed, 3 insertions(+) diff --git

[PATCH v3 5/9] ARM: mediatek: add MT7623a smp bringup code

From: Sean Wang Add support for booting secondary CPUs on MT7623a. Signed-off-by: Sean Wang --- arch/arm/mach-mediatek/mediatek.c | 2 ++ arch/arm/mach-mediatek/platsmp.c | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/arm/mach-mediatek/mediatek.c

[PATCH v3 6/9] arm: dts: mt7623: cleanup the mt7623n rfb uart nodes

From: John Crispin This patch does a cleanup of the uart nodes in the dts file of the RFB. It adds aliases, enables 2 more uarts and explicitly sets the uart mode of the console. Signed-off-by: John Crispin Signed-off-by: Sean Wang

[PATCH v3 6/9] arm: dts: mt7623: cleanup the mt7623n rfb uart nodes

From: John Crispin This patch does a cleanup of the uart nodes in the dts file of the RFB. It adds aliases, enables 2 more uarts and explicitly sets the uart mode of the console. Signed-off-by: John Crispin Signed-off-by: Sean Wang --- arch/arm/boot/dts/mt7623n-rfb.dtsi | 16 +++-

[PATCH v3 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

From: Sean Wang Add support for the Bananapi R2 (BPI-R2) development board from BIPAI KEJI. Detailed hardware information for BPI-R2 which could be found on http://www.banana-pi.org/r2.html The patch currently only adds Mediatek GMAC, MT7530 Switch, the crypto engine,

[PATCH v3 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

From: Sean Wang Add support for the Bananapi R2 (BPI-R2) development board from BIPAI KEJI. Detailed hardware information for BPI-R2 which could be found on http://www.banana-pi.org/r2.html The patch currently only adds Mediatek GMAC, MT7530 Switch, the crypto engine, USB, IR, I2S, I2C, UART,

[PATCH v3 2/9] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi

From: Sean Wang There are 2 versions of the MT7623 SoC, the one is MT7623n and the other is MT7623a. MT7623n is almost identical to MT7623a but has some additional multimedia features. The reference boards are available as NAND or MMC and might have a different ethernet

[PATCH v3 2/9] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi

From: Sean Wang There are 2 versions of the MT7623 SoC, the one is MT7623n and the other is MT7623a. MT7623n is almost identical to MT7623a but has some additional multimedia features. The reference boards are available as NAND or MMC and might have a different ethernet setup. In order to

[PATCH v3 8/9] arm: dts: mt7623: enable the nand device on the mt7623n nand rfb

From: John Crispin Enable the nand device and setup pinmux on the mt7632m rfb with nand support. Signed-off-by: John Crispin Signed-off-by: Sean Wang --- arch/arm/boot/dts/mt7623n-rfb-nand.dts | 88 ++

[PATCH v3 8/9] arm: dts: mt7623: enable the nand device on the mt7623n nand rfb

From: John Crispin Enable the nand device and setup pinmux on the mt7632m rfb with nand support. Signed-off-by: John Crispin Signed-off-by: Sean Wang --- arch/arm/boot/dts/mt7623n-rfb-nand.dts | 88 ++ 1 file changed, 88 insertions(+) diff --git

[PATCH v3 3/9] dt-bindings: arm: mediatek: update for MT7623n SoC and relevant boards

From: Sean Wang Because there are two versions of MT7623 SoC that is MT7623a and MT7623n respectively. So update the part of MT7623n bindings to allow that people tend to differentiate which MT7623 SoC the boards applies. Signed-off-by: John Crispin

[PATCH v3 4/9] dt-bindings: arm: mediatek: add bindings for mediatek MT7623a SoC Platform

From: Sean Wang This adds DT binding documentation for Mediatek MT7623a Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/arm/mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v3 0/9] arm: dts: extend mt7623 support

From: Sean Wang Changes since v2: - exclude those patches already queued into v4.11-next/dts32 - exclude those patches already sent in separation - add mt7623a SoC basic support - update binding SoC for mt7623n and relevant boards Changes since v1: Continue the upstream

[PATCH v3 1/9] arm: dts: mt7623: add mt7623-mt6323.dtsi file

From: John Crispin MediaTek produces various PMICs. Which one is used depends on the actual circuit design. Instead of adding the correct PMIC node to every dts file we instead add a new intermediate dtsi file which adds the PMIC node. Additionally we also add the phandles for

[PATCH v3 4/9] dt-bindings: arm: mediatek: add bindings for mediatek MT7623a SoC Platform

From: Sean Wang This adds DT binding documentation for Mediatek MT7623a Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/arm/mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt

[PATCH v3 0/9] arm: dts: extend mt7623 support

From: Sean Wang Changes since v2: - exclude those patches already queued into v4.11-next/dts32 - exclude those patches already sent in separation - add mt7623a SoC basic support - update binding SoC for mt7623n and relevant boards Changes since v1: Continue the upstream journey based on the

[PATCH v3 1/9] arm: dts: mt7623: add mt7623-mt6323.dtsi file

From: John Crispin MediaTek produces various PMICs. Which one is used depends on the actual circuit design. Instead of adding the correct PMIC node to every dts file we instead add a new intermediate dtsi file which adds the PMIC node. Additionally we also add the phandles for the regulators to

[PATCH v3 3/9] dt-bindings: arm: mediatek: update for MT7623n SoC and relevant boards

From: Sean Wang Because there are two versions of MT7623 SoC that is MT7623a and MT7623n respectively. So update the part of MT7623n bindings to allow that people tend to differentiate which MT7623 SoC the boards applies. Signed-off-by: John Crispin Signed-off-by: Sean Wang ---

Re: [PATCH 1/4] drm/vc4: Adjust modes in DSI to work around the integer PLL divider.

On Thu, May 11, 2017 at 04:56:22PM -0700, Eric Anholt wrote: > BCM2835's PLLD_DSI1 divider doesn't give us many choices for our pixel > clocks, so to support panels on the Raspberry Pi we need to set a > higher pixel clock rate than requested and adjust the mode we program > to extend out the HFP

Re: [PATCH 1/4] drm/vc4: Adjust modes in DSI to work around the integer PLL divider.

On Thu, May 11, 2017 at 04:56:22PM -0700, Eric Anholt wrote: > BCM2835's PLLD_DSI1 divider doesn't give us many choices for our pixel > clocks, so to support panels on the Raspberry Pi we need to set a > higher pixel clock rate than requested and adjust the mode we program > to extend out the HFP

Re: [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

On 04/26/2017, 03:42 AM, Josh Poimboeuf wrote: >> @@ -323,7 +323,7 @@ ENTRY(resume_userspace) >> movl%esp, %eax >> callprepare_exit_to_usermode >> jmp restore_all >> -END(ret_from_exception) >> +ENDPROC(ret_from_exception) > > What exactly is the motivation of this

Re: [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

On 04/26/2017, 03:42 AM, Josh Poimboeuf wrote: >> @@ -323,7 +323,7 @@ ENTRY(resume_userspace) >> movl%esp, %eax >> callprepare_exit_to_usermode >> jmp restore_all >> -END(ret_from_exception) >> +ENDPROC(ret_from_exception) > > What exactly is the motivation of this

Re: vmbus: Delete an error message for a failed memory allocation in vmbus_device_create()

On Fri, 2017-05-12 at 09:32 +0200, SF Markus Elfring wrote: > Will patches be picked up also from contributors who got a special > development reputation anyhow? Yes. Developer reputation matters for somewhat controversial patches being applied as well as non-controversial and obviously correct

Re: vmbus: Delete an error message for a failed memory allocation in vmbus_device_create()

On Fri, 2017-05-12 at 09:32 +0200, SF Markus Elfring wrote: > Will patches be picked up also from contributors who got a special > development reputation anyhow? Yes. Developer reputation matters for somewhat controversial patches being applied as well as non-controversial and obviously correct

Re: [PATCH v3] KVM: x86: Fix potential preemption when get the current kvmclock timestamp

On 12/05/2017 03:12, Wanpeng Li wrote: > From: Wanpeng Li > > BUG: using __this_cpu_read() in preemptible [] code: > qemu-system-x86/2809 > caller is __this_cpu_preempt_check+0x13/0x20 > CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 > Call

Re: [PATCH v3] KVM: x86: Fix potential preemption when get the current kvmclock timestamp

On 12/05/2017 03:12, Wanpeng Li wrote: > From: Wanpeng Li > > BUG: using __this_cpu_read() in preemptible [] code: > qemu-system-x86/2809 > caller is __this_cpu_preempt_check+0x13/0x20 > CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 > Call Trace: >

Re: Is there an recommended way to refer to bitkeepr commits?

On Fri, 12 May 2017, Michael Ellerman wrote: > Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] > linux-2.5.66-signal-cleanup.patch") > > In your tree that is c3c107051660 ("[PATCH] > linux-2.5.66-signal-cleanup.patch"), > but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 9:15 AM, Al Viro wrote: > On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > >> > How about trying to remove all of them? If we could actually get rid >> > of all of them, we could drop the arch support, and we'd get faster, >> >

Re: Is there an recommended way to refer to bitkeepr commits?

On Fri, 12 May 2017, Michael Ellerman wrote: > Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] > linux-2.5.66-signal-cleanup.patch") > > In your tree that is c3c107051660 ("[PATCH] > linux-2.5.66-signal-cleanup.patch"), > but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 9:15 AM, Al Viro wrote: > On Fri, May 12, 2017 at 09:00:12AM +0200, Ingo Molnar wrote: > >> > How about trying to remove all of them? If we could actually get rid >> > of all of them, we could drop the arch support, and we'd get faster, >> > simpler, shorter uaccess code

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

Hello Brendan, [ ... ] > +static bool aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus) > +{ > + u32 irq_status, status_ack = 0, command = 0; > + struct i2c_msg *msg; > + u8 recv_byte; > + > + spin_lock(>lock); > + irq_status = readl(bus->base + ASPEED_I2C_INTR_STS_REG); > +

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

Hello Brendan, [ ... ] > +static bool aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus) > +{ > + u32 irq_status, status_ack = 0, command = 0; > + struct i2c_msg *msg; > + u8 recv_byte; > + > + spin_lock(>lock); > + irq_status = readl(bus->base + ASPEED_I2C_INTR_STS_REG); > +

[GIT PULL] x86 fixes

Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: fb8fb46c56289b3f34b5d90a4ec65e9e4e4544a5 x86/intel_rdt: Fix a typo in Documentation It's mostly misc fixes: - two boot crash fixes

[GIT PULL] x86 fixes

Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: fb8fb46c56289b3f34b5d90a4ec65e9e4e4544a5 x86/intel_rdt: Fix a typo in Documentation It's mostly misc fixes: - two boot crash fixes

<    7   8   9   10   11   12   13   14   >