[PATCH v4 0/3] ASoC driver for the TSE-850

Hi! v3 -> v4 changes: - changed heading of the devicetree bindings as requested by Rob - add ack from Rob on patch 2/3 - rebased onto v4.9-rc5 v2 -> v3 changes: - update the preparatory atmel_ssc_dai patch with error checking and fallback handling of the CMR_DIV divider in addition to the new

[PATCH v4 0/3] ASoC driver for the TSE-850

Hi! v3 -> v4 changes: - changed heading of the devicetree bindings as requested by Rob - add ack from Rob on patch 2/3 - rebased onto v4.9-rc5 v2 -> v3 changes: - update the preparatory atmel_ssc_dai patch with error checking and fallback handling of the CMR_DIV divider in addition to the new

[PATCH v4 1/3] ASoC: atmel_ssc_dai: if not provided, default to sensible dividers

When this driver masters BCLK and/or LRCLK, and noone has stated differently, assume that all the bits of a frame are used. This relieves the cpu dai users from the duty to fill in the dividers for the common case. Signed-off-by: Peter Rosin --- sound/soc/atmel/atmel_ssc_dai.c

[PATCH v4 1/3] ASoC: atmel_ssc_dai: if not provided, default to sensible dividers

When this driver masters BCLK and/or LRCLK, and noone has stated differently, assume that all the bits of a frame are used. This relieves the cpu dai users from the duty to fill in the dividers for the common case. Signed-off-by: Peter Rosin --- sound/soc/atmel/atmel_ssc_dai.c | 83

[PATCH v4 2/3] ASoC: tse850: document axentia,tse850-pcm5142 bindings

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Acked-by: Rob Herring Signed-off-by: Peter Rosin ---

[PATCH v4 2/3] ASoC: tse850: document axentia,tse850-pcm5142 bindings

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Acked-by: Rob Herring Signed-off-by: Peter Rosin --- .../bindings/sound/axentia,tse850-pcm5142.txt | 88 ++

Re: [PATCH] staging: slicoss: fix different address space warnings

Hi Sergio, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.9-rc5 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/Sergio-Paracuellos/staging-slicoss

Re: [PATCH] staging: slicoss: fix different address space warnings

Hi Sergio, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.9-rc5 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/Sergio-Paracuellos/staging-slicoss

Re: perf: fuzzer KASAN unwind_get_return_address

On Tue, Nov 15, 2016 at 02:05:50PM -0500, Vince Weaver wrote: > On Tue, 15 Nov 2016, Peter Zijlstra wrote: > > > On Tue, Nov 15, 2016 at 12:43:56PM -0500, Vince Weaver wrote: > > > > > > Running on my haswell machine with the imc/uncore patch applied, the > > > perf_fuzzer next tripped over

Re: perf: fuzzer KASAN unwind_get_return_address

On Tue, Nov 15, 2016 at 02:05:50PM -0500, Vince Weaver wrote: > On Tue, 15 Nov 2016, Peter Zijlstra wrote: > > > On Tue, Nov 15, 2016 at 12:43:56PM -0500, Vince Weaver wrote: > > > > > > Running on my haswell machine with the imc/uncore patch applied, the > > > perf_fuzzer next tripped over

Re: [PATCH] [STYLE]staging:skein:threefish_block.c remove blank lines

Hi Walt, Please ignore our side conversation, On Sat, Nov 12, 2016 at 03:02:53PM -0500, Walt Feasel wrote: > Made suggested modifications from checkpatch in reference > to CHECK: Please don't use multiple blank lines > > Signed-off-by: Walt Feasel Acked-by: Jason Cooper

Re: [PATCH] [STYLE]staging:skein:threefish_block.c remove blank lines

Hi Walt, Please ignore our side conversation, On Sat, Nov 12, 2016 at 03:02:53PM -0500, Walt Feasel wrote: > Made suggested modifications from checkpatch in reference > to CHECK: Please don't use multiple blank lines > > Signed-off-by: Walt Feasel Acked-by: Jason Cooper thx, Jason.

Re: [PATCH] [STYLE]staging:skein:threefish_block.c remove blank lines

