[PATCH net-next v6 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with four integrated 10/100/1000Mbps Ethernet transceivers and one high speed SerDes interfaces. It belongs to the Topaz family and unlike the 88E6341 it does not have a TCAM. Signed-off-by: Gregory CLEMENT

[PATCH net-next v6 4/4] phy: marvell: Add support for the PHY embedded in the topaz switch

The PHY with the ID 0x1410C00 can be found embedded in the Marvell Topaz switches (88E6141/88E6341). It is compatible with the 88E1510 (at least for the temperature information), so add support for it, using the 88E1510 specific functions. Signed-off-by: Gregory CLEMENT

[PATCH net-next v6 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with four integrated 10/100/1000Mbps Ethernet transceivers and one high speed SerDes interfaces. It belongs to the Topaz family and unlike the 88E6341 it does not have a TCAM. Signed-off-by: Gregory CLEMENT ---

[PATCH net-next v6 4/4] phy: marvell: Add support for the PHY embedded in the topaz switch

The PHY with the ID 0x1410C00 can be found embedded in the Marvell Topaz switches (88E6141/88E6341). It is compatible with the 88E1510 (at least for the temperature information), so add support for it, using the 88E1510 specific functions. Signed-off-by: Gregory CLEMENT ---

[PATCH net-next v6 0/4] Add support for the ethernet switch on the ESPRESSObin

Hi, This set of patches adds support for the Marvell Ethernet Topaz switch family (88E6141/88E6341) which is found on the ESPRESSObin. With this series the network is usable on this board. I rebased the series again on the very last net-next/master which allowed me this time to benefit to the

[PATCH net-next v6 0/4] Add support for the ethernet switch on the ESPRESSObin

Hi, This set of patches adds support for the Marvell Ethernet Topaz switch family (88E6141/88E6341) which is found on the ESPRESSObin. With this series the network is usable on this board. I rebased the series again on the very last net-next/master which allowed me this time to benefit to the

[PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with four integrated 10/100/1000Mbps Ethernet transceivers and one high speed SerDes interfaces. It is partially compatible with switches of family 88E6352 and switches of family 88E6390. This commit adds an initial support for

[PATCH net-next v6 1/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

From: Romain Perier Some Marvell ethernet switches have internal ethernet transceivers with hardcoded phy addresses. These addresses can be greater than the number of ports or its value might be different than the associated port number. This is for example the

[PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with four integrated 10/100/1000Mbps Ethernet transceivers and one high speed SerDes interfaces. It is partially compatible with switches of family 88E6352 and switches of family 88E6390. This commit adds an initial support for

[PATCH net-next v6 1/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

From: Romain Perier Some Marvell ethernet switches have internal ethernet transceivers with hardcoded phy addresses. These addresses can be greater than the number of ports or its value might be different than the associated port number. This is for example the case for MV88E6341 that has 6

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

From: "Michael S. Tsirkin" Date: Tue, 24 Jan 2017 21:53:13 +0200 > I didn't realise. Why can't we? I thought that adjust_header is an > optional feature that userspace can test for, so no rush. No, we want the base set of XDP features to be present in all drivers supporting

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

From: "Michael S. Tsirkin" Date: Tue, 24 Jan 2017 21:53:13 +0200 > I didn't realise. Why can't we? I thought that adjust_header is an > optional feature that userspace can test for, so no rush. No, we want the base set of XDP features to be present in all drivers supporting XDP.

Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names

> diff --git a/include/linux/phy.h b/include/linux/phy.h > index 5c9d2529685fe215..f6ab919528ab3627 100644 > --- a/include/linux/phy.h > +++ b/include/linux/phy.h > @@ -25,7 +25,6 @@ > #include > #include > #include > -#include > > #include > > @@ -339,6 +338,8 @@ struct

Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names

> diff --git a/include/linux/phy.h b/include/linux/phy.h > index 5c9d2529685fe215..f6ab919528ab3627 100644 > --- a/include/linux/phy.h > +++ b/include/linux/phy.h > @@ -25,7 +25,6 @@ > #include > #include > #include > -#include > > #include > > @@ -339,6 +338,8 @@ struct

[PATCH 0/3] Fix zswap init failure behavior

If zswap fails to initialize itself at boot, it returns error from its init function; but for built-in drivers, that does not unload them; and more importantly, it doesn't prevent their sysfs module param interface from being created. In this case, changing the compressor or zpool param will

[PATCH 0/3] Fix zswap init failure behavior

If zswap fails to initialize itself at boot, it returns error from its init function; but for built-in drivers, that does not unload them; and more importantly, it doesn't prevent their sysfs module param interface from being created. In this case, changing the compressor or zpool param will

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On 01/24/2017 11:39 AM, Andy Shevchenko wrote: >> Are you concerned with storage, or what motivates the preference for >> bitfields vs. bools? > > Just matter of style. Up to you. > + { /* bit 5 */ +.name = "SD6:a:error", +.gpio =

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On 01/24/2017 11:39 AM, Andy Shevchenko wrote: >> Are you concerned with storage, or what motivates the preference for >> bitfields vs. bools? > > Just matter of style. Up to you. > + { /* bit 5 */ +.name = "SD6:a:error", +.gpio =

[PATCH 1/3] zswap: disable changing params if init fails

Add zswap_init_failed bool that prevents changing any of the module params, if init_zswap() fails, and set zswap_enabled to false. Change 'enabled' param to a callback, and check zswap_init_failed before allowing any change to 'enabled', 'zpool', or 'compressor' params. Any driver that is

[PATCH 2/3] zswap: allow initialization at boot without pool

Allow zswap to initialize at boot even if it can't create its pool due to a failure to create a zpool and/or compressor. Allow those to be created later, from the sysfs module param interface. Signed-off-by: Dan Streetman --- mm/zswap.c | 46

[PATCH 1/3] zswap: disable changing params if init fails

Add zswap_init_failed bool that prevents changing any of the module params, if init_zswap() fails, and set zswap_enabled to false. Change 'enabled' param to a callback, and check zswap_init_failed before allowing any change to 'enabled', 'zpool', or 'compressor' params. Any driver that is

[PATCH 2/3] zswap: allow initialization at boot without pool

Allow zswap to initialize at boot even if it can't create its pool due to a failure to create a zpool and/or compressor. Allow those to be created later, from the sysfs module param interface. Signed-off-by: Dan Streetman --- mm/zswap.c | 46 ++ 1

[PATCH 3/3] zswap: clear compressor or zpool param if invalid at init

If either the compressor and/or zpool param are invalid at boot, and their default value is also invalid, set the param to the empty string to indicate there is no compressor and/or zpool configured. This allows users to check the sysfs interface to see which param needs changing. Signed-off-by:

[PATCH 3/3] zswap: clear compressor or zpool param if invalid at init

If either the compressor and/or zpool param are invalid at boot, and their default value is also invalid, set the param to the empty string to indicate there is no compressor and/or zpool configured. This allows users to check the sysfs interface to see which param needs changing. Signed-off-by:

[PATCH 4/5] gpio: gpio-mm: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call with the devm_gpiochip_add_data call. In addition, the gpiomm_remove function has been

[PATCH 4/5] gpio: gpio-mm: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call with the devm_gpiochip_add_data call. In addition, the gpiomm_remove function has been

Re: [PATCH] kernel-doc: Handle returning pointers to pointers

Am 24.01.2017 um 16:35 schrieb Matthew Wilcox : > From: Markus Heiser [mailto:markus.hei...@darmarit.de] >> Am 23.01.2017 um 16:24 schrieb Jonathan Corbet : >>> Markus, would you consider sending out a new patch set for review? >> >> Yes, I send RFC soon

Re: [PATCH] kernel-doc: Handle returning pointers to pointers

Am 24.01.2017 um 16:35 schrieb Matthew Wilcox : > From: Markus Heiser [mailto:markus.hei...@darmarit.de] >> Am 23.01.2017 um 16:24 schrieb Jonathan Corbet : >>> Markus, would you consider sending out a new patch set for review? >> >> Yes, I send RFC soon ... > > Could I ask for some features?

[PATCH 1/5] gpio: 104-dio-48e: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 1/5] gpio: 104-dio-48e: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 3/5] gpio: 104-idio-16: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 3/5] gpio: 104-idio-16: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 5/5] gpio: ws16c48: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 5/5] gpio: ws16c48: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

Re: [PATCH net-next] net: dsa: Drop WARN() in tag_brcm.c

From: Florian Fainelli Date: Mon, 23 Jan 2017 19:19:07 -0800 > We may be able to see invalid Broadcom tags when the hardware and drivers are > misconfigured, or just while exercising the error path. Instead of flooding > the console with messages, flat out drop the packet.

[PATCH 2/5] gpio: 104-idi-48: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

Re: [PATCH net-next] net: dsa: Drop WARN() in tag_brcm.c

From: Florian Fainelli Date: Mon, 23 Jan 2017 19:19:07 -0800 > We may be able to see invalid Broadcom tags when the hardware and drivers are > misconfigured, or just while exercising the error path. Instead of flooding > the console with messages, flat out drop the packet. > > Signed-off-by:

[PATCH 2/5] gpio: 104-idi-48: Utilize devm_ functions in driver probe callback

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patch takes advantage of the resource manager functions and replaces the gpiochip_add_data call and request_irq call with the devm_gpiochip_add_data call and devm_request_irq call

[PATCH 0/5] gpio: Utilize devm_ functions in driver probe callbacks

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patchset takes advantage of the resource manager functions and replaces gpiochip_add_data calls and request_irq calls with devm_gpiochip_add_data calls and devm_request_irq calls

[PATCH 0/5] gpio: Utilize devm_ functions in driver probe callbacks

The devm_ resource manager functions allow memory to be automatically released when a device is unbound. This patchset takes advantage of the resource manager functions and replaces gpiochip_add_data calls and request_irq calls with devm_gpiochip_add_data calls and devm_request_irq calls

Re: fs/jffs2/readinode.c:189: faulty logic ?

On 01/24/2017 08:17 PM, David Binderman wrote: > > Hello there, > > > > >> This changes the logic of the code for equality case, please elaborate >> why this is OK. > > RTFM. > > Linux kernel file Documentation/rbtree.txt, around line 95, has the standard >

Re: fs/jffs2/readinode.c:189: faulty logic ?

On 01/24/2017 08:17 PM, David Binderman wrote: > > Hello there, > > > > >> This changes the logic of the code for equality case, please elaborate >> why this is OK. > > RTFM. > > Linux kernel file Documentation/rbtree.txt, around line 95, has the standard >

Re: [PATCH] nvdimm: constify device_type structures

On Tue, Jan 24, 2017 at 11:24 AM, Bhumika Goyal wrote: > Declare device_type structure as const as it is only stored in the > type field of a device structure. This field is of type const, so add > const to declaration of device_type structure. > > File size before: > text

Re: [PATCH] nvdimm: constify device_type structures

On Tue, Jan 24, 2017 at 11:24 AM, Bhumika Goyal wrote: > Declare device_type structure as const as it is only stored in the > type field of a device structure. This field is of type const, so add > const to declaration of device_type structure. > > File size before: > text data bss

Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin

On Tue, Jan 24, 2017 at 05:47:06PM +0100, Gregory CLEMENT wrote: > Hi David, > > On ven., janv. 20 2017, David Miller wrote: > > > From: Gregory CLEMENT > > Date: Thu, 19 Jan 2017 22:49:32 +0100 > > > >> I created a new family for this

Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin

On Tue, Jan 24, 2017 at 05:47:06PM +0100, Gregory CLEMENT wrote: > Hi David, > > On ven., janv. 20 2017, David Miller wrote: > > > From: Gregory CLEMENT > > Date: Thu, 19 Jan 2017 22:49:32 +0100 > > > >> I created a new family for this switch and filled the ops structure > >> by selecting

Re: [PATCH] net: ks8851: Drop eeprom_size structure member

From: Stephen Boyd Date: Mon, 23 Jan 2017 17:49:20 -0800 > After commit 51b7b1c34e19 (KSZ8851-SNL: Add ethtool support for > EEPROM via eeprom_93cx6, 2011-11-21) this structure member is > unused. Delete it. > > Signed-off-by: Stephen Boyd

Re: [PATCH] net: ks8851: Drop eeprom_size structure member

From: Stephen Boyd Date: Mon, 23 Jan 2017 17:49:20 -0800 > After commit 51b7b1c34e19 (KSZ8851-SNL: Add ethtool support for > EEPROM via eeprom_93cx6, 2011-11-21) this structure member is > unused. Delete it. > > Signed-off-by: Stephen Boyd Applied to net-next, thanks.

[RFC PATCH v1 1/6] kernel-doc: pure python kernel-doc parser (preparation)

This is the first patch of a series which merges a pure python implementation of the kernel-doc parser. It adds the prerequisites which are needed by the pure python implementation (which comes later in the series). The fspath module in this patch is a reduced implementation of pypi's fspath [1].

[RFC PATCH v1 1/6] kernel-doc: pure python kernel-doc parser (preparation)

This is the first patch of a series which merges a pure python implementation of the kernel-doc parser. It adds the prerequisites which are needed by the pure python implementation (which comes later in the series). The fspath module in this patch is a reduced implementation of pypi's fspath [1].

Re: [GIT PULL] Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window

On Tue, Jan 24, 2017 at 12:12 AM, Lee Jones wrote: > On Mon, 23 Jan 2017, Olof Johansson wrote: >> On Mon, Jan 23, 2017 at 4:12 AM, Lee Jones wrote: >> > Arm, IIO and PWM Maintainers, >> > >> > Enjoy! >> > >> > The following changes since commit >> >

Re: [GIT PULL] Immutable branch between MFD, ARM, IIO and PWM due for the v4.10 merge window

On Tue, Jan 24, 2017 at 12:12 AM, Lee Jones wrote: > On Mon, 23 Jan 2017, Olof Johansson wrote: >> On Mon, Jan 23, 2017 at 4:12 AM, Lee Jones wrote: >> > Arm, IIO and PWM Maintainers, >> > >> > Enjoy! >> > >> > The following changes since commit >> > 7ce7d89f48834cefece7804d38fc5d85382edf77: >>

[RFC PATCH v1 4/6] kernel-doc: insert TODOs on kernel-doc errors

The rstKernelDoc.py sphinx-extensions inserts '.. todo::' on errors. With this patch sphinx.ext.todo extension [1] is activated. This is similar to what we know from DocBook's *Oops* functionality of the kernel-doc perl script [2]. I added this functionality (only) to the subproject, to left the

[RFC PATCH v1 4/6] kernel-doc: insert TODOs on kernel-doc errors

The rstKernelDoc.py sphinx-extensions inserts '.. todo::' on errors. With this patch sphinx.ext.todo extension [1] is activated. This is similar to what we know from DocBook's *Oops* functionality of the kernel-doc perl script [2]. I added this functionality (only) to the subproject, to left the

[RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

this patch adds a command to lint kernel-doc comments.:: scripts/kerneldoc-lint --help The lint check include (only) kernel-doc rules described at [1]. It does not check against reST (sphinx-doc) markup used in the kernel-doc comments. Since reST markups could include depencies to the build-

[RFC PATCH v1 0/6] pure python kernel-doc parser and more

Hi Jon, here is my RFC, replacing the kernel-doc parser perl script with a python implementation. The parser is implemented as module and is used by several kernel-doc applications: * kerneldoc : the parser * kerneldoc-lint: liniting * kerneldoc-src2rst : autodoc source tree *

[RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

this patch adds a command to lint kernel-doc comments.:: scripts/kerneldoc-lint --help The lint check include (only) kernel-doc rules described at [1]. It does not check against reST (sphinx-doc) markup used in the kernel-doc comments. Since reST markups could include depencies to the build-

[RFC PATCH v1 0/6] pure python kernel-doc parser and more

Hi Jon, here is my RFC, replacing the kernel-doc parser perl script with a python implementation. The parser is implemented as module and is used by several kernel-doc applications: * kerneldoc : the parser * kerneldoc-lint: liniting * kerneldoc-src2rst : autodoc source tree *

[RFC PATCH v1 6/6] kernel-doc: add man page builder (target mandocs)

This patch brings man page build we already know from the DocBook toolchain. It adds a sphinx extension 'manKernelDoc' which consists of: * '.. kernel-doc-man::' : directive implemented in class KernelDocMan * 'kernel_doc_man' : *invisible* node * 'kernel-doc-man' : an alternative man

[RFC PATCH v1 6/6] kernel-doc: add man page builder (target mandocs)

This patch brings man page build we already know from the DocBook toolchain. It adds a sphinx extension 'manKernelDoc' which consists of: * '.. kernel-doc-man::' : directive implemented in class KernelDocMan * 'kernel_doc_man' : *invisible* node * 'kernel-doc-man' : an alternative man

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote: > rapl_cpu_prepare() must be called after logical package id of CPU > is set by topology_update_package_map(). > > But when onlining hot-added CPU, rapl_cpu_prepare() is called before > setting logical package id of the hot-added CPU. So

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote: > rapl_cpu_prepare() must be called after logical package id of CPU > is set by topology_update_package_map(). > > But when onlining hot-added CPU, rapl_cpu_prepare() is called before > setting logical package id of the hot-added CPU. So

[PATCH] drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance

Per the ABI specification[1], each mdev_supported_types entry should have an available_instances, with an "s", not available_instance. [1] Documentation/ABI/testing/sysfs-bus-vfio-mdev Signed-off-by: Alex Williamson --- This should really be fixed before initial

[PATCH] drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance

Per the ABI specification[1], each mdev_supported_types entry should have an available_instances, with an "s", not available_instance. [1] Documentation/ABI/testing/sysfs-bus-vfio-mdev Signed-off-by: Alex Williamson --- This should really be fixed before initial release in v4.10

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

On Tue, Jan 24, 2017 at 02:42:27PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Mon, 23 Jan 2017 21:37:52 +0200 > > > I don't have any guests with PAGE_SIZE > 64k but the > > code seems to be clearly broken in that case > > as PAGE_SIZE /

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

On Tue, Jan 24, 2017 at 02:42:27PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Mon, 23 Jan 2017 21:37:52 +0200 > > > I don't have any guests with PAGE_SIZE > 64k but the > > code seems to be clearly broken in that case > > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > >

[RFC PATCH v1 5/6] kernel-doc: add kerneldoc-src2rst command

this patch adds a command to auto-generate documentation from kernel's source tree.:: scripts/kerneldoc-src2rst --help E.g. to autodoc the kernel's ./include folder use:: scripts/kerneldoc-src2rst ./include /tmp/test123 >From the resulting reST-doctree you can build HTML rendered output

[RFC PATCH v1 5/6] kernel-doc: add kerneldoc-src2rst command

this patch adds a command to auto-generate documentation from kernel's source tree.:: scripts/kerneldoc-src2rst --help E.g. to autodoc the kernel's ./include folder use:: scripts/kerneldoc-src2rst ./include /tmp/test123 >From the resulting reST-doctree you can build HTML rendered output

Re: [PATCH v4] IB/umem: Release pid in error and ODP flow

On Thu, 2017-01-05 at 08:39 +0200, Leon Romanovsky wrote: > On Thu, Jan 05, 2017 at 03:00:05PM +0800, Kenneth Lee wrote: > > > > 1. Release pid before enter odp flow > > 2. Release pid when fail to allocate memory > > > > Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm- > >

Re: [PATCH v4] IB/umem: Release pid in error and ODP flow

On Thu, 2017-01-05 at 08:39 +0200, Leon Romanovsky wrote: > On Thu, Jan 05, 2017 at 03:00:05PM +0800, Kenneth Lee wrote: > > > > 1. Release pid before enter odp flow > > 2. Release pid when fail to allocate memory > > > > Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm- > >

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

From: "Michael S. Tsirkin" Date: Mon, 23 Jan 2017 21:37:52 +0200 > I don't have any guests with PAGE_SIZE > 64k but the > code seems to be clearly broken in that case > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > more than 8 bit and so the code in

Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

From: "Michael S. Tsirkin" Date: Mon, 23 Jan 2017 21:37:52 +0200 > I don't have any guests with PAGE_SIZE > 64k but the > code seems to be clearly broken in that case > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > more than 8 bit and so the code in mergeable_ctx_to_buf_address > does not

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On Sat, Jan 14, 2017 at 1:15 AM, Florian Fainelli wrote: > On 01/13/2017 08:38 AM, Andy Shevchenko wrote: >> On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli >> wrote: >>> This patch adds support for the IMS (now Zodiac Inflight Innovations) >>> SCU

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On Sat, Jan 14, 2017 at 1:15 AM, Florian Fainelli wrote: > On 01/13/2017 08:38 AM, Andy Shevchenko wrote: >> On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli >> wrote: >>> This patch adds support for the IMS (now Zodiac Inflight Innovations) >>> SCU Generation 1/2/3 platform driver. This

[GIT PULL] platform-drivers-x86 for 4.10-4

Hi Linus, This is my first pull request since I become a co-maintainer of Platform Drivers x86 subsystem. It's a bit bigger than usual due to material collected for almost 2 weeks in a row. Thanks, With Best Regards, Andy Shevchenko The following changes since commit

[GIT PULL] platform-drivers-x86 for 4.10-4

Hi Linus, This is my first pull request since I become a co-maintainer of Platform Drivers x86 subsystem. It's a bit bigger than usual due to material collected for almost 2 weeks in a row. Thanks, With Best Regards, Andy Shevchenko The following changes since commit

[PATCH] mfd: constify regmap_irq_chip structures

Declare regmap_irq_chip structures as const as they are only stored in the regmap_irq_chip field of a rk808 structure. This field is of type const, so regmap_irq_chip structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x;

[PATCH] mfd: constify regmap_irq_chip structures

Declare regmap_irq_chip structures as const as they are only stored in the regmap_irq_chip field of a rk808 structure. This field is of type const, so regmap_irq_chip structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier x;

[PATCH] nvdimm: constify device_type structures

Declare device_type structure as const as it is only stored in the type field of a device structure. This field is of type const, so add const to declaration of device_type structure. File size before: text data bss dec hex filename 192783199 16 2249357dd

[PATCH] nvdimm: constify device_type structures

Declare device_type structure as const as it is only stored in the type field of a device structure. This field is of type const, so add const to declaration of device_type structure. File size before: text data bss dec hex filename 192783199 16 2249357dd

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 04:28:29PM +0200, Andy Shevchenko wrote: > They probably release just almost all One Big Ugly patch from official > BSP, which by some reason, includes all Intel MID SoCs, Baytrail. > I think I know how Dollar Cove related code ended up there. But that > all stuff is a

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 04:28:29PM +0200, Andy Shevchenko wrote: > They probably release just almost all One Big Ugly patch from official > BSP, which by some reason, includes all Intel MID SoCs, Baytrail. > I think I know how Dollar Cove related code ended up there. But that > all stuff is a

[PATCH] usb: musb: constify musb_hdrc_config structures

Declare musb_hdrc_config structures as const as they are only stored in the config field of a musb_hdrc_platform_data structure. This field is of type const, so musb_hdrc_config structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier

[PATCH] usb: musb: constify musb_hdrc_config structures

Declare musb_hdrc_config structures as const as they are only stored in the config field of a musb_hdrc_platform_data structure. This field is of type const, so musb_hdrc_config structures having this property can be made const too. Done using Coccinelle: @r disable optional_qualifier@ identifier

Re: [PATCH 0/6 v3] kvmalloc

On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote: > On Thu 12-01-17 16:37:11, Michal Hocko wrote: > > Hi, > > this has been previously posted as a single patch [1] but later on more > > built on top. It turned out that there are users who would like to have > > __GFP_REPEAT semantic.

Re: [PATCH 0/6 v3] kvmalloc

On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote: > On Thu 12-01-17 16:37:11, Michal Hocko wrote: > > Hi, > > this has been previously posted as a single patch [1] but later on more > > built on top. It turned out that there are users who would like to have > > __GFP_REPEAT semantic.

Re: [PATCH 1/2] perf probe: Fix wrong register name for arm64

Em Tue, Jan 24, 2017 at 10:30:14AM +, He Kuang escreveu: > The register name of arm64 architecture is x0-x31 not r0-r31, this > patch changes this typo. > > Before this patch: Will, are you ok with this one? I'll make sure I'll forward patches in this area to you if you're not on the CC

Re: [PATCH 1/2] perf probe: Fix wrong register name for arm64

Em Tue, Jan 24, 2017 at 10:30:14AM +, He Kuang escreveu: > The register name of arm64 architecture is x0-x31 not r0-r31, this > patch changes this typo. > > Before this patch: Will, are you ok with this one? I'll make sure I'll forward patches in this area to you if you're not on the CC

Re: [PATCH] phy: marvell: remove conflicting initializer

From: Arnd Bergmann Date: Mon, 23 Jan 2017 13:18:41 +0100 > One line was apparently pasted incorrectly during a new feature patch: > > drivers/net/phy/marvell.c:2090:15: error: initialized field overwritten > [-Werror=override-init] >.features = PHY_GBIT_FEATURES, > > I'm

Re: [PATCH] phy: marvell: remove conflicting initializer

From: Arnd Bergmann Date: Mon, 23 Jan 2017 13:18:41 +0100 > One line was apparently pasted incorrectly during a new feature patch: > > drivers/net/phy/marvell.c:2090:15: error: initialized field overwritten > [-Werror=override-init] >.features = PHY_GBIT_FEATURES, > > I'm removing the

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu: > On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote: > > Since HAVE_KPROBES can be enabled in arm64, this patch introduces > > regs_query_register_offset() to convert register name to offset for > > arm64, so the BPF prologue

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu: > On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote: > > Since HAVE_KPROBES can be enabled in arm64, this patch introduces > > regs_query_register_offset() to convert register name to offset for > > arm64, so the BPF prologue

Re: [PATCH 4.4 00/42] 4.4.45-stable review

On Tue, Jan 24, 2017 at 08:55:10AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.45 release. > There are 42 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

Re: [PATCH 4.4 00/42] 4.4.45-stable review

On Tue, Jan 24, 2017 at 08:55:10AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.45 release. > There are 42 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

Re: [PATCH 4.9 000/130] 4.9.6-stable review

On Tue, Jan 24, 2017 at 08:54:00AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.6 release. > There are 130 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

Re: [PATCH 4.9 000/130] 4.9.6-stable review

On Tue, Jan 24, 2017 at 08:54:00AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.6 release. > There are 130 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

Re: [PATCH RFC] tpm: define a command filter

On Tue, Jan 24, 2017 at 04:36:00PM +0200, Jarkko Sakkinen wrote: > On Mon, Jan 23, 2017 at 05:19:18PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 24, 2017 at 02:02:52AM +0200, Jarkko Sakkinen wrote: > > > This commit adds a command filter for whitelisting a set of commands in > > > a TPM space.

Re: [PATCH RFC] tpm: define a command filter

On Tue, Jan 24, 2017 at 04:36:00PM +0200, Jarkko Sakkinen wrote: > On Mon, Jan 23, 2017 at 05:19:18PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 24, 2017 at 02:02:52AM +0200, Jarkko Sakkinen wrote: > > > This commit adds a command filter for whitelisting a set of commands in > > > a TPM space.

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

On 01/19/2017 10:12 AM, Florian Fainelli wrote: > > Back to the actual code that triggered this discussion, the whole > purpose is just a safeguard. Given a device reference, we can assume > that it is indeed the backing device for a net_device, and we could do a > to_net_device() right away (and

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

On 01/19/2017 10:12 AM, Florian Fainelli wrote: > > Back to the actual code that triggered this discussion, the whole > purpose is just a safeguard. Given a device reference, we can assume > that it is indeed the backing device for a net_device, and we could do a > to_net_device() right away (and

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