Re: [PATCH] net: ethernet: Fix SGMII unable to switch speed and autonego failure

From: ho.jia@intel.com Date: Mon, 14 Nov 2016 17:06:49 +0800 > From: Jia Jie Ho > > TSE PCS SGMII ethernet has an issue where switching speed doesn't work > caused by a faulty register macro offset. This fixes the issue. > > Signed-off-by: Jia Jie Ho

RE: [PATCH 2/2] perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs.

> This fixes SBOX support for Broadwell CPUs by checking the Power Control > Unit CAPID4 register to determine the number of available SBOXes on the > particular CPU before trying to enable them. > > This patch has been tested on E5-2620 v4 (no SBOXes) and E5-2697 v4 (4 > SBOXes). > >

Re: [PATCH] net: ethernet: Fix SGMII unable to switch speed and autonego failure

From: ho.jia@intel.com Date: Mon, 14 Nov 2016 17:06:49 +0800 > From: Jia Jie Ho > > TSE PCS SGMII ethernet has an issue where switching speed doesn't work > caused by a faulty register macro offset. This fixes the issue. > > Signed-off-by: Jia Jie Ho Applied.

RE: [PATCH 2/2] perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs.

> This fixes SBOX support for Broadwell CPUs by checking the Power Control > Unit CAPID4 register to determine the number of available SBOXes on the > particular CPU before trying to enable them. > > This patch has been tested on E5-2620 v4 (no SBOXes) and E5-2697 v4 (4 > SBOXes). > >

