On Thu, Aug 25, 2016 at 09:40:12PM -0700, Linus Torvalds wrote:
> On Thu, Aug 25, 2016 at 8:19 PM, Josh Poimboeuf wrote:
> > So yes, dmesg_restrict sounds useful to me. It's a way to prevent users
> > from seeing kernel addresses without affecting my ability to debug
> >
On Thu, Aug 25, 2016 at 09:40:12PM -0700, Linus Torvalds wrote:
> On Thu, Aug 25, 2016 at 8:19 PM, Josh Poimboeuf wrote:
> > So yes, dmesg_restrict sounds useful to me. It's a way to prevent users
> > from seeing kernel addresses without affecting my ability to debug
> > issues. For a locked
On Thu, Aug 25, 2016 at 9:31 PM, Damien Le Moal wrote:
>
> Shaun,
>
> On 8/25/16 05:24, Shaun Tancheff wrote:
>>
>> (RESENDING to include f2fs, fs-devel and dm-devel)
>>
>> Add op flags to access to zone information as well as open, close
>> and reset zones:
>> -
On Thu, Aug 25, 2016 at 9:31 PM, Damien Le Moal wrote:
>
> Shaun,
>
> On 8/25/16 05:24, Shaun Tancheff wrote:
>>
>> (RESENDING to include f2fs, fs-devel and dm-devel)
>>
>> Add op flags to access to zone information as well as open, close
>> and reset zones:
>> - REQ_OP_ZONE_REPORT - Query zone
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
crashkernel has been reserved successfully.
Aug 25 10:36:44 dut4062 kernel: Reserving 512MB of memory at 368MB for
crashkernel (System RAM: 130847MB)
So what's the result of executing "grep Crash /porc/iomem" on your
system?
>
> On 8/25/16,
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
crashkernel has been reserved successfully.
Aug 25 10:36:44 dut4062 kernel: Reserving 512MB of memory at 368MB for
crashkernel (System RAM: 130847MB)
So what's the result of executing "grep Crash /porc/iomem" on your
system?
>
> On 8/25/16,
Hello Scott,
thanks for the fast reply!
On 2016-08-24 23:39, Scott Wood wrote:
[..]
The second inbound window is at 256G, and it maps all of RAM. Note
that
for accesses in this window, the PCI address is different from the host
address.
I probably really misunderstand the manual here ...
Hello Scott,
thanks for the fast reply!
On 2016-08-24 23:39, Scott Wood wrote:
[..]
The second inbound window is at 256G, and it maps all of RAM. Note
that
for accesses in this window, the PCI address is different from the host
address.
I probably really misunderstand the manual here ...
On 26 August 2016 at 07:19, Masami Hiramatsu wrote:
> On Wed, 24 Aug 2016 16:47:28 +0530
>> "__local_bh_enable() tests if this is the last SOFTIRQ_OFFSET, if so it
>> tells lockdep softirqs are enabled with trace_softirqs_on() after that
>> we go an actually modify the
On 26 August 2016 at 07:19, Masami Hiramatsu wrote:
> On Wed, 24 Aug 2016 16:47:28 +0530
>> "__local_bh_enable() tests if this is the last SOFTIRQ_OFFSET, if so it
>> tells lockdep softirqs are enabled with trace_softirqs_on() after that
>> we go an actually modify the preempt_count with
The 2nd parameter of 'find_first_bit' is the number of bits to search.
In this case, we are passing 'sizeof(tmp)' which is likely to be 4 or 8
because 'tmp' is an 'unsigned long'.
It is likely that the number of bits of 'tmp' was expected here. So use
BITS_PER_LONG instead.
It has been spotted
The 2nd parameter of 'find_first_bit' is the number of bits to search.
In this case, we are passing 'sizeof(tmp)' which is likely to be 4 or 8
because 'tmp' is an 'unsigned long'.
It is likely that the number of bits of 'tmp' was expected here. So use
BITS_PER_LONG instead.
It has been spotted
> "Shawn" == Shawn Lin writes:
Shawn> We don't need to use kzalloc as we will always memset the
Shawn> local_atto_ioctl later.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
> "Shawn" == Shawn Lin writes:
Shawn> We don't need to use kzalloc as we will always memset the
Shawn> local_atto_ioctl later.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Best Regards!
Anson Huang
> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: 2016-08-25 3:09 PM
> To: Yongcai Huang
> Cc: linux-arm-ker...@lists.infradead.org; lkml ;
> Fabio Estevam
Best Regards!
Anson Huang
> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: 2016-08-25 3:09 PM
> To: Yongcai Huang
> Cc: linux-arm-ker...@lists.infradead.org; lkml ;
> Fabio Estevam ; shawn...@kernel.org;
> li...@armlinux.org.uk; ker...@pengutronix.de
>
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
>
> On 8/25/16, 1:10 AM, "Michal Hocko" wrote:
>
> >[Let's add kdump people]
> >
> >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote:
> >> Hello list,
> >>
> >> I am wondering if anybody has issue capturing crash dump with
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
>
> On 8/25/16, 1:10 AM, "Michal Hocko" wrote:
>
> >[Let's add kdump people]
> >
> >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote:
> >> Hello list,
> >>
> >> I am wondering if anybody has issue capturing crash dump with the 4.6.0
> >> and
>-Original Message-
>From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
>Sent: Sunday, August 21, 2016 1:58 PM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc:
>-Original Message-
>From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
>Sent: Sunday, August 21, 2016 1:58 PM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc:
2016-08-24 21:54 GMT+02:00 Mirza Krak :
> 2016-08-24 17:56 GMT+02:00 Jon Hunter :
> +
>>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap
>>> the
>>> +controllers with a simple-bus node since they are all connected to the
2016-08-24 21:54 GMT+02:00 Mirza Krak :
> 2016-08-24 17:56 GMT+02:00 Jon Hunter :
> +
>>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap
>>> the
>>> +controllers with a simple-bus node since they are all connected to the same
>>> +chip-select (CS4), in this example
In all other places in this file where 'find_first_bit' is called,
port_num is defined as a 'u8' and no casting is done.
Do the same here in order to be more consistent.
Signed-off-by: Christophe JAILLET
---
drivers/infiniband/hw/hfi1/mad.c | 4 ++--
1 file
Hi Daniel,
On Wed, Aug 24, 2016 at 06:00:51PM -0400, Daniel P. Berrange wrote:
>
> > diff --git a/hw/virtio/virtio-pstore.c b/hw/virtio/virtio-pstore.c
> > new file mode 100644
> > index 000..b8fb4be
> > --- /dev/null
> > +++ b/hw/virtio/virtio-pstore.c
> > @@ -0,0 +1,699 @@
> > +/*
> > + *
On Tue, Aug 23, 2016 at 10:18 PM, wrote:
> From: Gao Feng
>
> When rhashtable_walk_start returns -EAGAIN, it means the resize event
> happened but the iterator still could be used. So it should not be
> treated as an error in gfs2_glock_seq_start.
>
>
In all other places in this file where 'find_first_bit' is called,
port_num is defined as a 'u8' and no casting is done.
Do the same here in order to be more consistent.
Signed-off-by: Christophe JAILLET
---
drivers/infiniband/hw/hfi1/mad.c | 4 ++--
1 file changed, 2 insertions(+), 2
Hi Daniel,
On Wed, Aug 24, 2016 at 06:00:51PM -0400, Daniel P. Berrange wrote:
>
> > diff --git a/hw/virtio/virtio-pstore.c b/hw/virtio/virtio-pstore.c
> > new file mode 100644
> > index 000..b8fb4be
> > --- /dev/null
> > +++ b/hw/virtio/virtio-pstore.c
> > @@ -0,0 +1,699 @@
> > +/*
> > + *
On Tue, Aug 23, 2016 at 10:18 PM, wrote:
> From: Gao Feng
>
> When rhashtable_walk_start returns -EAGAIN, it means the resize event
> happened but the iterator still could be used. So it should not be
> treated as an error in gfs2_glock_seq_start.
>
> Signed-off-by: Gao Feng
> ---
>
The 2nd parameter of 'find_first_bit' is the number of bits to search.
In this case, we are passing 'sizeof(unsigned long)' which is likely to
be 4 or 8.
It is likely that the number of bits of 'port_mask' was expected here. This
variable is a 'u64', so use 64 instead.
It has been spotted by the
The 2nd parameter of 'find_first_bit' is the number of bits to search.
In this case, we are passing 'sizeof(unsigned long)' which is likely to
be 4 or 8.
It is likely that the number of bits of 'port_mask' was expected here. This
variable is a 'u64', so use 64 instead.
It has been spotted by the
Hi,
[no properly binding reference via In-Reply-To: available thus manually
re-creating, sorry]
> +++ b/include/linux/sched/deadline.h
> @@ -1,13 +1,7 @@
> #ifndef _SCHED_DEADLINE_H
> #define _SCHED_DEADLINE_H
>
> -/*
> - * SCHED_DEADLINE tasks has negative priorities, reflecting
> - * the
Hi,
[no properly binding reference via In-Reply-To: available thus manually
re-creating, sorry]
> +++ b/include/linux/sched/deadline.h
> @@ -1,13 +1,7 @@
> #ifndef _SCHED_DEADLINE_H
> #define _SCHED_DEADLINE_H
>
> -/*
> - * SCHED_DEADLINE tasks has negative priorities, reflecting
> - * the
On Thu, Aug 25, 2016 at 8:19 PM, Josh Poimboeuf wrote:
> For an oops, there are other opportunities for address leakage besides
> the stack trace function addresses. There's the raw stack dump which
> dumps the first 12 stack entries. And there's the register dump. I'm
>
On Thu, Aug 25, 2016 at 8:19 PM, Josh Poimboeuf wrote:
> For an oops, there are other opportunities for address leakage besides
> the stack trace function addresses. There's the raw stack dump which
> dumps the first 12 stack entries. And there's the register dump. I'm
> pretty sure we don't
Le 24/08/2016 à 07:14, Christophe Leroy a écrit :
>
>
> Le 23/08/2016 à 21:03, Florian Fainelli a écrit :
>> +others,
>>
>> On 08/23/2016 04:13 AM, Christophe Leroy wrote:
>>> In ERRATA DS8700A dated 05 May 2016, Microship recommends to
>>> not use software power down mode on KSZ8041 family.
Le 24/08/2016 à 07:14, Christophe Leroy a écrit :
>
>
> Le 23/08/2016 à 21:03, Florian Fainelli a écrit :
>> +others,
>>
>> On 08/23/2016 04:13 AM, Christophe Leroy wrote:
>>> In ERRATA DS8700A dated 05 May 2016, Microship recommends to
>>> not use software power down mode on KSZ8041 family.
> "Shawn" == Shawn Lin writes:
Shawn> req_table is allocate by kzalloc, so we don't need to zero it
Shawn> again anyway.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
> "Shawn" == Shawn Lin writes:
Shawn> req_table is allocate by kzalloc, so we don't need to zero it
Shawn> again anyway.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
On Thu, Aug 25, 2016 at 10:50:18PM +0530, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 06:31 PM, Peter Zijlstra wrote:
> >On Thu, Aug 25, 2016 at 05:27:54PM +0530, Hari Bathini wrote:
> >
> >>diff --git a/include/uapi/linux/perf_event.h
> >>b/include/uapi/linux/perf_event.h
> >>index
On Thu, Aug 25, 2016 at 10:50:18PM +0530, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 06:31 PM, Peter Zijlstra wrote:
> >On Thu, Aug 25, 2016 at 05:27:54PM +0530, Hari Bathini wrote:
> >
> >>diff --git a/include/uapi/linux/perf_event.h
> >>b/include/uapi/linux/perf_event.h
> >>index
On 2016-08-25 18:19, Wolfram Sang wrote:
>
>> diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
>> b/drivers/i2c/muxes/i2c-mux-pca9541.c
>> index 3cb8af635db5..f052c3067791 100644
>> --- a/drivers/i2c/muxes/i2c-mux-pca9541.c
>> +++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
>> @@ -349,7 +349,8 @@
On 2016-08-25 18:19, Wolfram Sang wrote:
>
>> diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
>> b/drivers/i2c/muxes/i2c-mux-pca9541.c
>> index 3cb8af635db5..f052c3067791 100644
>> --- a/drivers/i2c/muxes/i2c-mux-pca9541.c
>> +++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
>> @@ -349,7 +349,8 @@
i.MX7D has 2 cortex-a7 ARM core, add support for
booting up SMP kernel with 2 CPUs.
The existing i.MX SMP code is designed for i.MX6
series SoCs which have cortex-a9 ARM core, but i.MX7D
has 2 cortex-a7 ARM core, so we need to add runtime
check for those differences between cortex-a9 and
i.MX7D has 2 cortex-a7 ARM core, add support for
booting up SMP kernel with 2 CPUs.
The existing i.MX SMP code is designed for i.MX6
series SoCs which have cortex-a9 ARM core, but i.MX7D
has 2 cortex-a7 ARM core, so we need to add runtime
check for those differences between cortex-a9 and
On Mon, 22 Aug 2016 20:47:58 +1000
Nicholas Piggin wrote:
> On Fri, 19 Aug 2016 20:44:55 +1000
> Nicholas Piggin wrote:
>
> > On Fri, 19 Aug 2016 10:37:00 +0200
> > Michal Marek wrote:
> >
> > > On 2016-08-19 07:09, Stephen Rothwell
On Mon, 22 Aug 2016 20:47:58 +1000
Nicholas Piggin wrote:
> On Fri, 19 Aug 2016 20:44:55 +1000
> Nicholas Piggin wrote:
>
> > On Fri, 19 Aug 2016 10:37:00 +0200
> > Michal Marek wrote:
> >
> > > On 2016-08-19 07:09, Stephen Rothwell wrote:
>
> [snip]
>
> > > >
> > > > I may be
This patch adds GPC module, i.MX7 has a different
design of GPC module from i.MX6, so we call it GPCV2,
booting up secondary CPUs needs to access GPCV2
to enable secondary CPUs' power.
Also, adds "arm,cpu-registers-not-fw-configured"
property, interrupt parent and clock rate to
arch timer.
This patch adds GPC module, i.MX7 has a different
design of GPC module from i.MX6, so we call it GPCV2,
booting up secondary CPUs needs to access GPCV2
to enable secondary CPUs' power.
Also, adds "arm,cpu-registers-not-fw-configured"
property, interrupt parent and clock rate to
arch timer.
On Thu, Aug 25, 2016 at 10:14:36PM -0400, Kees Cook wrote:
> On Thu, Aug 25, 2016 at 4:47 PM, Josh Poimboeuf wrote:
> > On Tue, Aug 23, 2016 at 10:37:43PM -0400, Kees Cook wrote:
> >> On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf
> >> wrote:
> >> >
On Thu, Aug 25, 2016 at 10:14:36PM -0400, Kees Cook wrote:
> On Thu, Aug 25, 2016 at 4:47 PM, Josh Poimboeuf wrote:
> > On Tue, Aug 23, 2016 at 10:37:43PM -0400, Kees Cook wrote:
> >> On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf
> >> wrote:
> >> > This is a revert of:
> >> >
> >> >
This makes it trivial to constify them, so do that.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_dp_helper.c | 10 +++---
drivers/i2c/i2c-core.c | 13 -
drivers/i2c/i2c-mux.c | 25 -
include/linux/i2c.h
This makes it trivial to constify them, so do that.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_dp_helper.c | 10 +++---
drivers/i2c/i2c-core.c | 13 -
drivers/i2c/i2c-mux.c | 25 -
include/linux/i2c.h | 25
Hello,
On Thu, Aug 25, 2016 at 04:11:47PM +0300, Yauheni Kaliuta wrote:
> Hi, Jiri!
>
> > On Thu, 25 Aug 2016 14:02:50 +0200, Jiri Olsa wrote:
>
> [...]
>
> > Now here's where I got confused.. please continue reading only on your
> own risk ;-)
>
> > The uprobe_events shows following
Hello,
On Thu, Aug 25, 2016 at 04:11:47PM +0300, Yauheni Kaliuta wrote:
> Hi, Jiri!
>
> > On Thu, 25 Aug 2016 14:02:50 +0200, Jiri Olsa wrote:
>
> [...]
>
> > Now here's where I got confused.. please continue reading only on your
> own risk ;-)
>
> > The uprobe_events shows following
i.MX7D has 2 Cortex-A7 ARM cores, and it has a different GPC design
than i.MX6, so this patch set adds a new GPCV2 driver for i.MX7D,
and also adds runtime check in SMP code to support both Cortex-A9
and Cortex-A7 ARM cores.
With this patch set, i.MX7D can boot up SMP kernel with 2 CPUs.
Anson
i.MX7D has 2 Cortex-A7 ARM cores, and it has a different GPC design
than i.MX6, so this patch set adds a new GPCV2 driver for i.MX7D,
and also adds runtime check in SMP code to support both Cortex-A9
and Cortex-A7 ARM cores.
With this patch set, i.MX7D can boot up SMP kernel with 2 CPUs.
Anson
On Thu, Aug 18, 2016 at 03:08:22AM +0900, Masahiro Yamada wrote:
> Add T: entry for a new git tree, which I expect UniPhier SoC
> updates will be pulled from.
>
> Signed-off-by: Masahiro Yamada
Applied. Thanks.
-Olof
On Thu, Aug 18, 2016 at 03:08:22AM +0900, Masahiro Yamada wrote:
> Add T: entry for a new git tree, which I expect UniPhier SoC
> updates will be pulled from.
>
> Signed-off-by: Masahiro Yamada
Applied. Thanks.
-Olof
On Thu, Aug 25, 2016 at 02:23:35PM -0700, Linus Torvalds wrote:
> On Aug 25, 2016 2:08 PM, "Josh Poimboeuf" wrote:
> >
> > Ah, the plot thickens. I didn't know about 'dmesg_restrict'. So I
> > guess we don't have to restrict the stack dump addresses after all,
> > since the
On Thu, Aug 25, 2016 at 02:23:35PM -0700, Linus Torvalds wrote:
> On Aug 25, 2016 2:08 PM, "Josh Poimboeuf" wrote:
> >
> > Ah, the plot thickens. I didn't know about 'dmesg_restrict'. So I
> > guess we don't have to restrict the stack dump addresses after all,
> > since the entire dmesg buffer
Hi,
[no properly binding reference via In-Reply-To: available thus manually
re-creating, sorry]
> > But initerim I guess we could set our own owner field and check that
> > to keep the duct-tape from getting off completely.
> > -Daniel
>
> Another alternative is to provide a standard mutex API
> "Tyrel" == Tyrel Datwyler writes:
Tyrel> This patchset introduces optional FC-TAPE/FC Class 3 Error
Tyrel> Recovery to the ibmvfc client driver.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Hi,
[no properly binding reference via In-Reply-To: available thus manually
re-creating, sorry]
> > But initerim I guess we could set our own owner field and check that
> > to keep the duct-tape from getting off completely.
> > -Daniel
>
> Another alternative is to provide a standard mutex API
> "Tyrel" == Tyrel Datwyler writes:
Tyrel> This patchset introduces optional FC-TAPE/FC Class 3 Error
Tyrel> Recovery to the ibmvfc client driver.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Rework configs accessors so a future patch can use them in _probe()
with struct altera_pcie instead of struct pci_bus.
Signed-off-by: Ley Foon Tan
---
drivers/pci/host/pcie-altera.c | 64 +++---
1 file changed, 41 insertions(+), 23
Rework configs accessors so a future patch can use them in _probe()
with struct altera_pcie instead of struct pci_bus.
Signed-off-by: Ley Foon Tan
---
drivers/pci/host/pcie-altera.c | 64 +++---
1 file changed, 41 insertions(+), 23 deletions(-)
diff --git
> "Christophe" == Christophe JAILLET writes:
Christophe> It is likely that checking the result of
Christophe> 'pci_write_config_dword' is expected here.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
> "Christophe" == Christophe JAILLET writes:
Christophe> It is likely that checking the result of
Christophe> 'pci_write_config_dword' is expected here.
Applied to 4.9/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
On 08/25/16 at 11:00pm, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 12:31 PM, Dave Young wrote:
> > On 08/10/16 at 03:35pm, Hari Bathini wrote:
> > > When fadump is enabled, by default 5% of system RAM is reserved for
> > > fadump kernel. While that works for most cases, it is not good
On 08/25/16 at 11:00pm, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 12:31 PM, Dave Young wrote:
> > On 08/10/16 at 03:35pm, Hari Bathini wrote:
> > > When fadump is enabled, by default 5% of system RAM is reserved for
> > > fadump kernel. While that works for most cases, it is not good
On Thu, Aug 18, 2016 at 08:31:55AM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> A fix and a maintainers update for current release cycle (v4.8).
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07
On Thu, Aug 18, 2016 at 08:31:55AM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> A fix and a maintainers update for current release cycle (v4.8).
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07
On Thu, Aug 25, 2016 at 03:56:59PM +0900, Byungchul Park wrote:
> On Sun, Jul 05, 2015 at 06:43:31PM +0900, byungchul.p...@lge.com wrote:
> > From: Byungchul Park
>
> Hello,
>
> This patch was rejected and the next version having tried to apply what
> peterz recommanded,
On Thu, Aug 25, 2016 at 03:56:59PM +0900, Byungchul Park wrote:
> On Sun, Jul 05, 2015 at 06:43:31PM +0900, byungchul.p...@lge.com wrote:
> > From: Byungchul Park
>
> Hello,
>
> This patch was rejected and the next version having tried to apply what
> peterz recommanded, was almost ignored last
On Fri, Aug 26, 2016 at 08:50:50AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2016/8/26 0:57, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On Thu, Aug 25, 2016 at 05:22:29PM +0800, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2016/8/24 0:53, Jaegeuk Kim wrote:
> >>> Hi Chao,
> >>>
> >>> On Sun, Aug
On Fri, Aug 26, 2016 at 08:50:50AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2016/8/26 0:57, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On Thu, Aug 25, 2016 at 05:22:29PM +0800, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2016/8/24 0:53, Jaegeuk Kim wrote:
> >>> Hi Chao,
> >>>
> >>> On Sun, Aug
On Wed, Aug 10, 2016 at 8:27 PM, Tobias Klauser wrote:
> Use of_property_read_bool instead of open-coding it as fpcu_has. Convert
> the members of struct cpuinfo from u32 to bool accordingly as they are
> only used as boolean anyhow.
>
> Signed-off-by: Tobias Klauser
On Wed, Aug 10, 2016 at 8:27 PM, Tobias Klauser wrote:
> Use of_property_read_bool instead of open-coding it as fpcu_has. Convert
> the members of struct cpuinfo from u32 to bool accordingly as they are
> only used as boolean anyhow.
>
> Signed-off-by: Tobias Klauser
Acked-by: Ley Foon Tan
> Hi Jisheng,
>
> Looks good to me. But, you need to rebase it
> on latest devfreq.git because the related patch
> is already merged[1] for COMPILE_TEST.
> So, the merge conflict may happen.
>
> [1]
>
> Hi Jisheng,
>
> Looks good to me. But, you need to rebase it
> on latest devfreq.git because the related patch
> is already merged[1] for COMPILE_TEST.
> So, the merge conflict may happen.
>
> [1]
>
Hi MyungJoo, Chanwoo,
On Fri, 26 Aug 2016 02:42:05 + MyungJoo Ham wrote:
> > Hi Jisheng,
> >
> > Looks good to me. But, you need to rebase it
> > on latest devfreq.git because the related patch
> > is already merged[1] for COMPILE_TEST.
> > So, the merge conflict may happen.
> >
> > [1]
>
Add vendor id for Japan Display Inc.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
Acked-by: Rob Herring
Hi MyungJoo, Chanwoo,
On Fri, 26 Aug 2016 02:42:05 + MyungJoo Ham wrote:
> > Hi Jisheng,
> >
> > Looks good to me. But, you need to rebase it
> > on latest devfreq.git because the related patch
> > is already merged[1] for COMPILE_TEST.
> > So, the merge conflict may happen.
> >
> > [1]
>
Add vendor id for Japan Display Inc.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
> "John" == John Garry writes:
John> This patchset introduces support for the internal abort feature
John> for the HiSilicon SAS controller.
John> The internal abort feature allows commands which are active in the
John> controller to be aborted before being sent to
> "John" == John Garry writes:
John> This patchset introduces support for the internal abort feature
John> for the HiSilicon SAS controller.
John> The internal abort feature allows commands which are active in the
John> controller to be aborted before being sent to the slave device.
John>
On 2016-08-25 18:24, Wolfram Sang wrote:
> On Thu, Aug 25, 2016 at 06:22:37PM +0200, Peter Rosin wrote:
>> On 2016-08-25 18:19, Wolfram Sang wrote:
>>>
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
b/drivers/i2c/muxes/i2c-mux-pca9541.c
index 3cb8af635db5..f052c3067791 100644
On 2016-08-25 18:24, Wolfram Sang wrote:
> On Thu, Aug 25, 2016 at 06:22:37PM +0200, Peter Rosin wrote:
>> On 2016-08-25 18:19, Wolfram Sang wrote:
>>>
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
b/drivers/i2c/muxes/i2c-mux-pca9541.c
index 3cb8af635db5..f052c3067791 100644
Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.
Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git
And video mode setting is from
Add documentation for lt070me05000 panel
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
Acked-by: Rob Herring
Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.
Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git
And video mode setting is from
Add documentation for lt070me05000 panel
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
Acked-by: Rob Herring
---
v2:
* incorporated rob herring and thierry reviews
gpio to gpios, gpio to regulator using fixed regulators
and pwm
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 61c04572de404e52a655a36752e696bbcb483cf5
commit: 112dc0c8069e5554e0ad29c58228f1e6ca49e13d locking/barriers: Suppress
sparse warnings in lockless_dereference()
date: 8 days ago
reproduce:
# apt-get
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 61c04572de404e52a655a36752e696bbcb483cf5
commit: 112dc0c8069e5554e0ad29c58228f1e6ca49e13d locking/barriers: Suppress
sparse warnings in lockless_dereference()
date: 8 days ago
reproduce:
# apt-get
> "Christophe" == Christophe JAILLET writes:
Christophe> The 2nd parameter of 'find_first_bit' is the number of bits
Christophe> to search. In this case, we are passing 'sizeof(unsigned
Christophe> long)' which is likely to be 4.
Kashyap? Sumit?
--
Martin
> "Christophe" == Christophe JAILLET writes:
Christophe> The 2nd parameter of 'find_first_bit' is the number of bits
Christophe> to search. In this case, we are passing 'sizeof(unsigned
Christophe> long)' which is likely to be 4.
Kashyap? Sumit?
--
Martin K. Petersen Oracle Linux
Shaun,
On 8/25/16 05:24, Shaun Tancheff wrote:
(RESENDING to include f2fs, fs-devel and dm-devel)
Add op flags to access to zone information as well as open, close
and reset zones:
- REQ_OP_ZONE_REPORT - Query zone information (Report zones)
- REQ_OP_ZONE_OPEN - Explicitly open a zone for
Shaun,
On 8/25/16 05:24, Shaun Tancheff wrote:
(RESENDING to include f2fs, fs-devel and dm-devel)
Add op flags to access to zone information as well as open, close
and reset zones:
- REQ_OP_ZONE_REPORT - Query zone information (Report zones)
- REQ_OP_ZONE_OPEN - Explicitly open a zone for
On Thu, Aug 25, 2016 at 12:32:44PM +0200, Mickaël Salaün wrote:
> Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op)
> to compare the current process cgroup with a cgroup handle, The handle
> can match the current cgroup if it is the same or a child. This allows
> to make
On Thu, Aug 25, 2016 at 12:32:44PM +0200, Mickaël Salaün wrote:
> Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op)
> to compare the current process cgroup with a cgroup handle, The handle
> can match the current cgroup if it is the same or a child. This allows
> to make
1 - 100 of 1510 matches
Mail list logo