[PATCH] firmware: qcom_scm: Add missing is_available API

Add back function that was dropped when reworking the SCM code. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 84330c5..89c3775 100644

[PATCH] firmware: qcom_scm: Add missing is_available API

Add back function that was dropped when reworking the SCM code. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 84330c5..89c3775 100644 ---

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 4:15 PM, Andrew Lunn wrote: > On Wed, Jun 29, 2016 at 04:08:20PM -0400, Jon Mason wrote: >> On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: >> > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: >> >> On 06/29/2016 07:13

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 4:15 PM, Andrew Lunn wrote: > On Wed, Jun 29, 2016 at 04:08:20PM -0400, Jon Mason wrote: >> On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: >> > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: >> >> On 06/29/2016 07:13 AM, Andrew Lunn wrote: >> >> >

Re: [LKP] [x86/KASLR] ed9f007ee6: -- System halted

Hi, Yinghai, Yinghai Lu writes: > On Tue, Jun 28, 2016 at 12:49 PM, Yinghai Lu wrote: >> On Mon, Jun 27, 2016 at 10:43 PM, Ye Xiaolong wrote: >>> On Mon, Jun 27, 2016 at 11:59:37AM -0700, Yinghai Lu wrote: output is:

Re: [LKP] [x86/KASLR] ed9f007ee6: -- System halted

Hi, Yinghai, Yinghai Lu writes: > On Tue, Jun 28, 2016 at 12:49 PM, Yinghai Lu wrote: >> On Mon, Jun 27, 2016 at 10:43 PM, Ye Xiaolong wrote: >>> On Mon, Jun 27, 2016 at 11:59:37AM -0700, Yinghai Lu wrote: output is: early console in setup code early console in extract_kernel

[PATCH 2/2] fs: befs: remove comment that confuses kernel-doc

