[PATCH] ipmi: set si_trydefaults=0 for ARM64

Port I/O space does not exist in ARM64 and is not mapped. Attempts to access it on ARM systems cause stack traces and worse. Signed-off-by: Tony Camuso --- drivers/char/ipmi/ipmi_si_intf.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH] ipmi: set si_trydefaults=0 for ARM64

Port I/O space does not exist in ARM64 and is not mapped. Attempts to access it on ARM systems cause stack traces and worse. Signed-off-by: Tony Camuso --- drivers/char/ipmi/ipmi_si_intf.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/char/ipmi/ipmi_si_intf.c

[PATCH v3 09/15] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399

On rk3399 we'd like to be able to properly set corecfg registers in the Arasan SDHCI component. Specify the syscon to enable that. Signed-off-by: Douglas Anderson Tested-by: Heiko Stuebner --- Changes in v3: - Add collected tags Changes in v2: None

[PATCH v3 09/15] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399

On rk3399 we'd like to be able to properly set corecfg registers in the Arasan SDHCI component. Specify the syscon to enable that. Signed-off-by: Douglas Anderson Tested-by: Heiko Stuebner --- Changes in v3: - Add collected tags Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi |

Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

Hello Brian, On 06/20/2016 02:10 PM, Brian Norris wrote: > Hi, > > On Mon, Jun 20, 2016 at 10:44:55AM -0700, Brian Norris wrote: >> On Mon, Jun 20, 2016 at 09:46:57AM -0400, Javier Martinez Canillas wrote: >>> On 06/18/2016 01:09 PM, Guenter Roeck wrote: On 06/17/2016 06:08 PM, Brian Norris

Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

Hello Brian, On 06/20/2016 02:10 PM, Brian Norris wrote: > Hi, > > On Mon, Jun 20, 2016 at 10:44:55AM -0700, Brian Norris wrote: >> On Mon, Jun 20, 2016 at 09:46:57AM -0400, Javier Martinez Canillas wrote: >>> On 06/18/2016 01:09 PM, Guenter Roeck wrote: On 06/17/2016 06:08 PM, Brian Norris

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > A recent change accidentally introduced a 64-bit division in torture_shutdown, > which fails to build on 32-bit architectures: > > kernel/built-in.o: In function `torture_shutdown': > :(.text+0x4b29a): undefined reference to

Re: [PATCH 0/5] Input: alps - cleanup

On Monday 06 June 2016 13:32:31 Hans de Goede wrote: > Hi, > > On 06-06-16 13:23, Pali Rohár wrote: > > This patch series cleanup usage of alps_model_data table. > > > > Pali Rohár (5): > > Input: alps - move ALPS_PROTO_V6 out of alps_model_data table > > Input: alps - move ALPS_PROTO_V4 out

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > A recent change accidentally introduced a 64-bit division in torture_shutdown, > which fails to build on 32-bit architectures: > > kernel/built-in.o: In function `torture_shutdown': > :(.text+0x4b29a): undefined reference to

Re: [PATCH 0/5] Input: alps - cleanup

On Monday 06 June 2016 13:32:31 Hans de Goede wrote: > Hi, > > On 06-06-16 13:23, Pali Rohár wrote: > > This patch series cleanup usage of alps_model_data table. > > > > Pali Rohár (5): > > Input: alps - move ALPS_PROTO_V6 out of alps_model_data table > > Input: alps - move ALPS_PROTO_V4 out

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 13 2016 at 6:57pm -0400, Mike Snitzer wrote: > On Mon, Jun 13 2016 at 6:21pm -0400, > Toshi Kani wrote: > > > This patch-set adds DAX support to device-mapper dm-linear devices > > used by LVM. It works with LVM commands as follows: > > -

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 13 2016 at 6:57pm -0400, Mike Snitzer wrote: > On Mon, Jun 13 2016 at 6:21pm -0400, > Toshi Kani wrote: > > > This patch-set adds DAX support to device-mapper dm-linear devices > > used by LVM. It works with LVM commands as follows: > > - Creation of a logical volume with all

