Re: [PATCH] rtc: opal: Implement rtc_class_ops.alarm_irq_enable callback

On 31/05/2017 at 18:39:01 +0530, Vaibhav Jain wrote: > Provide an implementation of the callback > rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is > called when the wake alarm is disabled via the command: > > 'echo 0 > /sys/class/rtc/rtc0/wakealarm' > > Without this the

Re: [PATCH] rtc: opal: Implement rtc_class_ops.alarm_irq_enable callback

On 31/05/2017 at 18:39:01 +0530, Vaibhav Jain wrote: > Provide an implementation of the callback > rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is > called when the wake alarm is disabled via the command: > > 'echo 0 > /sys/class/rtc/rtc0/wakealarm' > > Without this the

Linux 4.9.34

I'm announcing the release of the 4.9.34 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Re: Linux 4.9.34

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a6fadef92d6d..86a6746f6833 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3932,6 +3932,13 @@ bytes respectively. Such letter suffixes can also be entirely

Linux 4.9.34

I'm announcing the release of the 4.9.34 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Re: Linux 4.9.34

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a6fadef92d6d..86a6746f6833 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3932,6 +3932,13 @@ bytes respectively. Such letter suffixes can also be entirely

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"

From: Len Brown cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz that is otherwise reported in x86 /proc/cpuinfo "cpu MHz". There are four problems with this scheme, any of them is sufficient justification to delete it. 1. Depending on which cpufreq driver

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"

From: Len Brown cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz that is otherwise reported in x86 /proc/cpuinfo "cpu MHz". There are four problems with this scheme, any of them is sufficient justification to delete it. 1. Depending on which cpufreq driver is loaded, the

[PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode

From: Len Brown The cpufreq/scaling_cur_freq sysfs attribute is now provided by shared x86 cpufreq code on modern x86 systems, including all systems supported by the intel_pstate driver. In HWP mode, maintaining that value was the sole purpose of the scheduler hook,

Linux 4.11.7

I'm announcing the release of the 4.11.7 kernel. All users of the 4.11 kernel series must upgrade. The updated 4.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.11.y and can be browsed at the normal kernel.org git web browser:

[PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode

From: Len Brown The cpufreq/scaling_cur_freq sysfs attribute is now provided by shared x86 cpufreq code on modern x86 systems, including all systems supported by the intel_pstate driver. In HWP mode, maintaining that value was the sole purpose of the scheduler hook,

Linux 4.11.7

I'm announcing the release of the 4.11.7 kernel. All users of the 4.11 kernel series must upgrade. The updated 4.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.11.y and can be browsed at the normal kernel.org git web browser:

[PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode.

From: Len Brown When the governor is set to "performance", intel_pstate does not need the scheduler hook for doing any calculations. Under these conditions, its only purpose is to continue to maintain cpufreq/scaling_cur_freq. The cpufreq/scaling_cur_freq sysfs attribute

Re: Linux 4.11.7

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index facc20a3f962..952319b73e61 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3779,6 +3779,13 @@

[PATCH 0/4 v2] x86,cpufreq: unify APERF/MPERF computation

Hi Rafael, Thomas, Please see the updated 2nd patch in this series -- in response to tglx review. Patch 1,3,4 are unchanged. thanks, -Len This patch series has 3 goals: 1. Make "cpu MHz" in /proc/cpuinfo supportable. 2. Make /sys/.../cpufreq/scaling_cur_freq meaningful and consistent on

[PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode.

From: Len Brown When the governor is set to "performance", intel_pstate does not need the scheduler hook for doing any calculations. Under these conditions, its only purpose is to continue to maintain cpufreq/scaling_cur_freq. The cpufreq/scaling_cur_freq sysfs attribute is now provided by

Re: Linux 4.11.7

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index facc20a3f962..952319b73e61 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3779,6 +3779,13 @@

[PATCH 0/4 v2] x86,cpufreq: unify APERF/MPERF computation

Hi Rafael, Thomas, Please see the updated 2nd patch in this series -- in response to tglx review. Patch 1,3,4 are unchanged. thanks, -Len This patch series has 3 goals: 1. Make "cpu MHz" in /proc/cpuinfo supportable. 2. Make /sys/.../cpufreq/scaling_cur_freq meaningful and consistent on

[PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

From: Len Brown The goal of this change is to give users a uniform and meaningful result when they read /sys/...cpufreq/scaling_cur_freq on modern x86 hardware, as compared to what they get today. Modern x86 processors include the hardware needed to accurately calculate

[PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

From: Len Brown The goal of this change is to give users a uniform and meaningful result when they read /sys/...cpufreq/scaling_cur_freq on modern x86 hardware, as compared to what they get today. Modern x86 processors include the hardware needed to accurately calculate frequency over an

Re: [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Tue, Jun 20, 2017 at 6:15 AM, Thomas Gleixner wrote: > On Fri, 16 Jun 2017, Len Brown wrote: >> +#include >> +#include >> +#include >> +#include >> + >> +struct aperfmperf_sample { >> + unsigned int khz; >> + unsigned long jiffies; >> + u64 aperf; >> +

Re: [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Tue, Jun 20, 2017 at 6:15 AM, Thomas Gleixner wrote: > On Fri, 16 Jun 2017, Len Brown wrote: >> +#include >> +#include >> +#include >> +#include >> + >> +struct aperfmperf_sample { >> + unsigned int khz; >> + unsigned long jiffies; >> + u64 aperf; >> + u64 mperf; > > Nit.

Re: Stable/distro kernel testing in Plumbers 2017

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > We were hoping to discuss the state of -stable/distro kernel testing > in the Testing & Fuzzing MC in Plumbers 2017. > > Mainly we want to understand what sort of testing is being done, how > bug

Re: Stable/distro kernel testing in Plumbers 2017

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > We were hoping to discuss the state of -stable/distro kernel testing > in the Testing & Fuzzing MC in Plumbers 2017. > > Mainly we want to understand what sort of testing is being done, how > bug

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote: > So taking the position that any kselftest script on linux-next or a future > kernel should never break stable implicate that *any* fix going upstream for > which there is a respective ksefltest test *must* have a stable upstream

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote: > So taking the position that any kselftest script on linux-next or a future > kernel should never break stable implicate that *any* fix going upstream for > which there is a respective ksefltest test *must* have a stable upstream

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote: > Greg, for context, the issue here is that we made what was arguably a > design error in seccomp's interaction with ptrace. After determining > that fixing it solved a bunch of problems and didn't break any user > programs, we

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote: > Greg, for context, the issue here is that we made what was arguably a > design error in seccomp's interaction with ptrace. After determining > that fixing it solved a bunch of problems and didn't break any user > programs, we

Re: [HMM 09/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v5

On 05/24/2017 10:20 AM, Jérôme Glisse wrote: [...] +/* + * hmm_devmem_fault_range() - migrate back a virtual range of memory + * + * @devmem: hmm_devmem struct use to track and manage the ZONE_DEVICE memory + * @vma: virtual memory area containing the range to be migrated + * @ops: migration

Re: [HMM 09/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v5

On 05/24/2017 10:20 AM, Jérôme Glisse wrote: [...] +/* + * hmm_devmem_fault_range() - migrate back a virtual range of memory + * + * @devmem: hmm_devmem struct use to track and manage the ZONE_DEVICE memory + * @vma: virtual memory area containing the range to be migrated + * @ops: migration

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

Hi, Andrew On 2017/6/24 11:12, Andrew Lunn wrote: >> +int phy_loopback(struct phy_device *phydev, bool enable) >> +{ >> +struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); >> +int ret = 0; >> + >> +if (enable && phydev->loopback_enabled) >> +return -EBUSY;

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

Hi, Andrew On 2017/6/24 11:12, Andrew Lunn wrote: >> +int phy_loopback(struct phy_device *phydev, bool enable) >> +{ >> +struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); >> +int ret = 0; >> + >> +if (enable && phydev->loopback_enabled) >> +return -EBUSY;

[PATCH v5] trace: ras: add ARM processor error information trace event

Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which defined in UEFI 2.6 spec section N.2.4.4.1.

[PATCH v5] trace: ras: add ARM processor error information trace event

Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which defined in UEFI 2.6 spec section N.2.4.4.1.

Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

Hi Gilad, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170623] [cannot apply to v4.12-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gilad-Ben

Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

Hi Gilad, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170623] [cannot apply to v4.12-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gilad-Ben

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

On Sat, Jun 24, 2017 at 8:11 AM, srishti sharma wrote: > On Fri, Jun 23, 2017 at 9:50 PM, Greg KH wrote: >> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote: >>> Fixed alignment so that it matched open parenthesis. >>> >>>

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

On Sat, Jun 24, 2017 at 8:11 AM, srishti sharma wrote: > On Fri, Jun 23, 2017 at 9:50 PM, Greg KH wrote: >> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote: >>> Fixed alignment so that it matched open parenthesis. >>> >>> Signed-off-by: srishti sharma >>> --- >>>

[PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

Fixed alignment so that it matched open parenthesis. Signed-off-by: srishti sharma --- Changes in v2: -Fix all checks of the type "alignment should match open parenthesis" for a file in the same patch. .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 18

[PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

Fixed alignment so that it matched open parenthesis. Signed-off-by: srishti sharma --- Changes in v2: -Fix all checks of the type "alignment should match open parenthesis" for a file in the same patch. .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 18 +- 1 file

Re: [PATCH NET v3 2/2] net: hns: Use phy_driver to setup Phy loopback

> static int hns_nic_config_phy_loopback(struct phy_device *phy_dev, u8 en) > { > -#define COPPER_CONTROL_REG 0 > -#define PHY_POWER_DOWN BIT(11) > -#define PHY_LOOP_BACK BIT(14) > - u16 val = 0; > + int err; > > if (phy_dev->is_c45) /* c45 branch adding for XGE PHY */ >

Re: [PATCH NET v3 2/2] net: hns: Use phy_driver to setup Phy loopback

> static int hns_nic_config_phy_loopback(struct phy_device *phy_dev, u8 en) > { > -#define COPPER_CONTROL_REG 0 > -#define PHY_POWER_DOWN BIT(11) > -#define PHY_LOOP_BACK BIT(14) > - u16 val = 0; > + int err; > > if (phy_dev->is_c45) /* c45 branch adding for XGE PHY */ >

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

> +int phy_loopback(struct phy_device *phydev, bool enable) > +{ > + struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); > + int ret = 0; > + > + if (enable && phydev->loopback_enabled) > + return -EBUSY; > + > + if (!enable && !phydev->loopback_enabled)

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

> +int phy_loopback(struct phy_device *phydev, bool enable) > +{ > + struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); > + int ret = 0; > + > + if (enable && phydev->loopback_enabled) > + return -EBUSY; > + > + if (!enable && !phydev->loopback_enabled)

[tip:irq/core 30/72] kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reor

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core head: 8d9d51b62e8558bbc11c6b978acad001f9ea7a42 commit: 087cdfb662ae50e3826e7cd2e54b6519d07b60f0 [30/72] genirq/debugfs: Add proper debugfs interface coccinelle warnings: (new ones prefixed by >>) >>

[tip:irq/core 30/72] kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reor

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core head: 8d9d51b62e8558bbc11c6b978acad001f9ea7a42 commit: 087cdfb662ae50e3826e7cd2e54b6519d07b60f0 [30/72] genirq/debugfs: Add proper debugfs interface coccinelle warnings: (new ones prefixed by >>) >>

Re: [PATCH 0/4] g_NCR5380: PDMA fixes and cleanup

On Fri, 23 Jun 2017, Ondrej Zary wrote: > On Friday 23 June 2017 13:01:53 Finn Thain wrote: > > On Fri, 23 Jun 2017, I wrote: > > > Does this patch help? It should be applied on top of this series of 4. > > > > Sorry, I sent the wrong diff. Please try this patch instead. > > Thanks, much better

Re: [PATCH 0/4] g_NCR5380: PDMA fixes and cleanup

On Fri, 23 Jun 2017, Ondrej Zary wrote: > On Friday 23 June 2017 13:01:53 Finn Thain wrote: > > On Fri, 23 Jun 2017, I wrote: > > > Does this patch help? It should be applied on top of this series of 4. > > > > Sorry, I sent the wrong diff. Please try this patch instead. > > Thanks, much better

[PATCH v3 3/3] ARM: dts: sunxi: Add R_LRADC support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Now the driver has been modified to support it. Add support for it. Signed-off-by: Ziping Chen --- arch/arm/boot/dts/sun8i-a83t.dtsi | 7 +++ 1 file

[PATCH v3 3/3] ARM: dts: sunxi: Add R_LRADC support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Now the driver has been modified to support it. Add support for it. Signed-off-by: Ziping Chen --- arch/arm/boot/dts/sun8i-a83t.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v3 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC, however, the A10 SoC's vref of lradc internally is divided by 2/3 and the A83T SoC's vref of lradc internally is divided by 3/4, thus add a hardware variant for it to be compatible

[PATCH v3 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC, however, the A10 SoC's vref of lradc internally is divided by 2/3 and the A83T SoC's vref of lradc internally is divided by 3/4, thus add a hardware variant for it to be compatible with various devices.

[PATCH v3 0/3] Allwinner A83T R_LRADC support

From: Ziping Chen Hi, This is the remaining parts of my A83T R_LRADC support series Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Add support for it. Changes for v3: - Fix some issuses raised by Maxime. - Added Rob's ACK. Changes for v2: -

[PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Add binding for it. Signed-off-by: Ziping Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt

[PATCH v3 0/3] Allwinner A83T R_LRADC support

From: Ziping Chen Hi, This is the remaining parts of my A83T R_LRADC support series Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Add support for it. Changes for v3: - Fix some issuses raised by Maxime. - Added Rob's ACK. Changes for v2: - Add an A83T specific

[PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

From: Ziping Chen Allwinner A83T SoC has a low res adc like the one in Allwinner A10 SoC. Add binding for it. Signed-off-by: Ziping Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

On Fri, Jun 23, 2017 at 9:50 PM, Greg KH wrote: > On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote: >> Fixed alignment so that it matched open parenthesis. >> >> Signed-off-by: srishti sharma >> --- >>

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

On Fri, Jun 23, 2017 at 9:50 PM, Greg KH wrote: > On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote: >> Fixed alignment so that it matched open parenthesis. >> >> Signed-off-by: srishti sharma >> --- >> .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 18 >>

Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

On Fri, Jun 23, 2017 at 12:59:07PM +0800, David Wu wrote: > To make internal phy worked, need to configure the phy_clock, > phy cru_reset and related registers. > > Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13 > Signed-off-by: David Wu > --- >

Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

On Fri, Jun 23, 2017 at 12:59:07PM +0800, David Wu wrote: > To make internal phy worked, need to configure the phy_clock, > phy cru_reset and related registers. > > Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13 > Signed-off-by: David Wu > --- >

Re: [PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

On Fri, Jun 23, 2017 at 12:42:02PM +0800, David Wu wrote: > This is wrong setting for rk3328_set_to_rmii(), so remove it. > > Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd Hi David This is not a reconsigned tag for a patch. Andrew

Re: [PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

On Fri, Jun 23, 2017 at 12:42:02PM +0800, David Wu wrote: > This is wrong setting for rk3328_set_to_rmii(), so remove it. > > Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd Hi David This is not a reconsigned tag for a patch. Andrew

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

On Fri, Jun 23, 2017 at 12:41:59PM +0800, David Wu wrote: > Support internal ephy currently. > > Signed-off-by: David Wu > --- > drivers/net/phy/Kconfig| 4 ++ > drivers/net/phy/Makefile | 1 + > drivers/net/phy/rockchip.c | 94 >

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

On Fri, Jun 23, 2017 at 12:41:59PM +0800, David Wu wrote: > Support internal ephy currently. > > Signed-off-by: David Wu > --- > drivers/net/phy/Kconfig| 4 ++ > drivers/net/phy/Makefile | 1 + > drivers/net/phy/rockchip.c | 94 > ++ > 3

[PATCH] net/icmp: restore source address if packet is NATed

The ICMP routines use the source address for two reasons: 1. Rate-limiting ICMP transmissions based on source address, so that one source address cannot provoke a flood of replies. If the source address is wrong, the rate limiting will be incorrectly applied. 2.

[PATCH] net/icmp: restore source address if packet is NATed

The ICMP routines use the source address for two reasons: 1. Rate-limiting ICMP transmissions based on source address, so that one source address cannot provoke a flood of replies. If the source address is wrong, the rate limiting will be incorrectly applied. 2.

[PATCH] alpha: support R_ALPHA_REFLONG relocations for module loading

Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs as 32 bit quantities) R_ALPHA_REFLONG relocations can be required to load modules. This implements it. Tested-by: Bob Tracy Signed-off-by: Michael Cree --- arch/alpha/kernel/module.c | 3

[PATCH] alpha: support R_ALPHA_REFLONG relocations for module loading

Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs as 32 bit quantities) R_ALPHA_REFLONG relocations can be required to load modules. This implements it. Tested-by: Bob Tracy Signed-off-by: Michael Cree --- arch/alpha/kernel/module.c | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [PATCH v2 2/3] dt-bindings: input: Add DT bindings documentation for Allwinner A83T R_LRADC

Hi 2017-06-24 5:51 GMT+08:00 Rob Herring : > On Tue, Jun 20, 2017 at 09:44:44PM +0800, Ziping Chen wrote: >> From: Ziping Chen > > Your subject could be more concise. "DT bindings documentation" is > redundant. > >> >> Allwinner A83T SoC has a low res

Re: [PATCH v2 2/3] dt-bindings: input: Add DT bindings documentation for Allwinner A83T R_LRADC

Hi 2017-06-24 5:51 GMT+08:00 Rob Herring : > On Tue, Jun 20, 2017 at 09:44:44PM +0800, Ziping Chen wrote: >> From: Ziping Chen > > Your subject could be more concise. "DT bindings documentation" is > redundant. > >> >> Allwinner A83T SoC has a low res adc like the one >> in Allwinner A10 SoC. >>

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

> + > +static int internal_config_init(struct phy_device *phydev) > +{ internal_ is a bit generic. The Marvell Ethernet switches have internal phy, etc. rockchip_ would be a better prefix. Andrew

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

> + > +static int internal_config_init(struct phy_device *phydev) > +{ internal_ is a bit generic. The Marvell Ethernet switches have internal phy, etc. rockchip_ would be a better prefix. Andrew

pci: Add generic pcibios_{fixup_bus,align_resource}

While upstreaming the RISC-V port, it was pointed out that multiple architectures have copied the mostly empty versions of at least one of these functions. This defines weakly bound versions of the common functions and removes the now obselete functions from other ports. This has been split out

pci: Add generic pcibios_{fixup_bus,align_resource}

While upstreaming the RISC-V port, it was pointed out that multiple architectures have copied the mostly empty versions of at least one of these functions. This defines weakly bound versions of the common functions and removes the now obselete functions from other ports. This has been split out

[PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

Multiple architectures define this as an empty function, and I'm adding another one as part of the RISC-V port. This adds a __weak version of pci_fixup_bios and deletes the now obselete ones in a handful of ports. The only functional change should be that microblaze used to export

[PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

Multiple architectures define this as an empty function, and I'm adding another one as part of the RISC-V port. This adds a __weak version of pci_fixup_bios and deletes the now obselete ones in a handful of ports. The only functional change should be that microblaze used to export

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Wed, 07 Jun 2017 01:01:57 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:19 AM, Geert Uytterhoeven > wrote: >> CC pci folks >> >> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: >>> While upstreaming the RISC-V port, it was

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Thu, 08 Jun 2017 01:35:29 PDT (-0700), Arnd Bergmann wrote: > On Thu, Jun 8, 2017 at 10:12 AM, Christoph Hellwig wrote: >> On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote: >>> CC pci folks >> >> Ok, replying with pci folks in Cc then :) >> >> Weak symbols

[PATCH 3/3] arc: kernel/pcibios.c is empty, delete it

Signed-off-by: Palmer Dabbelt --- arch/arc/kernel/Makefile | 1 - arch/arc/kernel/pcibios.c | 9 - 2 files changed, 10 deletions(-) delete mode 100644 arch/arc/kernel/pcibios.c diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile index

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Thu, 08 Jun 2017 01:35:29 PDT (-0700), Arnd Bergmann wrote: > On Thu, Jun 8, 2017 at 10:12 AM, Christoph Hellwig wrote: >> On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote: >>> CC pci folks >> >> Ok, replying with pci folks in Cc then :) >> >> Weak symbols have (rightly)

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Wed, 07 Jun 2017 01:01:57 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:19 AM, Geert Uytterhoeven > wrote: >> CC pci folks >> >> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: >>> While upstreaming the RISC-V port, it was pointed out that multiple >>> architectures

[PATCH 3/3] arc: kernel/pcibios.c is empty, delete it

Signed-off-by: Palmer Dabbelt --- arch/arc/kernel/Makefile | 1 - arch/arc/kernel/pcibios.c | 9 - 2 files changed, 10 deletions(-) delete mode 100644 arch/arc/kernel/pcibios.c diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile index 8942c5c3b4c5..2dc5f4296d44 100644 ---

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 01:12:00 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt wrote: >> This patch adds the include files for the RISC-V port. These are mostly >> based on the score port, but there are a lot of arm64-based files as >> well.

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

On Wed, 07 Jun 2017 02:43:09 PDT (-0700), marc.zyng...@arm.com wrote: > On 06/06/17 23:59, Palmer Dabbelt wrote: >> The RISC-V ISA defines a single RTC as well as an SBI oneshot timer. >> This timer is present on all RISC-V systems. >> >> Signed-off-by: Palmer Dabbelt >> ---

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 01:12:00 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt wrote: >> This patch adds the include files for the RISC-V port. These are mostly >> based on the score port, but there are a lot of arm64-based files as >> well. >> >> Signed-off-by:

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

On Wed, 07 Jun 2017 02:43:09 PDT (-0700), marc.zyng...@arm.com wrote: > On 06/06/17 23:59, Palmer Dabbelt wrote: >> The RISC-V ISA defines a single RTC as well as an SBI oneshot timer. >> This timer is present on all RISC-V systems. >> >> Signed-off-by: Palmer Dabbelt >> --- >>

[PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

Multiple architectures define this as trivial function, and I'm adding another one as part of the RISC-V port. This adds a __weak version of pcibios_align_resource and deletes the now obselete ones in a handful of ports. The only functional change should be that a handful of ports used to export

[PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

Multiple architectures define this as trivial function, and I'm adding another one as part of the RISC-V port. This adds a __weak version of pcibios_align_resource and deletes the now obselete ones in a handful of ports. The only functional change should be that a handful of ports used to export

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

Hi Steve, Thanks for your comments. On 2017/6/23 21:42, Steven Rostedt wrote: > On Fri, 23 Jun 2017 19:13:43 +0800 > Xie XiuQi wrote: > >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

Hi Steve, Thanks for your comments. On 2017/6/23 21:42, Steven Rostedt wrote: > On Fri, 23 Jun 2017 19:13:43 +0800 > Xie XiuQi wrote: > >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information the >> user may take

[PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

Fix to call of_node_put() right after of_drm_find_bridge() instead of holding on to it until exynos_dsi_remove(). Suggested-by: Inki Dae Signed-off-by: Shuah Khan --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 + 1 file changed, 1

[PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

Fix to call of_node_put() right after of_drm_find_bridge() instead of holding on to it until exynos_dsi_remove(). Suggested-by: Inki Dae Signed-off-by: Shuah Khan --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

Re: [PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

On Friday, June 23, 2017 03:37:36 PM mario.limoncie...@dell.com wrote: > > -Original Message- [cut] > > Index: linux-pm/drivers/acpi/sleep.c > > === > > --- linux-pm.orig/drivers/acpi/sleep.c > > +++

Re: [PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

On Friday, June 23, 2017 03:37:36 PM mario.limoncie...@dell.com wrote: > > -Original Message- [cut] > > Index: linux-pm/drivers/acpi/sleep.c > > === > > --- linux-pm.orig/drivers/acpi/sleep.c > > +++

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote: > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote: > > > > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch > > series and I'm happy we have finally landed on it. Yes, indeed the

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote: > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote: > > > > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch > > series and I'm happy we have finally landed on it. Yes, indeed the new API > >

Re: [PATCH v2 12/29] kselftest.rst: do some adjustments after ReST conversion

On 06/23/2017 03:32 PM, Mauro Carvalho Chehab wrote: > Em Fri, 23 Jun 2017 08:04:02 -0600 > Shuah Khan escreveu: > >> Hi Mauro, >> >> On 06/17/2017 09:26 AM, Mauro Carvalho Chehab wrote: >>> Do some minor adjustments after ReST conversion: >>> >>> - On most documents, we use

Re: [PATCH v2 12/29] kselftest.rst: do some adjustments after ReST conversion

On 06/23/2017 03:32 PM, Mauro Carvalho Chehab wrote: > Em Fri, 23 Jun 2017 08:04:02 -0600 > Shuah Khan escreveu: > >> Hi Mauro, >> >> On 06/17/2017 09:26 AM, Mauro Carvalho Chehab wrote: >>> Do some minor adjustments after ReST conversion: >>> >>> - On most documents, we use prepend a "$ "

Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver

On Wed, 07 Jun 2017 00:55:28 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:13 AM, Geert Uytterhoeven > wrote: >>> +struct plic_enable_context { >>> + atomic_t mask[32]; // 32-bit * 32-entry >>> +}; > > You use many '//' style comments in this file,

Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver

On Wed, 07 Jun 2017 00:55:28 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:13 AM, Geert Uytterhoeven > wrote: >>> +struct plic_enable_context { >>> + atomic_t mask[32]; // 32-bit * 32-entry >>> +}; > > You use many '//' style comments in this file, please change them all to

  1   2   3   4   5   6   7   8   9   10   >