Re: [PATCH v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver

Hi Rob, Thanks for the comments! On 11/14/2016 07:04 PM, Rob Herring wrote: > On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote: >> Add binding document for Venus video encoder/decoder driver >> >> Cc: Rob Herring >> Cc: Mark Rutland >>

Re: [PATCH v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver

Hi Rob, Thanks for the comments! On 11/14/2016 07:04 PM, Rob Herring wrote: > On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote: >> Add binding document for Venus video encoder/decoder driver >> >> Cc: Rob Herring >> Cc: Mark Rutland >> Cc: devicet...@vger.kernel.org >>

Re: [PATCH] reset: Add Tegra BPMP reset driver

Hi Thierry, Am Dienstag, den 15.11.2016, 17:17 +0100 schrieb Thierry Reding: > From: Thierry Reding > > This driver uses the services provided by the BPMP firmware driver to > implement a reset driver based on the MRQ_RESET request. > > Signed-off-by: Thierry Reding

Re: [PATCH] reset: Add Tegra BPMP reset driver

Hi Thierry, Am Dienstag, den 15.11.2016, 17:17 +0100 schrieb Thierry Reding: > From: Thierry Reding > > This driver uses the services provided by the BPMP firmware driver to > implement a reset driver based on the MRQ_RESET request. > > Signed-off-by: Thierry Reding > --- > Hi Philipp, > >

Re: [PATCH] drm/bridge: analogix_dp: return error if transfer none byte

On Thu, Nov 3, 2016 at 3:17 AM, Jianqun Xu wrote: > Reference from drm_dp_aux description (about transfer): > Upon success, the implementation should return the number of payload bytes > that were transferred, or a negative error-code on failure. Helpers > propagate errors

Re: [PATCH] drm/bridge: analogix_dp: return error if transfer none byte

On Thu, Nov 3, 2016 at 3:17 AM, Jianqun Xu wrote: > Reference from drm_dp_aux description (about transfer): > Upon success, the implementation should return the number of payload bytes > that were transferred, or a negative error-code on failure. Helpers > propagate errors from the .transfer()

RE: [PATCH] cpufreq: intel_pstate: Generic governors support

On 2016.11.13 16:08 Rafael J. Wysocki wrote: > Rebased on top of my linux-next branch, which in turn is based on 4.9-rc5 now. > > I'm running this on my IVB laptop w/ the schedutil governor, no problems so > far (fingers crossed). I did the exact same tests as I did with your earlier RFT/RFC

RE: [PATCH] cpufreq: intel_pstate: Generic governors support

On 2016.11.13 16:08 Rafael J. Wysocki wrote: > Rebased on top of my linux-next branch, which in turn is based on 4.9-rc5 now. > > I'm running this on my IVB laptop w/ the schedutil governor, no problems so > far (fingers crossed). I did the exact same tests as I did with your earlier RFT/RFC

Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Mon, Nov 14, 2016 at 7:43 PM, Marek Vasut wrote: > On 11/02/2016 08:38 AM, Ksenija Stanojevic wrote: >> Add core files for low resolution analog-to-digital converter (mxs-lradc) >> MFD driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >>

Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Mon, Nov 14, 2016 at 7:43 PM, Marek Vasut wrote: > On 11/02/2016 08:38 AM, Ksenija Stanojevic wrote: >> Add core files for low resolution analog-to-digital converter (mxs-lradc) >> MFD driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >> Changes in v9: >> - improve commit message. >> >>

RE: perf: fuzzer KASAN slab-out-of-bounds in snb_uncore_imc_event_del

> > On Tue, Nov 15, 2016 at 12:57:31AM -0500, Vince Weaver wrote: > > On Mon, 14 Nov 2016, Vince Weaver wrote: > > > > > Anyway as per the suggestion at Linux Plumbers I enabled KASAN and > > > on my haswell machine it falls over in a few minutes of running the > perf_fuzzer. > > > > > > [

RE: perf: fuzzer KASAN slab-out-of-bounds in snb_uncore_imc_event_del

> > On Tue, Nov 15, 2016 at 12:57:31AM -0500, Vince Weaver wrote: > > On Mon, 14 Nov 2016, Vince Weaver wrote: > > > > > Anyway as per the suggestion at Linux Plumbers I enabled KASAN and > > > on my haswell machine it falls over in a few minutes of running the > perf_fuzzer. > > > > > > [

Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options

On 11/15/2016 08:30 AM, Andrew Lunn wrote: > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote: >> On some platforms, energy efficient ethernet with rtl8211 devices is >> causing issue, like throughput drop or broken link. >> >> This was reported on the OdroidC2 (DWMAC + RTL8211F).

Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options

On 11/15/2016 08:30 AM, Andrew Lunn wrote: > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote: >> On some platforms, energy efficient ethernet with rtl8211 devices is >> causing issue, like throughput drop or broken link. >> >> This was reported on the OdroidC2 (DWMAC + RTL8211F).

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

On 11/15/2016 8:39 AM, Radim Krčmář wrote: > 2016-11-09 18:37-0600, Tom Lendacky: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

On 11/15/2016 8:39 AM, Radim Krčmář wrote: > 2016-11-09 18:37-0600, Tom Lendacky: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB

Re: [PATCH 0/2] sched/rt: disable RT_RUNTIME_SHARE by default and document it

On 11/15/2016 04:27 PM, Steven Rostedt wrote: > I don't see why this is two patches. A change and a comment can go > together, and probably should, especially since the comment explains > the change as well. > > With a folded patch... I will cook a v2 in a single patch! Thanks! -- Daniel

Re: [PATCH 0/2] sched/rt: disable RT_RUNTIME_SHARE by default and document it

On 11/15/2016 04:27 PM, Steven Rostedt wrote: > I don't see why this is two patches. A change and a comment can go > together, and probably should, especially since the comment explains > the change as well. > > With a folded patch... I will cook a v2 in a single patch! Thanks! -- Daniel

Re: [PATCH] icmp: Restore resistence to abnormal messages

From: Vicente Jiménez Date: Tue, 15 Nov 2016 17:49:43 +0100 > On Mon, Nov 14, 2016 at 7:36 PM, David Miller wrote: >> From: Vicente Jimenez Aguilar >> Date: Fri, 11 Nov 2016 21:20:18 +0100 >> >>> @@ -819,6 +820,12 @@ static bool

Re: [PATCH] icmp: Restore resistence to abnormal messages

From: Vicente Jiménez Date: Tue, 15 Nov 2016 17:49:43 +0100 > On Mon, Nov 14, 2016 at 7:36 PM, David Miller wrote: >> From: Vicente Jimenez Aguilar >> Date: Fri, 11 Nov 2016 21:20:18 +0100 >> >>> @@ -819,6 +820,12 @@ static bool icmp_unreach(struct sk_buff *skb) >>>

[PATCH 2/2] perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs.

This fixes SBOX support for Broadwell CPUs by checking the Power Control Unit CAPID4 register to determine the number of available SBOXes on the particular CPU before trying to enable them. This patch has been tested on E5-2620 v4 (no SBOXes) and E5-2697 v4 (4 SBOXes). Signed-off-by: Oskar Senft

[PATCH 1/2] Revert "perf/x86/intel/uncore: Remove SBOX support for Broadwell server"

This reverts commit 3b94a891667c ("perf/x86/intel/uncore: Remove SBOX support for Broadwell server"). Note that this commit will cause a GP fault during boot on Broadwell CPUs that do not have SBOXes. This is in preparation for a follow-up change which fixes the SBOX support for Broadwell CPUs.

[PATCH 2/2] perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs.

This fixes SBOX support for Broadwell CPUs by checking the Power Control Unit CAPID4 register to determine the number of available SBOXes on the particular CPU before trying to enable them. This patch has been tested on E5-2620 v4 (no SBOXes) and E5-2697 v4 (4 SBOXes). Signed-off-by: Oskar Senft

[PATCH 1/2] Revert "perf/x86/intel/uncore: Remove SBOX support for Broadwell server"

This reverts commit 3b94a891667c ("perf/x86/intel/uncore: Remove SBOX support for Broadwell server"). Note that this commit will cause a GP fault during boot on Broadwell CPUs that do not have SBOXes. This is in preparation for a follow-up change which fixes the SBOX support for Broadwell CPUs.

[PATCH 1/2] ovl: use kernel facility for copying attributes

Replace ovl_copyattr() by fsstack_copy_attr_all() and drop the definition of the former. Signed-off-by: Quorum Laval --- fs/overlayfs/dir.c | 3 ++- fs/overlayfs/inode.c | 3 ++- fs/overlayfs/overlayfs.h | 9 - fs/overlayfs/super.c | 7 --- 4

[PATCH 2/2] ovl: use kernel facility for updating access time

Use fsstack_copy_attr_atime() instead of direct assignement. Signed-off-by: Quorum Laval --- fs/overlayfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index 540caa6..083cbdb 100644 ---

[PATCH 1/2] ovl: use kernel facility for copying attributes

Replace ovl_copyattr() by fsstack_copy_attr_all() and drop the definition of the former. Signed-off-by: Quorum Laval --- fs/overlayfs/dir.c | 3 ++- fs/overlayfs/inode.c | 3 ++- fs/overlayfs/overlayfs.h | 9 - fs/overlayfs/super.c | 7 --- 4 files changed, 8

[PATCH 2/2] ovl: use kernel facility for updating access time

Use fsstack_copy_attr_atime() instead of direct assignement. Signed-off-by: Quorum Laval --- fs/overlayfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index 540caa6..083cbdb 100644 --- a/fs/overlayfs/inode.c +++

Re: [PATCH v2 2/3] cpuidle: allow setting deepest idle

On Mon, 14 Nov 2016 22:42:03 +0100 "Rafael J. Wysocki" wrote: > > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c > > index cb6442f..9e80f32 100644 > > --- a/kernel/sched/idle.c > > +++ b/kernel/sched/idle.c > > @@ -173,6 +173,9 @@ static void cpuidle_idle_call(void) >

Re: [PATCH v2 2/3] cpuidle: allow setting deepest idle

On Mon, 14 Nov 2016 22:42:03 +0100 "Rafael J. Wysocki" wrote: > > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c > > index cb6442f..9e80f32 100644 > > --- a/kernel/sched/idle.c > > +++ b/kernel/sched/idle.c > > @@ -173,6 +173,9 @@ static void cpuidle_idle_call(void) > > > >

Re: [PATCH] icmp: Restore resistence to abnormal messages

On Mon, Nov 14, 2016 at 7:36 PM, David Miller wrote: > From: Vicente Jimenez Aguilar > Date: Fri, 11 Nov 2016 21:20:18 +0100 > >> @@ -819,6 +820,12 @@ static bool icmp_unreach(struct sk_buff *skb) >> /* fall through */ >>

Re: [PATCH] icmp: Restore resistence to abnormal messages

On Mon, Nov 14, 2016 at 7:36 PM, David Miller wrote: > From: Vicente Jimenez Aguilar > Date: Fri, 11 Nov 2016 21:20:18 +0100 > >> @@ -819,6 +820,12 @@ static bool icmp_unreach(struct sk_buff *skb) >> /* fall through */ >> case 0: >>

Mr. Turritopsis Dohrnii Teo En Ming (Zhang Enming) is Looking for Information Technology-related Jobs World Wide

Dear Sir/Madam, My academic and educational qualifications are now reflected in my email signature. I am an entry level/junior/beginner Information Technology (IT) Specialist/Systems Engineer/Linux Server Administrator/Helpdesk Support/Computer Technician available for hire anywhere in the

Mr. Turritopsis Dohrnii Teo En Ming (Zhang Enming) is Looking for Information Technology-related Jobs World Wide

Dear Sir/Madam, My academic and educational qualifications are now reflected in my email signature. I am an entry level/junior/beginner Information Technology (IT) Specialist/Systems Engineer/Linux Server Administrator/Helpdesk Support/Computer Technician available for hire anywhere in the

Re: [PATCH] printk, locking/atomics, kref: Introduce new %pAr and %pAk format string options for atomic_t and 'struct kref'

On Tue, Nov 15, 2016 at 12:37 AM, Ingo Molnar wrote: > +atomic variables such atomic_t or struct kref: > + > + %pAratomic_t count > + %pAkstruct kref count Not a huge fan. That "r" makes sense to you ("raw" atomic), but it makes no sense to a user. An atomic

Re: [PATCH] printk, locking/atomics, kref: Introduce new %pAr and %pAk format string options for atomic_t and 'struct kref'

On Tue, Nov 15, 2016 at 12:37 AM, Ingo Molnar wrote: > +atomic variables such atomic_t or struct kref: > + > + %pAratomic_t count > + %pAkstruct kref count Not a huge fan. That "r" makes sense to you ("raw" atomic), but it makes no sense to a user. An atomic isn't "raw" to

Re: [PATCH 3/3] x86/intel_rdt: Update closid in PQR_ASSOC registers in synchronous mode when changing "cpus"

On Tue, 15 Nov 2016, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Fenghua Yu wrote: > > +/* > > + * MSR_IA32_PQR_ASSOC is scoped per logical CPU, so all updates > > + * are always in thread context. > > And this comment tells us what? Nothing useful. It lacks the most important > information

Re: [PATCH 3/3] x86/intel_rdt: Update closid in PQR_ASSOC registers in synchronous mode when changing "cpus"

On Tue, 15 Nov 2016, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Fenghua Yu wrote: > > +/* > > + * MSR_IA32_PQR_ASSOC is scoped per logical CPU, so all updates > > + * are always in thread context. > > And this comment tells us what? Nothing useful. It lacks the most important > information

Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state

On Tue, 15 Nov 2016 19:36:26 +0800 Zhang Rui wrote: > On Mon, 2016-11-14 at 11:12 -0800, Jacob Pan wrote: > > On Fri, 11 Nov 2016 18:34:10 +0100 > > Petr Mladek wrote: > > > > > > > > Please, let me known if I should do this as a separate patch > > >

Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state

On Tue, 15 Nov 2016 19:36:26 +0800 Zhang Rui wrote: > On Mon, 2016-11-14 at 11:12 -0800, Jacob Pan wrote: > > On Fri, 11 Nov 2016 18:34:10 +0100 > > Petr Mladek wrote: > > > > > > > > Please, let me known if I should do this as a separate patch > > > and/or resend the patchset. > >

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

On 11/11/16 14:19, Sudeep Holla wrote: On 11/11/16 13:34, Rob Herring wrote: On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla wrote: [...] True and I agree, how about "arm,scpi-pre-1.0" instead ? That's still meaningless. Convince me that multiple implementations

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

On 11/11/16 14:19, Sudeep Holla wrote: On 11/11/16 13:34, Rob Herring wrote: On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla wrote: [...] True and I agree, how about "arm,scpi-pre-1.0" instead ? That's still meaningless. Convince me that multiple implementations are identical, then we

Re: [PATCH] ACPI: allow compilation with bare metal compilers

On 11/15/2016 08:43 AM, Moore, Robert wrote: > The design for all of this is as follows: > > 1) OS-dependent includes > 2) Compiler-specific includes > 3) acenv.h is the master file that pulls in the correct headers (one > compiler, and one OS) Sure, that's understood from the current

Re: [PATCH] ACPI: allow compilation with bare metal compilers

On 11/15/2016 08:43 AM, Moore, Robert wrote: > The design for all of this is as follows: > > 1) OS-dependent includes > 2) Compiler-specific includes > 3) acenv.h is the master file that pulls in the correct headers (one > compiler, and one OS) Sure, that's understood from the current

Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME

On Tue, Nov 15, 2016 at 10:06:16AM -0600, Tom Lendacky wrote: > Yes, but that doesn't relate to the physical address space reduction. > > Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is > never used, there is a physical reduction of the address space. So when > checking

Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME

On Tue, Nov 15, 2016 at 10:06:16AM -0600, Tom Lendacky wrote: > Yes, but that doesn't relate to the physical address space reduction. > > Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is > never used, there is a physical reduction of the address space. So when > checking

[RFC v2 0/2] mmc: sdhci-pci: Use ACPI to set max frequency of sdio host controller

On some boards, max SDIO frequency is limited by trace lengths and other layout choices. We would like a way to specify this limitation so the driver can behave accordingly. This patch set assumes that the limitation has been reported in an ACPI table which the driver can check to get the max

[RFC v2 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On NI 9037 boards the max SDIO frequency is limited by trace lengths and other layout choices. The max SDIO frequency is stored in an ACPI table. The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the f_max field of the host. Signed-off-by: Nathan Sullivan

[RFC v2 1/2] mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller sub-vended by NI

Add PCI ID for Intel byt sdio host controller sub-vended by NI. The controller has different behavior because of the board layout NI puts it on. Signed-off-by: Zach Brown --- drivers/mmc/host/sdhci-pci-core.c | 24 1 file changed, 24 insertions(+)

[RFC v2 0/2] mmc: sdhci-pci: Use ACPI to set max frequency of sdio host controller

On some boards, max SDIO frequency is limited by trace lengths and other layout choices. We would like a way to specify this limitation so the driver can behave accordingly. This patch set assumes that the limitation has been reported in an ACPI table which the driver can check to get the max

[RFC v2 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On NI 9037 boards the max SDIO frequency is limited by trace lengths and other layout choices. The max SDIO frequency is stored in an ACPI table. The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the f_max field of the host. Signed-off-by: Nathan Sullivan Reviewed-by: Jaeden

[RFC v2 1/2] mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller sub-vended by NI

Add PCI ID for Intel byt sdio host controller sub-vended by NI. The controller has different behavior because of the board layout NI puts it on. Signed-off-by: Zach Brown --- drivers/mmc/host/sdhci-pci-core.c | 24 1 file changed, 24 insertions(+) diff --git

Re: [GIT PULL] fbdev fixes for 4.9

On Tue, Nov 15, 2016 at 3:40 AM, Tomi Valkeinen wrote: > > I did test compile, and I would have noticed errors but I missed the warnings > (I blame the flu...). I need to improve my testing methods, but I couldn't > find > a way to add -Werror to kernel builds. I guess I

Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options

On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote: > On some platforms, energy efficient ethernet with rtl8211 devices is > causing issue, like throughput drop or broken link. > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root > cause is not fully

Re: [GIT PULL] fbdev fixes for 4.9

On Tue, Nov 15, 2016 at 3:40 AM, Tomi Valkeinen wrote: > > I did test compile, and I would have noticed errors but I missed the warnings > (I blame the flu...). I need to improve my testing methods, but I couldn't > find > a way to add -Werror to kernel builds. I guess I should just always

Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options

On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote: > On some platforms, energy efficient ethernet with rtl8211 devices is > causing issue, like throughput drop or broken link. > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root > cause is not fully

[PATCH 0/2] MMC: davinci: fix card detect and write protect

This series fixes the card detect and write protect parsing for the davinci_mmc driver, and takes care of a technical debt to remove card polling when a card detect gpio is available. In the case of a platform based boot we register the gpios using the APIs provided by slot-gpio. In the case of

[PATCH 0/2] MMC: davinci: fix card detect and write protect

This series fixes the card detect and write protect parsing for the davinci_mmc driver, and takes care of a technical debt to remove card polling when a card detect gpio is available. In the case of a platform based boot we register the gpios using the APIs provided by slot-gpio. In the case of

[PATCH 1/2] MMC: davinci: use mmc_of_parse to parse common mmc configuration

Card detect and write protect are currently not working on a DT boot, and the driver relies on polling to get the state of the card. The current code depends on platform data callbacks to register and get the state of the gpios. mmc core provides a generic way to parse device tree configuration,

[PATCH 2/2] MMC: davinci: request gpios using gpio descriptors

Request card detect and write protect gpios using the provided API by mmc core. If a gpio is provided for card detect, we don't need to poll. So only use polling when a gpio is not provided. Once all pdata users register the gpios using gpio descriptors, we could remove the platform callbacks.

[PATCH 1/2] MMC: davinci: use mmc_of_parse to parse common mmc configuration

Card detect and write protect are currently not working on a DT boot, and the driver relies on polling to get the state of the card. The current code depends on platform data callbacks to register and get the state of the gpios. mmc core provides a generic way to parse device tree configuration,

[PATCH 2/2] MMC: davinci: request gpios using gpio descriptors

Request card detect and write protect gpios using the provided API by mmc core. If a gpio is provided for card detect, we don't need to poll. So only use polling when a gpio is not provided. Once all pdata users register the gpios using gpio descriptors, we could remove the platform callbacks.

Re: [PATCH] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

Hi Michael, [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on v4.9-rc5] [cannot apply to next-20161115] [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/Michael

Re: [PATCH] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

Hi Michael, [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on v4.9-rc5] [cannot apply to next-20161115] [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/Michael

Re: [PATCH 1/5] arm64: dts: hip06: Correct hardware pin number of usb node

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > The ohci/ehci hardware pin number should be 640/641, correct them. > > Fixes: commit aa8d3e74f54d ("arm64: dts: Add initial dts for Hisilicon Hip06 > D03 board") > Signed-off-by: Kefeng Wang > --- Applied to the

Re: [PATCH 1/5] arm64: dts: hip06: Correct hardware pin number of usb node

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > The ohci/ehci hardware pin number should be 640/641, correct them. > > Fixes: commit aa8d3e74f54d ("arm64: dts: Add initial dts for Hisilicon Hip06 > D03 board") > Signed-off-by: Kefeng Wang > --- Applied to the hisilicon soc tree. Thanks!

Re: [PATCH 3/5] arm64: dts: hisilicon: Add initial dts for Hip07 D05 board

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > Adding initial dt file for Hip07 D05 board, it is with dual socket > and each socket has two SCCLs(supper cpu cluster), one SCCL contains > four clusters and each cluster has quard Cortex-A72. > > Since each SCCL has their own DDR controller,

Re: [PATCH 3/5] arm64: dts: hisilicon: Add initial dts for Hip07 D05 board

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > Adding initial dt file for Hip07 D05 board, it is with dual socket > and each socket has two SCCLs(supper cpu cluster), one SCCL contains > four clusters and each cluster has quard Cortex-A72. > > Since each SCCL has their own DDR controller,

Re: [PATCH] thunderbolt: fix compile-test dependencies

On Tue, Nov 15, 2016 at 04:58:53PM +0100, Arnd Bergmann wrote: > Building the Apple thunderbolt driver on non-x86 machines now produces > a harmless warning: > > warning: (THUNDERBOLT) selects APPLE_PROPERTIES which has unmet direct > dependencies (EFI && EFI_STUB && X86) > > As there is no

Re: [PATCH] thunderbolt: fix compile-test dependencies

On Tue, Nov 15, 2016 at 04:58:53PM +0100, Arnd Bergmann wrote: > Building the Apple thunderbolt driver on non-x86 machines now produces > a harmless warning: > > warning: (THUNDERBOLT) selects APPLE_PROPERTIES which has unmet direct > dependencies (EFI && EFI_STUB && X86) > > As there is no

Re: [PATCH 2/5] Documentation: arm64: Add Hisilicon Hip07 D05 dts binding

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > This patch adds documentation for the devicetree bindings used by > the DT files of Hisilicon Hip07 D05 board. > > Signed-off-by: Kefeng Wang > --- Applied to the hisilicon soc tree. Thanks! Best Regards, Wei >

Re: [PATCH 2/5] Documentation: arm64: Add Hisilicon Hip07 D05 dts binding

Hi Kefeng, On 2016/9/24 10:14, Kefeng Wang wrote: > This patch adds documentation for the devicetree bindings used by > the DT files of Hisilicon Hip07 D05 board. > > Signed-off-by: Kefeng Wang > --- Applied to the hisilicon soc tree. Thanks! Best Regards, Wei >

RE: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

> -Original Message- > From: Colin Ian King [mailto:colin.k...@canonical.com] > Sent: Tuesday, November 15, 2016 11:09 AM > To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, > Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri- > de...@lists.freedesktop.org > Cc:

fuse: max_background and congestion_threshold settings

Hello, Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of pending requests (i.e., requests that have been send to userspace but for which no reply was received

RE: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

> -Original Message- > From: Colin Ian King [mailto:colin.k...@canonical.com] > Sent: Tuesday, November 15, 2016 11:09 AM > To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, > Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri- > de...@lists.freedesktop.org > Cc:

fuse: max_background and congestion_threshold settings

Hello, Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of pending requests (i.e., requests that have been send to userspace but for which no reply was received

[PATCH] reset: Add Tegra BPMP reset driver

From: Thierry Reding This driver uses the services provided by the BPMP firmware driver to implement a reset driver based on the MRQ_RESET request. Signed-off-by: Thierry Reding --- Hi Philipp, I'm looking for an Acked-by on this because there are

[PATCH] reset: Add Tegra BPMP reset driver

From: Thierry Reding This driver uses the services provided by the BPMP firmware driver to implement a reset driver based on the MRQ_RESET request. Signed-off-by: Thierry Reding --- Hi Philipp, I'm looking for an Acked-by on this because there are complicated dependencies between this and

Re: [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes

Hi John, On 2016/11/7 16:44, John Garry wrote: > This patchset resolves some hip06 SAS device tree issues. > Series applied to the hisilicon soc tree. Thanks! Best Regards, Wei > John Garry (3): > arm64: dts: hisi: fix hip06 sas am-max-trans quirk > arm64: dts: hisi: disable sas0 and sas2

Re: [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes

Hi John, On 2016/11/7 16:44, John Garry wrote: > This patchset resolves some hip06 SAS device tree issues. > Series applied to the hisilicon soc tree. Thanks! Best Regards, Wei > John Garry (3): > arm64: dts: hisi: fix hip06 sas am-max-trans quirk > arm64: dts: hisi: disable sas0 and sas2

[PATCH 2/2] pci: pcie-designware-plat: updated author email

I returned to Synopsys and so I am sending this patch to update the email address of the pcie-designware-plat author. Signed-off-by: Joao Pinto --- drivers/pci/host/pcie-designware-plat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] pci: pcie-designware: Change Maintenance

I accepted the invitation from Pratyush to replace him in the pcie-designware maintenance. This patch makes the maintainer replacement and symplifies a bit the pcie-designware* maintenance structure. Signed-off-by: Joao Pinto Cc: Pratyush Anand Cc:

[PATCH 2/2] pci: pcie-designware-plat: updated author email

I returned to Synopsys and so I am sending this patch to update the email address of the pcie-designware-plat author. Signed-off-by: Joao Pinto --- drivers/pci/host/pcie-designware-plat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/host/pcie-designware-plat.c

[PATCH 1/2] pci: pcie-designware: Change Maintenance

I accepted the invitation from Pratyush to replace him in the pcie-designware maintenance. This patch makes the maintainer replacement and symplifies a bit the pcie-designware* maintenance structure. Signed-off-by: Joao Pinto Cc: Pratyush Anand Cc: Jose Abreu --- MAINTAINERS | 10 ++

Re: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

On 15/11/16 15:49, Deucher, Alexander wrote: >> -Original Message- >> From: Colin King [mailto:colin.k...@canonical.com] >> Sent: Tuesday, November 15, 2016 7:55 AM >> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, >> Tom; Huang, Ray; Nils Wallménius; Baoyou

Re: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

On 15/11/16 15:49, Deucher, Alexander wrote: >> -Original Message- >> From: Colin King [mailto:colin.k...@canonical.com] >> Sent: Tuesday, November 15, 2016 7:55 AM >> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, >> Tom; Huang, Ray; Nils Wallménius; Baoyou

Re: [PATCH -v1.1] kbuild: Steal gcc's pie from the very beginning

On Mon, Nov 14, 2016 at 09:45:29PM +0100, Borislav Petkov wrote: > From: Borislav Petkov > Date: Mon, 14 Nov 2016 19:41:31 +0100 > Subject: [PATCH] kbuild: Steal gcc's pie from the very beginning > > So Sebastian turned off the PIE for kernel builds but that was too late > -

Re: [PATCH -v1.1] kbuild: Steal gcc's pie from the very beginning

On Mon, Nov 14, 2016 at 09:45:29PM +0100, Borislav Petkov wrote: > From: Borislav Petkov > Date: Mon, 14 Nov 2016 19:41:31 +0100 > Subject: [PATCH] kbuild: Steal gcc's pie from the very beginning > > So Sebastian turned off the PIE for kernel builds but that was too late > - Kbuild.include

[PATCH] kasan: support use-after-scope detection

Gcc revision 241896 implements use-after-scope detection. Will be available in gcc 7. Support it in KASAN. Gcc emits 2 new callbacks to poison/unpoison large stack objects when they go in/out of scope. Implement the callbacks and add a test. Signed-off-by: Dmitry Vyukov Cc:

[PATCH] kasan: support use-after-scope detection

Gcc revision 241896 implements use-after-scope detection. Will be available in gcc 7. Support it in KASAN. Gcc emits 2 new callbacks to poison/unpoison large stack objects when they go in/out of scope. Implement the callbacks and add a test. Signed-off-by: Dmitry Vyukov Cc:

Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME

On 11/15/2016 9:33 AM, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote: >> The feature may be present and enabled even if it is not currently >> active. In other words, the SYS_CFG MSR bit could be set but we aren't >> actually using encryption (sme_me_mask

Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME

On 11/15/2016 9:33 AM, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote: >> The feature may be present and enabled even if it is not currently >> active. In other words, the SYS_CFG MSR bit could be set but we aren't >> actually using encryption (sme_me_mask

[PATCH] dwc3: make PM functions as __maybe_unused

A change to the suspend/resume handling in dwc3-pci introduced a harmless warning: drivers/usb/dwc3/dwc3-pci.c:169:12: error: ‘dwc3_pci_dsm’ defined but not used [-Werror=unused-function] Replacing the #ifdef around the PM functions with __maybe_unused annotations is the easiest way to make

[PATCH] dwc3: make PM functions as __maybe_unused

A change to the suspend/resume handling in dwc3-pci introduced a harmless warning: drivers/usb/dwc3/dwc3-pci.c:169:12: error: ‘dwc3_pci_dsm’ defined but not used [-Werror=unused-function] Replacing the #ifdef around the PM functions with __maybe_unused annotations is the easiest way to make

RE: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Tuesday, November 15, 2016 7:55 AM > To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, > Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri- > de...@lists.freedesktop.org > Cc:

RE: [PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Tuesday, November 15, 2016 7:55 AM > To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis, > Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri- > de...@lists.freedesktop.org > Cc:

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