Re: [PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399

Am Montag, 20. Juni 2016, 10:56:39 schrieb Douglas Anderson: > The theme of this series of patches is to try to allow running the eMMC > at 150 MHz on the rk3399 SoC, though the changes should still be correct > and have merit on their own. The motivation for running at 150 MHz is > that doing so

Re: [PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399

Am Montag, 20. Juni 2016, 10:56:39 schrieb Douglas Anderson: > The theme of this series of patches is to try to allow running the eMMC > at 150 MHz on the rk3399 SoC, though the changes should still be correct > and have merit on their own. The motivation for running at 150 MHz is > that doing so

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: 'perf cc' seems sensible, and has the added bonus of being one letter shorter :-) perf is now a general front-end to a compiler?

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: 'perf cc' seems sensible, and has the added bonus of being one letter shorter :-) perf is now a general front-end to a compiler?

Re: [PATCH v3 14/15] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

Am Montag, 20. Juni 2016, 10:56:53 schrieb Douglas Anderson: > The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the > frequency range of DLL operation". Although the Rockchip variant of > this PHY has different ranges than the reference Arasan PHY it appears > as if the

Re: [PATCH v3 14/15] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

Am Montag, 20. Juni 2016, 10:56:53 schrieb Douglas Anderson: > The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the > frequency range of DLL operation". Although the Rockchip variant of > this PHY has different ranges than the reference Arasan PHY it appears > as if the

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Mon, Jun 20, 2016 at 09:22:11AM -0700, Alexei Starovoitov escreveu: > On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: > > Doing: > > perf bcc -c foo.c > > Looks so much simpler and similar to an existing compile source code > > into object file workflow (gcc's,

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Mon, Jun 20, 2016 at 09:22:11AM -0700, Alexei Starovoitov escreveu: > On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: > > Doing: > > perf bcc -c foo.c > > Looks so much simpler and similar to an existing compile source code > > into object file workflow (gcc's,

Re: [PATCH v2 1/3] Documentation: DT: Add iproc-static-adc binding

On Sun, Jun 19, 2016 at 03:36:28PM +0530, Raveendra Padasalagi wrote: > The patch adds devicetree binding document for broadcom's > iproc-static-adc controller driver. > > Signed-off-by: Raveendra Padasalagi > Reviewed-by: Ray Jui >

Re: [PATCH v2 1/3] Documentation: DT: Add iproc-static-adc binding

On Sun, Jun 19, 2016 at 03:36:28PM +0530, Raveendra Padasalagi wrote: > The patch adds devicetree binding document for broadcom's > iproc-static-adc controller driver. > > Signed-off-by: Raveendra Padasalagi > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden > --- >

[PATCH v3 14/15] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the frequency range of DLL operation". Although the Rockchip variant of this PHY has different ranges than the reference Arasan PHY it appears as if the functionality is similar. We should set this phyctrl field properly. Note:

Re: Stable -rc git trees and email headers

Greg KH writes: > Hi, > > I've finally gotten off my butt and made my quilt trees of patches into > a "semi-proper" git tree to make it easier for people to test them. > > I'm now pushing the patches I accept into the stable queues into the git > tree here: >

[PATCH v3 14/15] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the frequency range of DLL operation". Although the Rockchip variant of this PHY has different ranges than the reference Arasan PHY it appears as if the functionality is similar. We should set this phyctrl field properly. Note:

Re: Stable -rc git trees and email headers

Greg KH writes: > Hi, > > I've finally gotten off my butt and made my quilt trees of patches into > a "semi-proper" git tree to make it easier for people to test them. > > I'm now pushing the patches I accept into the stable queues into the git > tree here: >

[PATCH v3 08/15] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399.

[PATCH v3 08/15] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399.

[PATCH v3 12/15] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

As of an earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add ability to export card clock") the SDHCI driver used on Rockchip SoCs can now expose its clock. Let's now specify that the PHY can use it. Letting the PHY get access to this clock means it can adjust phyctrl_frqsel

[PATCH v3 15/15] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399

Previous changes in this series allowed exposing the card clock from the rk3399 SDHCI device and allowed consuming the card clock in the rk3399 eMMC PHY. Hook things up in the main rk3399 dtsi file. Signed-off-by: Douglas Anderson Tested-by: Heiko Stuebner

[PATCH v3 12/15] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

As of an earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add ability to export card clock") the SDHCI driver used on Rockchip SoCs can now expose its clock. Let's now specify that the PHY can use it. Letting the PHY get access to this clock means it can adjust phyctrl_frqsel

[PATCH v3 15/15] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399

Previous changes in this series allowed exposing the card clock from the rk3399 SDHCI device and allowed consuming the card clock in the rk3399 eMMC PHY. Hook things up in the main rk3399 dtsi file. Signed-off-by: Douglas Anderson Tested-by: Heiko Stuebner --- Changes in v3: - Add collected

[PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399

The theme of this series of patches is to try to allow running the eMMC at 150 MHz on the rk3399 SoC, though the changes should still be correct and have merit on their own. The motivation for running at 150 MHz is that doing so improves signal integrity and (with some eMMC devices) doesn't

[PATCH v3 11/15] mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the

[PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399

The theme of this series of patches is to try to allow running the eMMC at 150 MHz on the rk3399 SoC, though the changes should still be correct and have merit on their own. The motivation for running at 150 MHz is that doing so improves signal integrity and (with some eMMC devices) doesn't

[PATCH v3 11/15] mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the

Re: [PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

On Mon, Jun 20, 2016 at 09:52:00AM +0100, Lee Jones wrote: > > > > > +static struct trip_config_map str3_trip_config[] = { > > > > > + { > > > > > + .irq_reg = BXTWC_THRM2IRQ, > > > > > + .irq_mask = 0x10, > > > > > + .irq_en = BXTWC_MTHRM2IRQ, > > > > > +

[PATCH v3 06/15] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for

[PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

Previous PHY code waited a fixed amount of time for the DLL to lock at power on time. Unfortunately, the time for the DLL to lock is actually a bit more dynamic and can be longer if the card clock is slower. Instead of waiting a fixed 30 us, let's now dynamically wait until the lock bit gets

Re: [PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

On Mon, Jun 20, 2016 at 09:52:00AM +0100, Lee Jones wrote: > > > > > +static struct trip_config_map str3_trip_config[] = { > > > > > + { > > > > > + .irq_reg = BXTWC_THRM2IRQ, > > > > > + .irq_mask = 0x10, > > > > > + .irq_en = BXTWC_MTHRM2IRQ, > > > > > +

[PATCH v3 06/15] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for

[PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

Previous PHY code waited a fixed amount of time for the DLL to lock at power on time. Unfortunately, the time for the DLL to lock is actually a bit more dynamic and can be longer if the card clock is slower. Instead of waiting a fixed 30 us, let's now dynamically wait until the lock bit gets

[PATCH v3 03/15] phy: rockchip-emmc: configure default output tap delay

From: Brian Norris The output tap delay controls helps maintain the hold requirements for eMMC. The exact value is dependent on the SoC and other factors, though it isn't really an exact science. But the default of 0 is not very good, as it doesn't give the eMMC much

[PATCH v3 03/15] phy: rockchip-emmc: configure default output tap delay

From: Brian Norris The output tap delay controls helps maintain the hold requirements for eMMC. The exact value is dependent on the SoC and other factors, though it isn't really an exact science. But the default of 0 is not very good, as it doesn't give the eMMC much hold time, so let's bump up

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

On 20/06/16 18:56, Kevin Hilman wrote: Sudeep Holla writes: This series add support for SCPI based device device power state management using genpd. Regards, Sudeep v1[1]->v2: - Fixed the endianness handling in scpi_device_get_power_state as spotted

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

On 20/06/16 18:56, Kevin Hilman wrote: Sudeep Holla writes: This series add support for SCPI based device device power state management using genpd. Regards, Sudeep v1[1]->v2: - Fixed the endianness handling in scpi_device_get_power_state as spotted by Tixy -

the usage of __SYSCALL_MASK in entry_SYSCALL_64/do_syscall_64 is not consistent

On 06/19, Andy Lutomirski wrote: > > Something's clearly buggy there, The usage of __X32_SYSCALL_BIT doesn't look right too. Nothing serious but still. Damn, initially I thought I have found the serious bug in entry_64.S and it took me some time to understand why my exploit doesn't work ;) So I

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

the usage of __SYSCALL_MASK in entry_SYSCALL_64/do_syscall_64 is not consistent

On 06/19, Andy Lutomirski wrote: > > Something's clearly buggy there, The usage of __X32_SYSCALL_BIT doesn't look right too. Nothing serious but still. Damn, initially I thought I have found the serious bug in entry_64.S and it took me some time to understand why my exploit doesn't work ;) So I

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we actually change over the inode

[PATCH] perf: add 'perf bench syscall'

On Wed, Feb 03, 2016 at 11:22:47AM +0100, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > > > On Jan 31, 2016 11:42 PM, "Ingo Molnar" wrote: > > > > > > > > > * r...@redhat.com wrote: > > > > > > > (v3: address comments raised by

[PATCH] perf: add 'perf bench syscall'

On Wed, Feb 03, 2016 at 11:22:47AM +0100, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > > > On Jan 31, 2016 11:42 PM, "Ingo Molnar" wrote: > > > > > > > > > * r...@redhat.com wrote: > > > > > > > (v3: address comments raised by Frederic) > > > > > > > > Running with nohz_full introduces a

[PATCH v3] gpio: add Intel WhiskeyCove GPIO driver

This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC. This driver is based on gpio-crystalcove.c. Signed-off-by: Ajay Thomas Signed-off-by: Bin Gao --- Changes in v3: - Fixed the year in copyright

[PATCH v3] gpio: add Intel WhiskeyCove GPIO driver

This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC. This driver is based on gpio-crystalcove.c. Signed-off-by: Ajay Thomas Signed-off-by: Bin Gao --- Changes in v3: - Fixed the year in copyright line(2015-->2016). - Removed DRV_NAME macro. - Added kernel-doc for

Re: [PATCH V3] clocksource/drivers/bcm_kona: Convert init function to return error

Hi Daniel, On 6/20/2016 10:48 AM, Daniel Lezcano wrote: The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller

Re: [PATCH V3] clocksource/drivers/bcm_kona: Convert init function to return error

Hi Daniel, On 6/20/2016 10:48 AM, Daniel Lezcano wrote: The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/20/16 08:43, Greg KH wrote: > On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: >> On 06/08/2016 03:43 AM, Greg KH wrote: >>> I'm announcing the release of the 4.4.13 kernel. >>> >> >> Hi, >> >> I tried to compile 4.4.13 using my 4.4.7 config file and ran in to this: >> >> LD

[PATCH v4 net-next v4 04/14] net: dsa: mv88e6xxx: do not increment bus refcount

The MDIO device probe and remove functions are respectively incrementing and decrementing the bus refcount themselves. Since these bus level actions are out of the device scope, remove them. Signed-off-by: Vivien Didelot Acked-by: Andrew Lunn

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/20/16 08:43, Greg KH wrote: > On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: >> On 06/08/2016 03:43 AM, Greg KH wrote: >>> I'm announcing the release of the 4.4.13 kernel. >>> >> >> Hi, >> >> I tried to compile 4.4.13 using my 4.4.7 config file and ran in to this: >> >> LD

[PATCH v4 net-next v4 04/14] net: dsa: mv88e6xxx: do not increment bus refcount

The MDIO device probe and remove functions are respectively incrementing and decrementing the bus refcount themselves. Since these bus level actions are out of the device scope, remove them. Signed-off-by: Vivien Didelot Acked-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 3 --- 1 file

[PATCH v4 net-next v4 05/14] net: dsa: mv88e6xxx: add switch register helpers

The mixed assignments, allocations and registrations in the probe code make it hard to follow the logic and figure out what is DSA or chip specific. Extract the struct dsa_switch related code in a simple mv88e6xxx_register_switch helper function. For symmetry in the code, add a

[PATCH v4 net-next v4 05/14] net: dsa: mv88e6xxx: add switch register helpers

The mixed assignments, allocations and registrations in the probe code make it hard to follow the logic and figure out what is DSA or chip specific. Extract the struct dsa_switch related code in a simple mv88e6xxx_register_switch helper function. For symmetry in the code, add a

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

"Jon Medhurst (Tixy)" writes: > On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: >> >> On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: >> > On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: >> > [...] >> >> +enum scpi_power_domain_state { >> >> + SCPI_PD_STATE_ON = 0,

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

"Jon Medhurst (Tixy)" writes: > On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: >> >> On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: >> > On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: >> > [...] >> >> +enum scpi_power_domain_state { >> >> + SCPI_PD_STATE_ON = 0, >> >> +

[PATCH v4 net-next v4 03/14] net: dsa: mv88e6xxx: use already declared variables

In the MDIO probing function, dev is already assigned to >dev and np is already assigned to mdiodev->dev.of_node, so use them. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 6 +++--- 1 file changed,

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi Andrew, David, Andrew Lunn writes: > On Mon, Jun 20, 2016 at 12:03:37PM -0400, Vivien Didelot wrote: >> When the SMI address of the switch chip is zero, the chip assumes to be >> the only one on the SMI master bus and thus responds to all its known >> SMI devices addresses

[PATCH v4 net-next v4 07/14] net: dsa: mv88e6xxx: remove table args in info lookup

The mv88e6xxx_table array and the mv88e6xxx_lookup_info function are static, so remove the table and size arguments from the lookup function. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 16

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 20/06/16 18:50, Kevin Hilman wrote: "Jon Medhurst (Tixy)" writes: On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] +enum scpi_power_domain_state { +

[PATCH v4 net-next v4 01/14] net: dsa: mv88e6xxx: fix style issues

This patch fixes 5 style problems reported by checkpatch: WARNING: suspect code indent for conditional statements (8, 24) #492: FILE: drivers/net/dsa/mv88e6xxx.c:492: + if (phydev->link) + reg |= PORT_PCS_CTRL_LINK_UP; CHECK: Logical continuations should

[PATCH v4 net-next v4 03/14] net: dsa: mv88e6xxx: use already declared variables

In the MDIO probing function, dev is already assigned to >dev and np is already assigned to mdiodev->dev.of_node, so use them. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi Andrew, David, Andrew Lunn writes: > On Mon, Jun 20, 2016 at 12:03:37PM -0400, Vivien Didelot wrote: >> When the SMI address of the switch chip is zero, the chip assumes to be >> the only one on the SMI master bus and thus responds to all its known >> SMI devices addresses (port registers,

[PATCH v4 net-next v4 07/14] net: dsa: mv88e6xxx: remove table args in info lookup

The mv88e6xxx_table array and the mv88e6xxx_lookup_info function are static, so remove the table and size arguments from the lookup function. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 16 ++-- 1 file changed, 6 insertions(+), 10

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 20/06/16 18:50, Kevin Hilman wrote: "Jon Medhurst (Tixy)" writes: On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] +enum scpi_power_domain_state { + SCPI_PD_STATE_ON

[PATCH v4 net-next v4 01/14] net: dsa: mv88e6xxx: fix style issues

This patch fixes 5 style problems reported by checkpatch: WARNING: suspect code indent for conditional statements (8, 24) #492: FILE: drivers/net/dsa/mv88e6xxx.c:492: + if (phydev->link) + reg |= PORT_PCS_CTRL_LINK_UP; CHECK: Logical continuations should

[PATCH V3] clocksource/drivers/bcm_kona: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V3] clocksource/drivers/bcm_kona: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

Re: [PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

Hi Lee, On Mon, Jun 20, 2016 at 09:00:51AM +0100, Lee Jones wrote: > On Fri, 17 Jun 2016, Doug Anderson wrote: > > On Fri, Jun 17, 2016 at 1:06 AM, Lee Jones wrote: > > >> Probably the reason for all of these non-kernel-isms is that this > > >> isn't a kernel file. From

Re: [PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

Hi Lee, On Mon, Jun 20, 2016 at 09:00:51AM +0100, Lee Jones wrote: > On Fri, 17 Jun 2016, Doug Anderson wrote: > > On Fri, Jun 17, 2016 at 1:06 AM, Lee Jones wrote: > > >> Probably the reason for all of these non-kernel-isms is that this > > >> isn't a kernel file. From the top of the file: > >

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

Sudeep Holla writes: > This series add support for SCPI based device device power state > management using genpd. > > Regards, > Sudeep > > v1[1]->v2: > - Fixed the endianness handling in scpi_device_get_power_state > as spotted by Tixy > - Renamed

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

Sudeep Holla writes: > This series add support for SCPI based device device power state > management using genpd. > > Regards, > Sudeep > > v1[1]->v2: > - Fixed the endianness handling in scpi_device_get_power_state > as spotted by Tixy > - Renamed scpi_pd.c to

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

On 20 June 2016 at 18:20, Pali Rohár wrote: > > On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote: > > On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote: > > > I do not understand it... Why Canonical is hidden and don't communicate > > > with rest of world?

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

On 20 June 2016 at 18:20, Pali Rohár wrote: > > On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote: > > On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r wrote: > > > I do not understand it... Why Canonical is hidden and don't communicate > > > with rest of world? Otherwise touchpads

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

On Monday 20 June 2016 19:37:57 Dmitry Torokhov wrote: > On Tue, Jun 21, 2016 at 01:29:41AM +0800, Anthony Wong wrote: > > On 20 June 2016 at 18:20, Pali Rohár wrote: > > > On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote: > > > > On Sun, Jun 19, 2016 at 01:43:46AM

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

On Monday 20 June 2016 19:37:57 Dmitry Torokhov wrote: > On Tue, Jun 21, 2016 at 01:29:41AM +0800, Anthony Wong wrote: > > On 20 June 2016 at 18:20, Pali Rohár wrote: > > > On Monday 20 June 2016 03:16:36 Christoph Hellwig wrote: > > > > On Sun, Jun 19, 2016 at 01:43:46AM +0200, Pali Roh??r

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > Could either of you comment on the below patch? > > All atomic functions that return a value should imply full memory > barrier semantics -- this very much includes a compiler barrier / memory > clobber. I wonder if it is possible to find a case

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > Could either of you comment on the below patch? > > All atomic functions that return a value should imply full memory > barrier semantics -- this very much includes a compiler barrier / memory > clobber. I wonder if it is possible to find a case where this makes a real

Re: [PATCH v2 2/9] kexec_file: Generalize kexec_add_buffer.

Am Montag, 20 Juni 2016, 10:26:05 schrieb Dave Young: > kexec_buf should go within #ifdef for kexec file like struct > purgatory_info > > Other than that it looks good. Great! Here it is. -- []'s Thiago Jung Bauermann IBM Linux Technology Center kexec_file: Generalize kexec_add_buffer.

Re: [PATCH v2 2/9] kexec_file: Generalize kexec_add_buffer.

Am Montag, 20 Juni 2016, 10:26:05 schrieb Dave Young: > kexec_buf should go within #ifdef for kexec file like struct > purgatory_info > > Other than that it looks good. Great! Here it is. -- []'s Thiago Jung Bauermann IBM Linux Technology Center kexec_file: Generalize kexec_add_buffer.

Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

Hi, On Mon, Jun 20, 2016 at 09:46:57AM -0400, Javier Martinez Canillas wrote: > On 06/18/2016 01:09 PM, Guenter Roeck wrote: > > On 06/17/2016 06:08 PM, Brian Norris wrote: > >> On Fri, Jun 17, 2016 at 02:41:51PM -0700, Guenter Roeck wrote: > >>> On Fri, Jun 17, 2016 at 12:58:12PM -0700, Brian

Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

Hi, On Mon, Jun 20, 2016 at 09:46:57AM -0400, Javier Martinez Canillas wrote: > On 06/18/2016 01:09 PM, Guenter Roeck wrote: > > On 06/17/2016 06:08 PM, Brian Norris wrote: > >> On Fri, Jun 17, 2016 at 02:41:51PM -0700, Guenter Roeck wrote: > >>> On Fri, Jun 17, 2016 at 12:58:12PM -0700, Brian

Re: [RFC 00/18] Present useful limits to user

On 2016-06-18 10:45, Konstantin Khlebnikov wrote: On Wed, Jun 15, 2016 at 5:47 PM, Austin S. Hemmelgarn wrote: On 2016-06-14 15:03, Konstantin Khlebnikov wrote: I don't like the idea of this patchset. All limitations are context dependent and that context changes

Re: [RFC 00/18] Present useful limits to user

On 2016-06-18 10:45, Konstantin Khlebnikov wrote: On Wed, Jun 15, 2016 at 5:47 PM, Austin S. Hemmelgarn wrote: On 2016-06-14 15:03, Konstantin Khlebnikov wrote: I don't like the idea of this patchset. All limitations are context dependent and that context changes rapidly. You'll never dump

Re: [PATCH] Input: elan_i2c - +200 ms delay before setting to ABS mode

On Tue, Jun 07, 2016 at 09:34:09PM +0800, Chris Chiu wrote: > When performing a warm reboot from a system which does not correctly > support ELAN I2C touchpads, the touchpad will sometimes enter standard > mouse mode, cursor then never respond to touchpad event, and making the > driver discard the

Re: [PATCH] Input: elan_i2c - +200 ms delay before setting to ABS mode

On Tue, Jun 07, 2016 at 09:34:09PM +0800, Chris Chiu wrote: > When performing a warm reboot from a system which does not correctly > support ELAN I2C touchpads, the touchpad will sometimes enter standard > mouse mode, cursor then never respond to touchpad event, and making the > driver discard the

Re: [PATCH] devfreq_cooling: pass a pointer to devfreq in the power model callbacks

Eduardo, Rui, On Fri, Jun 03, 2016 at 10:25:31AM +0100, Javi Merino wrote: > When the devfreq cooling device was designed, it was an oversight not to > pass a pointer to the struct devfreq as the first parameters of the > callbacks. The design patterns of the kernel suggest it for a good >

Re: [PATCH] devfreq_cooling: pass a pointer to devfreq in the power model callbacks

Eduardo, Rui, On Fri, Jun 03, 2016 at 10:25:31AM +0100, Javi Merino wrote: > When the devfreq cooling device was designed, it was an oversight not to > pass a pointer to the struct devfreq as the first parameters of the > callbacks. The design patterns of the kernel suggest it for a good >

Re: [PATCH v2 1/2] remoteproc: qcom: Driver for the self-authenticating Hexagon v5

On Mon 20 Jun 07:48 PDT 2016, Srinivas Kandagatla wrote: > Thanks Bjorn for this patch, > > I will start playing with patch soon, but here are few comments. > > On 17/06/16 18:17, Bjorn Andersson wrote: > >From: Bjorn Andersson > > > >This initial hack powers

Re: [PATCH v2 1/2] remoteproc: qcom: Driver for the self-authenticating Hexagon v5

On Mon 20 Jun 07:48 PDT 2016, Srinivas Kandagatla wrote: > Thanks Bjorn for this patch, > > I will start playing with patch soon, but here are few comments. > > On 17/06/16 18:17, Bjorn Andersson wrote: > >From: Bjorn Andersson > > > >This initial hack powers the q6v5, boots and authenticate

Re: [PATCH] clk: renesas: build clk-rcar-gen2.o for R8A7792

Hello. On 06/20/2016 06:43 PM, Arnd Bergmann wrote: The newly added support for R8A7792 causes build failures because we try to call rcar_gen2_clocks_init but that is not built into the kernel: arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init': :(.init.text+0x3b0):

Re: [PATCH] clk: renesas: build clk-rcar-gen2.o for R8A7792

Hello. On 06/20/2016 06:43 PM, Arnd Bergmann wrote: The newly added support for R8A7792 causes build failures because we try to call rcar_gen2_clocks_init but that is not built into the kernel: arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init': :(.init.text+0x3b0):

<    5   6   7   8   9   10   11   12   13   14   >