Hi Dan, On Mon, Nov 14, 2016 at 01:34:15PM +0300, Dan Carpenter wrote: > Please just delete the blank lines. Sure, if that's what you guys prefer. > You aren't that special like a snow flake. Someone put his grumpy pants on backwards, didn't he? thx, Jason.

Re: [PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

On Tue, Nov 15, 2016 at 12:38 PM, Steven Rostedt wrote: > On Tue, 15 Nov 2016 12:31:20 -0800 > Joel Fernandes wrote: > >> Currently the global_ops filtering hash is not available to outside >> users registering for function tracing. Provide an API for

Re: perf: fuzzer KASAN unwind_get_return_address

On Tue, Nov 15, 2016 at 11:04:45AM -0800, Dmitry Vyukov wrote: > On Tue, Nov 15, 2016 at 10:57 AM, Peter Zijlstra wrote: > > On Tue, Nov 15, 2016 at 12:43:56PM -0500, Vince Weaver wrote: > >> > >> Running on my haswell machine with the imc/uncore patch applied, the > >>

Re: [PATCH] [STYLE]staging:skein:threefish_block.c remove blank lines

Hi Dan, On Mon, Nov 14, 2016 at 01:34:15PM +0300, Dan Carpenter wrote: > Please just delete the blank lines. Sure, if that's what you guys prefer. > You aren't that special like a snow flake. Someone put his grumpy pants on backwards, didn't he? thx, Jason.

Re: [PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

On Tue, Nov 15, 2016 at 12:38 PM, Steven Rostedt wrote: > On Tue, 15 Nov 2016 12:31:20 -0800 > Joel Fernandes wrote: > >> Currently the global_ops filtering hash is not available to outside >> users registering for function tracing. Provide an API for those >> users to be able to choose global

Re: perf: fuzzer KASAN unwind_get_return_address

On Tue, Nov 15, 2016 at 11:04:45AM -0800, Dmitry Vyukov wrote: > On Tue, Nov 15, 2016 at 10:57 AM, Peter Zijlstra wrote: > > On Tue, Nov 15, 2016 at 12:43:56PM -0500, Vince Weaver wrote: > >> > >> Running on my haswell machine with the imc/uncore patch applied, the > >> perf_fuzzer next tripped

Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 11/15/2016 12:46 PM, Lino Sanfilippo wrote: >> Could this be pulled out into a standard PHY driver? All the SLIC >> SLIC_PCR_ defines seems to be the same as those in mii.h. This could >> be a standard PHY hidden behind a single register. >> >>Andrew > > You are right, the driver should

Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 11/15/2016 12:46 PM, Lino Sanfilippo wrote: >> Could this be pulled out into a standard PHY driver? All the SLIC >> SLIC_PCR_ defines seems to be the same as those in mii.h. This could >> be a standard PHY hidden behind a single register. >> >>Andrew > > You are right, the driver should

Re: [PATCH v13 10/22] vfio iommu type1: Add support for mediated devices

On Tue, 15 Nov 2016 20:59:53 +0530 Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use

Re: [PATCH v13 10/22] vfio iommu type1: Add support for mediated devices

On Tue, 15 Nov 2016 20:59:53 +0530 Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use most of the code of

Re: [RFC][PATCH 2/7] kref: Add kref_read()

On Tue, Nov 15, 2016 at 12:03 AM, Peter Zijlstra wrote: > On Tue, Nov 15, 2016 at 08:33:22AM +0100, Greg KH wrote: >> On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote: > >> > --- a/drivers/block/drbd/drbd_req.c >> > +++ b/drivers/block/drbd/drbd_req.c >> > @@

Re: [RFC][PATCH 2/7] kref: Add kref_read()

On Tue, Nov 15, 2016 at 12:03 AM, Peter Zijlstra wrote: > On Tue, Nov 15, 2016 at 08:33:22AM +0100, Greg KH wrote: >> On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote: > >> > --- a/drivers/block/drbd/drbd_req.c >> > +++ b/drivers/block/drbd/drbd_req.c >> > @@ -520,7 +520,7 @@ static

Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

Hi, On 13.11.2016 20:55, Andrew Lunn wrote: >> +static const char slic_stats_strings[][ETH_GSTRING_LEN] = { >> +"rx_packets ", >> +"rx_bytes ", >> +"rx_multicasts ", >> +"rx_errors ", >> +"rx_buff_miss ", >> +"rx_tp_csum ", >> +"rx_tp_oflow",

Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

Hi, On 13.11.2016 20:55, Andrew Lunn wrote: >> +static const char slic_stats_strings[][ETH_GSTRING_LEN] = { >> +"rx_packets ", >> +"rx_bytes ", >> +"rx_multicasts ", >> +"rx_errors ", >> +"rx_buff_miss ", >> +"rx_tp_csum ", >> +"rx_tp_oflow",

Re: [PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

On Tue, 15 Nov 2016 12:31:20 -0800 Joel Fernandes wrote: > Currently the global_ops filtering hash is not available to outside > users registering for function tracing. Provide an API for those > users to be able to choose global filtering. > > This is in preparation for

Re: [PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

On Tue, 15 Nov 2016 12:31:20 -0800 Joel Fernandes wrote: > Currently the global_ops filtering hash is not available to outside > users registering for function tracing. Provide an API for those > users to be able to choose global filtering. > > This is in preparation for pstore's ftrace feature

[RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device

The following use-after-free reports were seen on resume with a specific USB hub. BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c at addr ffc0cc1a2eb0 BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc at addr ffc0cc1a2eb0 Relevant traceback

[RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device

The following use-after-free reports were seen on resume with a specific USB hub. BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c at addr ffc0cc1a2eb0 BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc at addr ffc0cc1a2eb0 Relevant traceback

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

On 11/15/2016 12:17 PM, Radim Krčmář wrote: > 2016-11-15 11:02-0600, Tom Lendacky: >> 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

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

On 11/15/2016 12:17 PM, Radim Krčmář wrote: > 2016-11-15 11:02-0600, Tom Lendacky: >> 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

[PATCH v2 2/2] pstore: Use global ftrace filters for function trace filtering

Currently, pstore doesn't have any filters setup for function tracing. This has the associated overhead and may not be useful for users looking for tracing specific set of functions. ftrace's regular function trace filtering is done writing to tracing/set_ftrace_filter however this is not

[PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

Currently the global_ops filtering hash is not available to outside users registering for function tracing. Provide an API for those users to be able to choose global filtering. This is in preparation for pstore's ftrace feature to be able to use the global filters. Suggested-by: Steven Rostedt

[PATCH v2 2/2] pstore: Use global ftrace filters for function trace filtering

Currently, pstore doesn't have any filters setup for function tracing. This has the associated overhead and may not be useful for users looking for tracing specific set of functions. ftrace's regular function trace filtering is done writing to tracing/set_ftrace_filter however this is not

[PATCH v2 1/2] ftrace: Provide API to use global filtering for ftrace ops

Currently the global_ops filtering hash is not available to outside users registering for function tracing. Provide an API for those users to be able to choose global filtering. This is in preparation for pstore's ftrace feature to be able to use the global filters. Suggested-by: Steven Rostedt

[PATCH v2 0/2] Global filtering for ftrace functions

Currently enabling /sys/kernel/debug/pstore/record_ftrace traces all functions and setting set_ftrace_filter doesn't apply. These patches allow one to set_ftrace_filter and have pstore make use of the filtering feature resulting in lower overhead and performance improvement. Changes in v2 are

[PATCH v2 0/2] Global filtering for ftrace functions

Currently enabling /sys/kernel/debug/pstore/record_ftrace traces all functions and setting set_ftrace_filter doesn't apply. These patches allow one to set_ftrace_filter and have pstore make use of the filtering feature resulting in lower overhead and performance improvement. Changes in v2 are

[no subject]

> > There is a deadlock, Peter!!! > > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ? > The description was given earlier in the the thread and the drawbacks of using RT_RUNTIME_SHARE as well.

[no subject]

> > There is a deadlock, Peter!!! > > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ? > The description was given earlier in the the thread and the drawbacks of using RT_RUNTIME_SHARE as well.

[PATCH 1/4] x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag

The X86_FEATURE_TSC_RELIABLE flag in Linux kernel implies both reliable (at runtime) and trustable (at calibration). But reliable running and trustable calibration are logically irrelevant. Per Thomas Gleixner's suggestion we would like to split this flag into two separate flags:

[PATCH 3/4] x86/tsc: mark Intel ATOM_GOLDMONT TSC reliable

On Intel GOLDMONT Atom SoC TSC is the only reliable clocksource. We mark TSC reliable to avoid watchdog on it. Signed-off-by: Bin Gao --- arch/x86/kernel/tsc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index

[PATCH 3/4] x86/tsc: mark Intel ATOM_GOLDMONT TSC reliable

On Intel GOLDMONT Atom SoC TSC is the only reliable clocksource. We mark TSC reliable to avoid watchdog on it. Signed-off-by: Bin Gao --- arch/x86/kernel/tsc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index f1a7fb5..354b302 100644

[PATCH 1/4] x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag

The X86_FEATURE_TSC_RELIABLE flag in Linux kernel implies both reliable (at runtime) and trustable (at calibration). But reliable running and trustable calibration are logically irrelevant. Per Thomas Gleixner's suggestion we would like to split this flag into two separate flags:

[PATCH 4/4] x86/tsc: set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs

TSC on Intel Atom SoCs capable of determining TSC frequency by MSR is reliable and the frequency is known (because it's provided by HW). On these platforms PIT/HPET is generally not available so calibration won't work at all and also TSC is the only reliable clocksource. So we set both

[PATCH 4/4] x86/tsc: set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs

TSC on Intel Atom SoCs capable of determining TSC frequency by MSR is reliable and the frequency is known (because it's provided by HW). On these platforms PIT/HPET is generally not available so calibration won't work at all and also TSC is the only reliable clocksource. So we set both

[PATCH 0/4] x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag and hardware related changes

This patch series adds X86_FEATURE_TSC_KNOWN_FREQ flag and modifies Intel Atom SoC related TSC codes to use the new TSC_KNOWN_FREQ flag and the existed TSC_RELIABLE flag. Bin Gao (4): x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag x86/tsc: mark TSC frequency determined by CPUID as known

[PATCH 2/4] x86/tsc: mark TSC frequency determined by CPUID as known

Unlike TSC calibration where we determin TSC frequency by another timer with known frequency, CPUs/SoCs with CPUID leaf 0x15 come with a known frequency and will report the frequency to software via CPUID instruction. This hardware provided frequency is the "real" frequency of TSC so we set the

[PATCH 0/4] x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag and hardware related changes

This patch series adds X86_FEATURE_TSC_KNOWN_FREQ flag and modifies Intel Atom SoC related TSC codes to use the new TSC_KNOWN_FREQ flag and the existed TSC_RELIABLE flag. Bin Gao (4): x86/tsc: add X86_FEATURE_TSC_KNOWN_FREQ flag x86/tsc: mark TSC frequency determined by CPUID as known

[PATCH 2/4] x86/tsc: mark TSC frequency determined by CPUID as known

Unlike TSC calibration where we determin TSC frequency by another timer with known frequency, CPUs/SoCs with CPUID leaf 0x15 come with a known frequency and will report the frequency to software via CPUID instruction. This hardware provided frequency is the "real" frequency of TSC so we set the

Re: [PATCH 03/15] net: bcm63xx_enet: Utilize phy_ethtool_nway_reset

On 11/15/2016 11:59 AM, Heinrich Schuchardt wrote: > On 11/15/2016 07:06 PM, Florian Fainelli wrote: >> Signed-off-by: Florian Fainelli > > Each patch of your patch series should have a commit message. It's pretty obvious what this does, really. > > You can add the

Re: [PATCH 03/15] net: bcm63xx_enet: Utilize phy_ethtool_nway_reset

On 11/15/2016 11:59 AM, Heinrich Schuchardt wrote: > On 11/15/2016 07:06 PM, Florian Fainelli wrote: >> Signed-off-by: Florian Fainelli > > Each patch of your patch series should have a commit message. It's pretty obvious what this does, really. > > You can add the missing commit messages

Re: [PATCH v2] f2fs: don't wait writeback for datas during checkpoint

Hi Chao, On Tue, Nov 15, 2016 at 07:33:27PM +0800, Chao Yu wrote: > Normally, while committing checkpoint, we will wait on all pages to be > writebacked no matter the page is data or metadata, so in scenario where > there are lots of data IO being submitted with metadata, we may suffer > long

Re: [PATCH v2] f2fs: don't wait writeback for datas during checkpoint

Hi Chao, On Tue, Nov 15, 2016 at 07:33:27PM +0800, Chao Yu wrote: > Normally, while committing checkpoint, we will wait on all pages to be > writebacked no matter the page is data or metadata, so in scenario where > there are lots of data IO being submitted with metadata, we may suffer > long

Re: [PATCH 03/15] net: bcm63xx_enet: Utilize phy_ethtool_nway_reset

On 11/15/2016 07:06 PM, Florian Fainelli wrote: > Signed-off-by: Florian Fainelli Each patch of your patch series should have a commit message. You can add the missing commit messages with git rebase -i HEAD~15 choosing reword. Please, add a cover letter message

Re: [PATCH 03/15] net: bcm63xx_enet: Utilize phy_ethtool_nway_reset

On 11/15/2016 07:06 PM, Florian Fainelli wrote: > Signed-off-by: Florian Fainelli Each patch of your patch series should have a commit message. You can add the missing commit messages with git rebase -i HEAD~15 choosing reword. Please, add a cover letter message describing the patch series

[PATCH v2] usb: dwc2: add amcc,dwc-otg support

From: Christian Lamparter This patch adds support for the "amcc,usb-otg" device which is found in the PowerPC Canyonlands' dts. The device definition was added by: commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board") but without any driver

[PATCH v2] usb: dwc2: add amcc,dwc-otg support

From: Christian Lamparter This patch adds support for the "amcc,usb-otg" device which is found in the PowerPC Canyonlands' dts. The device definition was added by: commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board") but without any driver support as the dwc2 driver

Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops

Hi Kees, On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook wrote: > Hi Joel, > > I've reorganized a bunch of the logic here. Since pstore is going to need > the init_przs() logic for multiple pmsg przs, I wanted to get this in and > make sure I was happy with how it looks. I

Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops

Hi Kees, On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook wrote: > Hi Joel, > > I've reorganized a bunch of the logic here. Since pstore is going to need > the init_przs() logic for multiple pmsg przs, I wanted to get this in and > make sure I was happy with how it looks. I figured this would reduce

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

On Tue, Nov 15, 2016 at 8:33 PM, Stefan Wahren wrote: > Hi Ksenija, > >> Ksenija Stanojevic hat am 2. November 2016 um >> 08:38 geschrieben: >> >> >> Add core files for low resolution analog-to-digital converter (mxs-lradc) >> MFD driver. >>

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

On Tue, Nov 15, 2016 at 8:33 PM, Stefan Wahren wrote: > Hi Ksenija, > >> Ksenija Stanojevic hat am 2. November 2016 um >> 08:38 geschrieben: >> >> >> Add core files for low resolution analog-to-digital converter (mxs-lradc) >> MFD driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >>

Re: [PATCH V4 00/15] blk-throttle: add .high limit

On 11/14/2016 05:28 PM, Shaohua Li wrote: On Mon, Nov 14, 2016 at 05:18:28PM -0800, Bart Van Assche wrote: Unless someone can convince me of the opposite I think that coming up with an algorithm for estimating I/O cost is essential to guarantee I/O fairness without requesting users to perform

Re: [PATCH V4 00/15] blk-throttle: add .high limit

On 11/14/2016 05:28 PM, Shaohua Li wrote: On Mon, Nov 14, 2016 at 05:18:28PM -0800, Bart Van Assche wrote: Unless someone can convince me of the opposite I think that coming up with an algorithm for estimating I/O cost is essential to guarantee I/O fairness without requesting users to perform

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Wed, Aug 24, 2016 at 08:57:21AM +0200, Frans Klaver wrote: > On Tue, Aug 23, 2016 at 10:03 AM, Frans Klaver wrote: > > On Tue, Aug 23, 2016 at 9:05 AM, David Miller wrote: > >> From: Frans Klaver > >> Date: Tue, 23 Aug 2016

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Wed, Aug 24, 2016 at 08:57:21AM +0200, Frans Klaver wrote: > On Tue, Aug 23, 2016 at 10:03 AM, Frans Klaver wrote: > > On Tue, Aug 23, 2016 at 9:05 AM, David Miller wrote: > >> From: Frans Klaver > >> Date: Tue, 23 Aug 2016 09:03:20 +0200 > >> > >>> On Tue, Aug 23, 2016 at 1:30 AM, David

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

Hi Ksenija, > Ksenija Stanojevic hat am 2. November 2016 um > 08:38 geschrieben: > > > Add core files for low resolution analog-to-digital converter (mxs-lradc) > MFD driver. > > Signed-off-by: Ksenija Stanojevic > --- > Changes in

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

Hi Ksenija, > Ksenija Stanojevic hat am 2. November 2016 um > 08:38 geschrieben: > > > 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. > > Changes in v8: > -

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

I agree that both patches try to solve the same problem in a very similar way. Florian Westphal's patch do two more things: 1- add warning with pr_warn_ratelimited. I like this idea. I also though about adding some message but I have no kernel experience and I preferred to have just a working

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

I agree that both patches try to solve the same problem in a very similar way. Florian Westphal's patch do two more things: 1- add warning with pr_warn_ratelimited. I like this idea. I also though about adding some message but I have no kernel experience and I preferred to have just a working

Re: [PATCH v05 14/72] include/uapi/asm-generic/ipcbuf.h: include linux/posix_types.h

On Wed, Aug 24, 2016 at 05:36:22PM +0200, Arnd Bergmann wrote: > On Monday, August 22, 2016 8:32:31 PM CEST Mikko Rapeli wrote: > > Fixes userspace compilation error: > > > > error: unknown type name ‘__kernel_key_t’ > > > > Signed-off-by: Mikko Rapeli > > > > Looks good.

Re: [PATCH v05 14/72] include/uapi/asm-generic/ipcbuf.h: include linux/posix_types.h

On Wed, Aug 24, 2016 at 05:36:22PM +0200, Arnd Bergmann wrote: > On Monday, August 22, 2016 8:32:31 PM CEST Mikko Rapeli wrote: > > Fixes userspace compilation error: > > > > error: unknown type name ‘__kernel_key_t’ > > > > Signed-off-by: Mikko Rapeli > > > > Looks good. I was on Cc for

Re: [PATCH v4 8/8] clocksource: import ARC timer driver

On Tue, Nov 15, 2016 at 06:05:32PM +, Noam Camus wrote: > >From: Daniel Lezcano > > >Sent: Tuesday, November 15, 2016 7:49 PM > > > I believe the request was for you. > Indeed it was. > > However no formal Ack was made by you. Since I got no tree I preferred

Re: [PATCH v4 8/8] clocksource: import ARC timer driver

On Tue, Nov 15, 2016 at 06:05:32PM +, Noam Camus wrote: > >From: Daniel Lezcano > > >Sent: Tuesday, November 15, 2016 7:49 PM > > > I believe the request was for you. > Indeed it was. > > However no formal Ack was made by you. Since I got no tree I preferred that > you will take the

Re: [PATCH 04/15] net: mv643xx_eth: Utilize phy_ethtool_nway_reset

On Tue, Nov 15, 2016 at 10:06:33AM -0800, Florian Fainelli wrote: > Signed-off-by: Florian Fainelli Reviewed-by: Andrew Lunn Andrew

Re: [PATCH 04/15] net: mv643xx_eth: Utilize phy_ethtool_nway_reset

On Tue, Nov 15, 2016 at 10:06:33AM -0800, Florian Fainelli wrote: > Signed-off-by: Florian Fainelli Reviewed-by: Andrew Lunn Andrew

Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop

On 15 November 2016 at 19:18, Stephen Boyd wrote: > On 11/15, Ard Biesheuvel wrote: >> On 19 October 2016 at 00:42, Stephen Boyd wrote: >> > In similar spirit to x86 and arm64 support, add a make_nop_arm() >> > to replace calls to mcount with a nop in

Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop

On 15 November 2016 at 19:18, Stephen Boyd wrote: > On 11/15, Ard Biesheuvel wrote: >> On 19 October 2016 at 00:42, Stephen Boyd wrote: >> > In similar spirit to x86 and arm64 support, add a make_nop_arm() >> > to replace calls to mcount with a nop in sections that aren't >> > traced. >> > >> >

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra wrote: > > > On 15 November 2016 19:06:28 CET, Kees Cook wrote: > >>I'll want to modify this in the future; I have a config already doing >>"Bug on data structure corruption" that makes the warn/bug

Re: [PATCH v15 01/13] clocksource/drivers/arm_arch_timer: Move enums and defines to header file

Hi Fu, [auto build test ERROR on tip/timers/core] [also build test ERROR on v4.9-rc5 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/fu-wei-linaro-org/acpi-clocksource-add-GTDT

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra wrote: > > > On 15 November 2016 19:06:28 CET, Kees Cook wrote: > >>I'll want to modify this in the future; I have a config already doing >>"Bug on data structure corruption" that makes the warn/bug choice. >>It'll need some massaging to fit into

Re: [PATCH v15 01/13] clocksource/drivers/arm_arch_timer: Move enums and defines to header file

Hi Fu, [auto build test ERROR on tip/timers/core] [also build test ERROR on v4.9-rc5 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/fu-wei-linaro-org/acpi-clocksource-add-GTDT

[PATCH net-next 4/5] net: ethernet: mvpp2: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/mvpp2.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 4/5] net: ethernet: mvpp2: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/mvpp2.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 2/5] net: ethoc: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/ethoc.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 5/5] net: ethernet: marvell: pxa168_eth: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/pxa168_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 2/5] net: ethoc: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/ethoc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ethoc.c

[PATCH net-next 5/5] net: ethernet: marvell: pxa168_eth: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/pxa168_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 1/5] net: stmmac: Implement ethtool::nway_reset

Utilize the generic phy_ethtool_nway_reset() helper function to implement an autonegotiation restart. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 3/5] net: ethernet: mvneta: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/mvneta.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next 1/5] net: stmmac: Implement ethtool::nway_reset

Utilize the generic phy_ethtool_nway_reset() helper function to implement an autonegotiation restart. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c

[PATCH net-next 3/5] net: ethernet: mvneta: Implement ethtool::nway_reset

Implement ethtool::nway_reset using phy_ethtool_nway_reset. We are already using dev->phydev all over the place so this comes for free. Signed-off-by: Florian Fainelli --- drivers/net/ethernet/marvell/mvneta.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop

On 11/15, Ard Biesheuvel wrote: > On 19 October 2016 at 00:42, Stephen Boyd wrote: > > In similar spirit to x86 and arm64 support, add a make_nop_arm() > > to replace calls to mcount with a nop in sections that aren't > > traced. > > > > Cc: Russell King

Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop

On 11/15, Ard Biesheuvel wrote: > On 19 October 2016 at 00:42, Stephen Boyd wrote: > > In similar spirit to x86 and arm64 support, add a make_nop_arm() > > to replace calls to mcount with a nop in sections that aren't > > traced. > > > > Cc: Russell King > > Acked-by: Rabin Vincent > >

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On 15 November 2016 19:06:28 CET, Kees Cook wrote: >I'll want to modify this in the future; I have a config already doing >"Bug on data structure corruption" that makes the warn/bug choice. >It'll need some massaging to fit into the new refcount_t checks, but >it should

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On 15 November 2016 19:06:28 CET, Kees Cook wrote: >I'll want to modify this in the future; I have a config already doing >"Bug on data structure corruption" that makes the warn/bug choice. >It'll need some massaging to fit into the new refcount_t checks, but >it should be okay -- there needs

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

On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > >> Since DMA addresses will effectively look like 48-bit addresses when the > >> memory encryption mask is set,

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

On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > >> Since DMA addresses will effectively look like 48-bit addresses when the > >> memory encryption mask is set,

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

On 11/14/2016 3:00 PM, John Youn wrote: > On 11/11/2016 3:12 PM, Christian Lamparter wrote: >> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote: >>> On 11/11/2016 2:05 PM, Christian Lamparter wrote: On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > On 11/11/2016

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

On 11/14/2016 3:00 PM, John Youn wrote: > On 11/11/2016 3:12 PM, Christian Lamparter wrote: >> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote: >>> On 11/11/2016 2:05 PM, Christian Lamparter wrote: On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > On 11/11/2016

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