This comment with a mysterious unfinished line confuses the kernel-doc system since, because it starts with /**, it thinks it is documenting a function. Signed-off-by: Luis de Bethencourt --- fs/befs/linuxvfs.c | 4 1 file changed, 4 deletions(-) diff --git

[PATCH 2/2] fs: befs: remove comment that confuses kernel-doc

This comment with a mysterious unfinished line confuses the kernel-doc system since, because it starts with /**, it thinks it is documenting a function. Signed-off-by: Luis de Bethencourt --- fs/befs/linuxvfs.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/befs/linuxvfs.c

[PATCH 1/2] fs: befs: check silent flag before logging error

Log error only when silent flag is not set. Fixes: dbe6460388bc ("fs/befs/linuxvfs.c: check silent flag before logging errors") Signed-off-by: Luis de Bethencourt --- Hi, Reading the backlog of latest patches to befs, I noticed that Salah's patch missed one call to

[PATCH 1/2] fs: befs: check silent flag before logging error

Log error only when silent flag is not set. Fixes: dbe6460388bc ("fs/befs/linuxvfs.c: check silent flag before logging errors") Signed-off-by: Luis de Bethencourt --- Hi, Reading the backlog of latest patches to befs, I noticed that Salah's patch missed one call to befs_error() when setting

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 04:08:20PM -0400, Jon Mason wrote: > On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: > > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: > >> On 06/29/2016 07:13 AM, Andrew Lunn wrote: > >> > Hi Jon > >> > > >> > I know you are just

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 04:08:20PM -0400, Jon Mason wrote: > On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: > > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: > >> On 06/29/2016 07:13 AM, Andrew Lunn wrote: > >> > Hi Jon > >> > > >> > I know you are just refactoring code,

[PATCH] mtdpart: propagate _get/put_device()

If the master device has callbacks for _get/put_device() and this MTD has slaves a get_mtd_device() call on paritions will never issue the registered callbacks. Fix this by propergating _get/put_device() down. Signed-off-by: Richard Weinberger --- Hi! I've found this issue while

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On June 29, 2016 12:46:35 PM PDT, Greg KH wrote: >On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: >> On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: >> > copyleft-next [0] [1] is an openly evolved copyleft license, its an >> >

[PATCH] mtdpart: propagate _get/put_device()

If the master device has callbacks for _get/put_device() and this MTD has slaves a get_mtd_device() call on paritions will never issue the registered callbacks. Fix this by propergating _get/put_device() down. Signed-off-by: Richard Weinberger --- Hi! I've found this issue while heavily

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On June 29, 2016 12:46:35 PM PDT, Greg KH wrote: >On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: >> On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: >> > copyleft-next [0] [1] is an openly evolved copyleft license, its an >> > effort to evolve copyleft

[RFC][PATCH 0/3] vsprintf: Do not dereference pointers in bstr_printf()

vbin_printf() and bstr_printf() are used by trace_printk(), when it is possible to optimize to copying the binary arguments into the ring buffer and doing the final conversions at the time of reading the ring buffer. This is advantageous as it removes computer processing from the executing of

[RFC][PATCH 0/3] vsprintf: Do not dereference pointers in bstr_printf()

vbin_printf() and bstr_printf() are used by trace_printk(), when it is possible to optimize to copying the binary arguments into the ring buffer and doing the final conversions at the time of reading the ring buffer. This is advantageous as it removes computer processing from the executing of

[RFC][PATCH 1/3] vsprintf: Prevent vbin_printf() from using dereferenced pointers

From: "Steven Rostedt (Red Hat)" vbin_printf() is used in conjunction with bstr_printf() to record some printf() statment and to show it later. It is currently used exclusively with trace_printk() which records the binary format into the trace ring buffer and formats the

[RFC][PATCH 3/3] vsprintf: Add support for %pb and friends to vbin_printf()

From: "Steven Rostedt (Red Hat)" printk() allows a %pb to print out cpumasks. As it uses a pointer to reference the mask it can be problematic for vbin_printf() to use, as the referencing is done at a later time (via bstr_printf()). Instead of saving the pointer to the

[RFC][PATCH 1/3] vsprintf: Prevent vbin_printf() from using dereferenced pointers

From: "Steven Rostedt (Red Hat)" vbin_printf() is used in conjunction with bstr_printf() to record some printf() statment and to show it later. It is currently used exclusively with trace_printk() which records the binary format into the trace ring buffer and formats the output at a later time

[RFC][PATCH 3/3] vsprintf: Add support for %pb and friends to vbin_printf()

From: "Steven Rostedt (Red Hat)" printk() allows a %pb to print out cpumasks. As it uses a pointer to reference the mask it can be problematic for vbin_printf() to use, as the referencing is done at a later time (via bstr_printf()). Instead of saving the pointer to the cpumask, simply save the

[RFC][PATCH 2/3] vsprintf: Add support for %pf and %pF to vbin_printf()

From: "Steven Rostedt (Red Hat)" Some architectures require a dereference of function pointers (See powerpc). The dereferenced poiner must be saved into the buffer in vbin_printf() to be safe to access it later. Cc: Frederic Weisbecker Cc: Jiri Olsa

[RFC][PATCH 2/3] vsprintf: Add support for %pf and %pF to vbin_printf()

From: "Steven Rostedt (Red Hat)" Some architectures require a dereference of function pointers (See powerpc). The dereferenced poiner must be saved into the buffer in vbin_printf() to be safe to access it later. Cc: Frederic Weisbecker Cc: Jiri Olsa Signed-off-by: Steven Rostedt ---

Re: [RFC 1/7] net: ethernet: bgmac: change bgmac_* prints to dev_* prints

On Tue, Jun 28, 2016 at 3:43 PM, Joe Perches wrote: > On Tue, 2016-06-28 at 15:34 -0400, Jon Mason wrote: >> The bgmac_* print wrappers call dev_* prints with the dev pointer from >> the bcma core. In anticipation of removing the bcma requirement for >> this driver, these must

Re: [RFC 1/7] net: ethernet: bgmac: change bgmac_* prints to dev_* prints

On Tue, Jun 28, 2016 at 3:43 PM, Joe Perches wrote: > On Tue, 2016-06-28 at 15:34 -0400, Jon Mason wrote: >> The bgmac_* print wrappers call dev_* prints with the dev pointer from >> the bcma core. In anticipation of removing the bcma requirement for >> this driver, these must be changed to not

Re: [x86/KASLR] ed9f007ee6: -- System halted

On Tue, Jun 28, 2016 at 12:49 PM, Yinghai Lu wrote: > On Mon, Jun 27, 2016 at 10:43 PM, Ye Xiaolong wrote: >> On Mon, Jun 27, 2016 at 11:59:37AM -0700, Yinghai Lu wrote: >>>output is: >>> >>>early console in setup code >>>early console in extract_kernel

Re: [x86/KASLR] ed9f007ee6: -- System halted

On Tue, Jun 28, 2016 at 12:49 PM, Yinghai Lu wrote: > On Mon, Jun 27, 2016 at 10:43 PM, Ye Xiaolong wrote: >> On Mon, Jun 27, 2016 at 11:59:37AM -0700, Yinghai Lu wrote: >>>output is: >>> >>>early console in setup code >>>early console in extract_kernel >>>input_data: 0x08fbb276

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: >> On 06/29/2016 07:13 AM, Andrew Lunn wrote: >> > Hi Jon >> > >> > I know you are just refactoring code, but at some point it would be >> > good to take a

Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On Wed, Jun 29, 2016 at 2:46 PM, Andrew Lunn wrote: > On Wed, Jun 29, 2016 at 11:35:28AM -0700, Florian Fainelli wrote: >> On 06/29/2016 07:13 AM, Andrew Lunn wrote: >> > Hi Jon >> > >> > I know you are just refactoring code, but at some point it would be >> > good to take a closer look at this

[PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

From: Huang Ying ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for

[PATCH] acpi, apei: Add Boot Error Record Table (BERT) support

From: Huang Ying ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 12:46:35PM -0700, Greg KH wrote: > On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: > > On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: > > > copyleft-next [0] [1] is an openly evolved copyleft license, its an > > > effort to evolve

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 12:46:35PM -0700, Greg KH wrote: > On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: > > On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: > > > copyleft-next [0] [1] is an openly evolved copyleft license, its an > > > effort to evolve

Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Tue, 28 Jun 2016 13:47:23 -0600 Alex Williamson wrote: > On Tue, 28 Jun 2016 18:09:46 +0800 > Yongji Xie wrote: > > > Hi, Alex > > > > On 2016/6/25 0:43, Alex Williamson wrote: > > > > > On Fri, 24 Jun 2016 23:37:02 +0800 > > >

Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On Tue, 28 Jun 2016 13:47:23 -0600 Alex Williamson wrote: > On Tue, 28 Jun 2016 18:09:46 +0800 > Yongji Xie wrote: > > > Hi, Alex > > > > On 2016/6/25 0:43, Alex Williamson wrote: > > > > > On Fri, 24 Jun 2016 23:37:02 +0800 > > > Yongji Xie wrote: > > > > > >> Hi, Alex > > >> > > >>

[PATCH 3/3] x86, cpufeatures: add helper macro for mask check macros

From: Dave Hansen Every time we add a word to our cpu features, we need to add something like this in two places: (((bit)>>5)==16 && (1UL<<((bit)&31) & REQUIRED_MASK16)) The trick is getting the "16" in this case in both places. I've now screwed this up

[PATCH 1/3] x86, cpufeatures: update cpufeaure macros

From: Dave Hansen We had a new CPUID "NCAPINT" word added, but the REQUIRED_MASK and DISABLED_MASK macros did not get updated. Update them. None of the features was needed in these masks, so there was no harm, but we should keep them updated anyway.

[PATCH 3/3] x86, cpufeatures: add helper macro for mask check macros

From: Dave Hansen Every time we add a word to our cpu features, we need to add something like this in two places: (((bit)>>5)==16 && (1UL<<((bit)&31) & REQUIRED_MASK16)) The trick is getting the "16" in this case in both places. I've now screwed this up twice, so as pennance, I've

[PATCH 1/3] x86, cpufeatures: update cpufeaure macros

From: Dave Hansen We had a new CPUID "NCAPINT" word added, but the REQUIRED_MASK and DISABLED_MASK macros did not get updated. Update them. None of the features was needed in these masks, so there was no harm, but we should keep them updated anyway. Signed-off-by: Dave Hansen ---

[PATCH 2/3] x86, cpufeatures: make sure DISABLED/REQUIRED macros are updated

From: Dave Hansen x86 has two macros which allow us to evaluate some CPUID-based features at compile time: REQUIRED_MASK_BIT_SET() DISABLED_MASK_BIT_SET() They're both defined by having the compiler check the bit argument against some constant

[PATCH 2/3] x86, cpufeatures: make sure DISABLED/REQUIRED macros are updated

From: Dave Hansen x86 has two macros which allow us to evaluate some CPUID-based features at compile time: REQUIRED_MASK_BIT_SET() DISABLED_MASK_BIT_SET() They're both defined by having the compiler check the bit argument against some constant masks of features. But, when

Re: [PATCH 0/2] brcmfmac: support removing AP interfaces with new fw

On 29 June 2016 at 21:54, Rafał Miłecki wrote: > This is the latest patchset needed to get brcmfmac working reasonably well > with BCM4366. > > Both patches were already sent as V2 RFC (10 days ago), there were no more > comments since then and this is the same code as in V2

Re: [PATCH 0/2] brcmfmac: support removing AP interfaces with new fw

On 29 June 2016 at 21:54, Rafał Miłecki wrote: > This is the latest patchset needed to get brcmfmac working reasonably well > with BCM4366. > > Both patches were already sent as V2 RFC (10 days ago), there were no more > comments since then and this is the same code as in V2 RFC. I was mostly >

[PATCH 1/2] brcmfmac: delete interface directly in code that sent fw request

So far when receiving event about in-firmware-interface removal our event worker was notifying listener and afterwards it was removing Linux interface. First of all it was resulting in slightly unexpected order. The listener (del_virtual_intf callback) was (usually) returning with success before

[PATCH 1/2] brcmfmac: delete interface directly in code that sent fw request

So far when receiving event about in-firmware-interface removal our event worker was notifying listener and afterwards it was removing Linux interface. First of all it was resulting in slightly unexpected order. The listener (del_virtual_intf callback) was (usually) returning with success before

[PATCH 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove" for removing interfaces. Try to use this method on cfg80211 request. In case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this will just result in firmware rejecting command and this won't change any

[PATCH 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove" for removing interfaces. Try to use this method on cfg80211 request. In case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this will just result in firmware rejecting command and this won't change any

Re: [PATCH 1/6] [media] s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver doesn't set the struct v4l2_capability bus_info field so the > v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: > > Required ioctls: > VIDIOC_QUERYCAP returned 0 (Success) >

Re: [PATCH 1/6] [media] s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver doesn't set the struct v4l2_capability bus_info field so the > v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: > > Required ioctls: > VIDIOC_QUERYCAP returned 0 (Success) >

Re: [PATCH 2/2] arm64: Always provide compat /proc/cpuinfo for 32-bit tasks

Hi all, On Tue, May 31, 2016 at 03:55:04PM +0100, Catalin Marinas wrote: > Currently, the compat /proc/cpuinfo is provided only if a task has the > PER_LINUX32 personality, either by setting it explicitly or by > inheriting it from the parent task. This is in line with the "uname -m" > behaviour.

[PATCH] arm64: Add Broadcom Set Top Box Kconfig entry point

From: Florian Fainelli Add an ARCH_BRCMSTB Kconfig symbol which allows us not to update the dependencies for all STB-related drivers. Select BRCMSTB_L2_IRQ and GENERIC_IRQ_CHIP which are required for proper functioning. Signed-off-by: Doug Berger

Re: [PATCH 2/2] arm64: Always provide compat /proc/cpuinfo for 32-bit tasks

Hi all, On Tue, May 31, 2016 at 03:55:04PM +0100, Catalin Marinas wrote: > Currently, the compat /proc/cpuinfo is provided only if a task has the > PER_LINUX32 personality, either by setting it explicitly or by > inheriting it from the parent task. This is in line with the "uname -m" > behaviour.

[PATCH] arm64: Add Broadcom Set Top Box Kconfig entry point

From: Florian Fainelli Add an ARCH_BRCMSTB Kconfig symbol which allows us not to update the dependencies for all STB-related drivers. Select BRCMSTB_L2_IRQ and GENERIC_IRQ_CHIP which are required for proper functioning. Signed-off-by: Doug Berger Signed-off-by: Florian Fainelli Signed-off-by:

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > > On 06/27/16 at 04:21pm, Dave Young wrote: > > > Please ignore previous reply, I mistakenly send a broken mail without > > > subject, sorry about it. Resend the reply here. > > > > >

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > > On 06/27/16 at 04:21pm, Dave Young wrote: > > > Please ignore previous reply, I mistakenly send a broken mail without > > > subject, sorry about it. Resend the reply here. > > > > >

Re: [PATCH 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG in FS mode with internal PHY

On Mon, Jun 27, 2016 at 7:51 PM, John Youn wrote: > On 6/21/2016 7:26 PM, Bruno Herrera wrote: >> Signed-off-by: Bruno Herrera > > Please add a commit message describing the purpose of your changes, > some information about the platform you're

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

On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > Am Donnerstag, 23 Juni 2016, 10:25:06 schrieb Dave Young: > > On 06/22/16 at 08:30pm, Thiago Jung Bauermann wrote: > > > Am Mittwoch, 22 Juni 2016, 18:20:47 schrieb Dave Young: > > > > The patch looks good, but could the subject be more

Re: [PATCH 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG in FS mode with internal PHY

On Mon, Jun 27, 2016 at 7:51 PM, John Youn wrote: > On 6/21/2016 7:26 PM, Bruno Herrera wrote: >> Signed-off-by: Bruno Herrera > > Please add a commit message describing the purpose of your changes, > some information about the platform you're adding, and the special > handling of the GGPIO. >

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

On 06/28/16 at 07:18pm, Thiago Jung Bauermann wrote: > Am Donnerstag, 23 Juni 2016, 10:25:06 schrieb Dave Young: > > On 06/22/16 at 08:30pm, Thiago Jung Bauermann wrote: > > > Am Mittwoch, 22 Juni 2016, 18:20:47 schrieb Dave Young: > > > > The patch looks good, but could the subject be more

Re: [Y2038] [PATCH v3 00/24] Delete CURRENT_TIME_SEC and replace current_fs_time()

On Saturday, June 25, 2016 2:37:24 PM CEST Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME, CURRENT_TIME_SEC macros > and replacing current_fs_time() with current_time(). > The macros are not y2038 safe. There is no plan to transition them into being > y2038 safe. >

Re: [Y2038] [PATCH v3 00/24] Delete CURRENT_TIME_SEC and replace current_fs_time()

On Saturday, June 25, 2016 2:37:24 PM CEST Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME, CURRENT_TIME_SEC macros > and replacing current_fs_time() with current_time(). > The macros are not y2038 safe. There is no plan to transition them into being > y2038 safe. >

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: > On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: > > copyleft-next [0] [1] is an openly evolved copyleft license, its an > > effort to evolve copyleft without participation of the Church (TM) > > or State (R),

Re: [PATCH 2/6] [media] s5p-mfc: improve v4l2_capability driver and card fields

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > According to the V4L2 documentation the driver and card fields should be > used to identify the driver and the device but the s5p-mfc driver fills > those field using the platform device name, which in turn is the name of > the device DT

Re: [PATCH] module.h: add copyleft-next >= 0.3.1 as GPL compatible

On Wed, Jun 29, 2016 at 09:05:47PM +0200, Luis R. Rodriguez wrote: > On Tue, Jun 14, 2016 at 11:35:11AM -0700, Luis R. Rodriguez wrote: > > copyleft-next [0] [1] is an openly evolved copyleft license, its an > > effort to evolve copyleft without participation of the Church (TM) > > or State (R),

Re: [PATCH 2/6] [media] s5p-mfc: improve v4l2_capability driver and card fields

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > According to the V4L2 documentation the driver and card fields should be > used to identify the driver and the device but the s5p-mfc driver fills > those field using the platform device name, which in turn is the name of > the device DT

Re: [PATCH 3/6] [media] s5p-jpeg: set capablity bus_info as required by VIDIOC_QUERYCAP

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver doesn't set the struct v4l2_capability cap_info field so the > v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: > > Required ioctls: > VIDIOC_QUERYCAP returned 0 (Success) >

Re: [PATCH 4/6] [media] s5p-jpeg: only fill driver's name in capabilities driver field

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver fills in both the struct v4l2_capability driver and card fields > the same values, that is the driver's name plus the information if the dev > is a decoder or an encoder. > > But the driver field has a fixed length of 16 bytes

Re: [PATCH 3/6] [media] s5p-jpeg: set capablity bus_info as required by VIDIOC_QUERYCAP

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver doesn't set the struct v4l2_capability cap_info field so the > v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: > > Required ioctls: > VIDIOC_QUERYCAP returned 0 (Success) >

Re: [PATCH 4/6] [media] s5p-jpeg: only fill driver's name in capabilities driver field

On 06/16/2016 03:40 PM, Javier Martinez Canillas wrote: > The driver fills in both the struct v4l2_capability driver and card fields > the same values, that is the driver's name plus the information if the dev > is a decoder or an encoder. > > But the driver field has a fixed length of 16 bytes

Re: [tip:perf/core] perf/x86/intel: Add {rd,wr}lbr_{to,from} wrappers

On Mon, Jun 27, 2016 at 05:56:02AM -0700, tip-bot for Peter Zijlstra wrote: > +static inline u64 rdlbr_from(unsigned int idx) > +{ > + u64 val; > + > + rdmsrl(x86_pmu.lbr_from + idx, val); > + > + return lbr_from_signext_quirk_rd(val); > +} > + > +static inline u64 rdlbr_to(unsigned

Re: [tip:perf/core] perf/x86/intel: Add {rd,wr}lbr_{to,from} wrappers

On Mon, Jun 27, 2016 at 05:56:02AM -0700, tip-bot for Peter Zijlstra wrote: > +static inline u64 rdlbr_from(unsigned int idx) > +{ > + u64 val; > + > + rdmsrl(x86_pmu.lbr_from + idx, val); > + > + return lbr_from_signext_quirk_rd(val); > +} > + > +static inline u64 rdlbr_to(unsigned

[PATCH] staging: comedi: daqboard2000: bug fix board type matching code

`daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the

[PATCH] staging: comedi: daqboard2000: bug fix board type matching code

`daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the

[PATCH] x86: rename "WESTMERE2" family to "NEHALEM_G"

From: Dave Hansen Len Brown noticed something was amiss in our INTEL_FAM6_* definitions. It seems like model 0x1F was a Nehalem part, marketed as "Intel Core i7 and i5 Processors" (according to the SDM). But, although it was a Nehalem 0x1F had some uncore events

[PATCH] x86: rename "WESTMERE2" family to "NEHALEM_G"

From: Dave Hansen Len Brown noticed something was amiss in our INTEL_FAM6_* definitions. It seems like model 0x1F was a Nehalem part, marketed as "Intel Core i7 and i5 Processors" (according to the SDM). But, although it was a Nehalem 0x1F had some uncore events which were shared with

Re: [Cocci] [PATCH] Coccinelle: Script to replace NULL test with IS_ERR test for devm_ioremap_resource

On Thu, Jun 30, 2016 at 12:03:47AM +0530, Amitoj Kaur Chawla wrote: > This script detects cases which have incorrect error handling for > devm_ioremap_resource function, employing a NULL test instead of an > IS_ERR() test. > > Signed-off-by: Amitoj Kaur Chawla Why don't we

Re: [Cocci] [PATCH] Coccinelle: Script to replace NULL test with IS_ERR test for devm_ioremap_resource

On Thu, Jun 30, 2016 at 12:03:47AM +0530, Amitoj Kaur Chawla wrote: > This script detects cases which have incorrect error handling for > devm_ioremap_resource function, employing a NULL test instead of an > IS_ERR() test. > > Signed-off-by: Amitoj Kaur Chawla Why don't we fix the code at the

Re: [PATCH] mmotm: mm-oom-fortify-task_will_free_mem-fix

On 06/29, Michal Hocko wrote: > > But it seems that further changes I am > planning in this area will benefit from stable task->mm in this path Oh, so I hope you will cleanup this later, > Just pull the task->mm != > NULL check inside the function. OK, but this means it will always return false

Re: [PATCH] mmotm: mm-oom-fortify-task_will_free_mem-fix

On 06/29, Michal Hocko wrote: > > But it seems that further changes I am > planning in this area will benefit from stable task->mm in this path Oh, so I hope you will cleanup this later, > Just pull the task->mm != > NULL check inside the function. OK, but this means it will always return false

Re: [GIT PULL] (Xen) stable/for-jens-4.7 for v4.7-rc5

On 06/29/2016 10:39 AM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the 'stable/for-jens-4.7' branch which is based on your 'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

Re: [GIT PULL] (Xen) stable/for-jens-4.7 for v4.7-rc5

On 06/29/2016 10:39 AM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the 'stable/for-jens-4.7' branch which is based on your 'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

[PATCH v3 12/14] clk: sunxi-ng: Add N-K-M-P factor clock

Introduce support for clocks that use a combination of two linear multipliers (N and K factors), one linear divider (M) and one power of two divider (P). Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig| 5 ++ drivers/clk/sunxi-ng/Makefile

[PATCH v3 12/14] clk: sunxi-ng: Add N-K-M-P factor clock

Introduce support for clocks that use a combination of two linear multipliers (N and K factors), one linear divider (M) and one power of two divider (P). Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig| 5 ++ drivers/clk/sunxi-ng/Makefile | 1 +

Re: [PATCH v1 1/2] Add the initify gcc plugin

On Tue, 28 Jun 2016 23:05:56 +0200 Rasmus Villemoes wrote: > On Tue, Jun 28 2016, Emese Revfy wrote: > > > The kernel already has a mechanism to free up code and data memory that > > is only used during kernel or module initialization. > > This

[PATCH v3 05/14] clk: sunxi-ng: Add mux clock support

Some clocks in the Allwinner SoCs clocks unit are just muxes. However, those muxes might also be found in some other complicated clocks that would benefit from the code in there to deal with "advanced" features, like pre-dividers. Introduce a set of helpers to reduce the code duplication in such

[PATCH v3 02/14] clk: sunxi-ng: Add common infrastructure

Start our new clock infrastructure by adding the registration code, common structure and common code. Signed-off-by: Maxime Ripard --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/sunxi-ng/Kconfig | 3 ++

[PATCH v3 11/14] clk: sunxi-ng: Add N-K-M Factor clock

Introduce support for clocks that multiply and divide using two linear multipliers and one linear divider. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig | 5 ++ drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_nkm.c | 153

Re: [PATCH v1 1/2] Add the initify gcc plugin

On Tue, 28 Jun 2016 23:05:56 +0200 Rasmus Villemoes wrote: > On Tue, Jun 28 2016, Emese Revfy wrote: > > > The kernel already has a mechanism to free up code and data memory that > > is only used during kernel or module initialization. > > This plugin will teach the compiler to find more such

[PATCH v3 05/14] clk: sunxi-ng: Add mux clock support

Some clocks in the Allwinner SoCs clocks unit are just muxes. However, those muxes might also be found in some other complicated clocks that would benefit from the code in there to deal with "advanced" features, like pre-dividers. Introduce a set of helpers to reduce the code duplication in such

[PATCH v3 02/14] clk: sunxi-ng: Add common infrastructure

Start our new clock infrastructure by adding the registration code, common structure and common code. Signed-off-by: Maxime Ripard --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/sunxi-ng/Kconfig | 3 ++ drivers/clk/sunxi-ng/Makefile

[PATCH v3 11/14] clk: sunxi-ng: Add N-K-M Factor clock

Introduce support for clocks that multiply and divide using two linear multipliers and one linear divider. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig | 5 ++ drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_nkm.c | 153

[PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

setup_new_dl_entity() takes two parameters, but it only actually uses one of them, under a different name, to setup a new dl_entity, after: 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity" as we currently do setup_new_dl_entity(>dl, >dl) However, before Luca's change

[PATCH v3 06/14] clk: sunxi-ng: Add phase clock support

Add support for the clocks in the CCU that introduce a phase shift from their parent clock. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig | 3 + drivers/clk/sunxi-ng/Makefile| 1 + drivers/clk/sunxi-ng/ccu_phase.c | 126

[PATCH v3 01/14] dt-bindings: sunxi: Add CCU binding documentation

Introduce a new binding with its documentation for the brand new clock sub-framework. Signed-off-by: Maxime Ripard --- .../devicetree/bindings/clock/sunxi-ccu.txt| 24 ++ 1 file changed, 24 insertions(+) create mode 100644

[PATCH v3 00/14] clk: sunxi: introduce "modern" clock support

Hi, This is the third attempt at introducing clock support for the Allwinner SoCs following the current model used by pretty much all the other SoCs. Such a conversion has been suggested on a regular basis by Mike and Stephen, and here is a first implementation. This new approach has a good

[PATCH v3 04/14] clk: sunxi-ng: Add gate clock support

Some clocks in the Allwinner SoCs clocks unit are just simple gates. Add support for those clocks. Since it's a feature that can also be found in more complex clocks, provide a bunch of helpers that can be reused later on. Signed-off-by: Maxime Ripard ---

[PATCH v3 03/14] clk: sunxi-ng: Add fractional lib

Some clocks can be switched to a mode called fractional that have two fixed output rate you can choose from. Add a small library to deal with those clocks. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig| 9

[PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

setup_new_dl_entity() takes two parameters, but it only actually uses one of them, under a different name, to setup a new dl_entity, after: 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity" as we currently do setup_new_dl_entity(>dl, >dl) However, before Luca's change

[PATCH v3 06/14] clk: sunxi-ng: Add phase clock support

Add support for the clocks in the CCU that introduce a phase shift from their parent clock. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Kconfig | 3 + drivers/clk/sunxi-ng/Makefile| 1 + drivers/clk/sunxi-ng/ccu_phase.c | 126 +++

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