On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to? What
>> > specifically is the endianess problem
On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to? What
>> > specifically is the endianess problem
On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote:
> From: Yury Norov
> Date: Tue, 24 May 2016 03:04:30 +0300
>
> > +To clear that top halves, automatic wrappers are introduced. They clear all
> > +required registers before passing control to regular syscall
On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote:
> From: Yury Norov
> Date: Tue, 24 May 2016 03:04:30 +0300
>
> > +To clear that top halves, automatic wrappers are introduced. They clear all
> > +required registers before passing control to regular syscall handler.
>
> Why have one
Hi CK,
Reply in line.
On Thu, 2016-05-26 at 15:28 +0800, CK Hu wrote:
> Hi, HS:
>
> Replay inline.
>
> On Tue, 2016-05-24 at 20:27 +0800, Horng-Shyang Liao wrote:
> > Hi CK,
> >
> > Reply in line.
> >
> > On Tue, 2016-05-24 at 11:05 +0800, CK Hu wrote:
> > > Hi, HS:
> > >
> > > Some
Hi CK,
Reply in line.
On Thu, 2016-05-26 at 15:28 +0800, CK Hu wrote:
> Hi, HS:
>
> Replay inline.
>
> On Tue, 2016-05-24 at 20:27 +0800, Horng-Shyang Liao wrote:
> > Hi CK,
> >
> > Reply in line.
> >
> > On Tue, 2016-05-24 at 11:05 +0800, CK Hu wrote:
> > > Hi, HS:
> > >
> > > Some
2016-05-26 10:53 GMT+08:00 Steve Muckle :
> The slow-path frequency transition path is relatively expensive as it
> requires waking up a thread to do work. Should support be added for
> remote CPU cpufreq updates that is also expensive since it requires an
> IPI. These
2016-05-26 10:53 GMT+08:00 Steve Muckle :
> The slow-path frequency transition path is relatively expensive as it
> requires waking up a thread to do work. Should support be added for
> remote CPU cpufreq updates that is also expensive since it requires an
> IPI. These activities should be avoided
On Fri, May 27, 2016 at 09:42:24AM +0800, Chen Feng wrote:
> Hi Joonsoo,
> > -/* Free whole pageblock and set its migration type to MIGRATE_CMA. */
> > +/* Free whole pageblock and set its migration type to MIGRATE_MOVABLE. */
> > void __init init_cma_reserved_pageblock(struct page *page)
> > {
On Fri, May 27, 2016 at 09:42:24AM +0800, Chen Feng wrote:
> Hi Joonsoo,
> > -/* Free whole pageblock and set its migration type to MIGRATE_CMA. */
> > +/* Free whole pageblock and set its migration type to MIGRATE_MOVABLE. */
> > void __init init_cma_reserved_pageblock(struct page *page)
> > {
On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote:
> On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote:
> > From: Joonsoo Kim
>
> Hi Joonsoo,
>
> Nice work!
Thanks!
> > FYI, there is another attempt [3] trying to solve this problem in lkml.
> >
On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote:
> On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote:
> > From: Joonsoo Kim
>
> Hi Joonsoo,
>
> Nice work!
Thanks!
> > FYI, there is another attempt [3] trying to solve this problem in lkml.
> > And, as far as I know,
On Thu, May 26, 2016 at 1:33 PM, Michal Marek wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild
This pull results in new warnings.
I get new "may be uninitialized" warnings now for me allmodconfig
build, and while I didn't look at them all, the
On Thu, May 26, 2016 at 1:33 PM, Michal Marek wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild
This pull results in new warnings.
I get new "may be uninitialized" warnings now for me allmodconfig
build, and while I didn't look at them all, the one I looked at
On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> On 5/25/2016 5:37 PM, Minchan Kim wrote:
> >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> >>>Per the discussion with Joonsoo Kim [1], we need check the return
On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> On 5/25/2016 5:37 PM, Minchan Kim wrote:
> >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> >>>Per the discussion with Joonsoo Kim [1], we need check the return
Hi Choi,
Sorry for changing author, will update author field with your name.
Regarding Rob Herring comments, You had already replied.
I felt separate compatible for each external connector is not required,
as client driver can detect the type of external cable(sdp,dcp, microphone) on
receiving
Hi Choi,
Sorry for changing author, will update author field with your name.
Regarding Rob Herring comments, You had already replied.
I felt separate compatible for each external connector is not required,
as client driver can detect the type of external cable(sdp,dcp, microphone) on
receiving
On 27 May 2016 at 05:41, Peter Chen wrote:
> On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
>> Hello,
>>
>> I was updating my config by make oldconfig for a while and noticed that my
>> USB
>> OTG controller is not working. Apparently it grew dependency
On 27 May 2016 at 05:41, Peter Chen wrote:
> On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
>> Hello,
>>
>> I was updating my config by make oldconfig for a while and noticed that my
>> USB
>> OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
>> over
Hi Michal,
On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek wrote:
> On 27 May 2016 at 04:05, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote:
>>> The trasfer timeout is fixed at
Hi Michal,
On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek wrote:
> On 27 May 2016 at 04:05, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote:
>>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>>> 1MHz SPI bus takes way
On 27 May 2016 at 04:05, Julian Calaby wrote:
> Hi Michal,
>
> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote:
>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>> 1MHz SPI bus takes way longer than that. Calculate the
On 27 May 2016 at 04:05, Julian Calaby wrote:
> Hi Michal,
>
> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote:
>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>> 1MHz SPI bus takes way longer than that. Calculate the timeout from the
>> actual time the transfer is
Hello Sergey,
I want to know more how it works so below questions goes.
On Wed, May 25, 2016 at 11:30:04PM +0900, Sergey Senozhatsky wrote:
> There is no way to get a string with all the crypto comp
> algorithms supported by the crypto comp engine, so we need
> to maintain our own backends list.
Hello Sergey,
I want to know more how it works so below questions goes.
On Wed, May 25, 2016 at 11:30:04PM +0900, Sergey Senozhatsky wrote:
> There is no way to get a string with all the crypto comp
> algorithms supported by the crypto comp engine, so we need
> to maintain our own backends list.
On 2016/5/27 8:25, Jaegeuk Kim wrote:
If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away.
Otherwise, for example, we can get duplicate directory entry by ->chash and
->clevel.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/dir.c| 23 ---
On 2016/5/27 8:25, Jaegeuk Kim wrote:
If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away.
Otherwise, for example, we can get duplicate directory entry by ->chash and
->clevel.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/dir.c| 23 ---
fs/f2fs/inline.c |
On 27 May 2016 at 05:18, Darrick J. Wong wrote:
>
> It's possible that the pvscsi device advertised WRITE SAME, but if the device
> sends back ILLEGAL REQUEST then the SCSI disk driver will set
> write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue
On 27 May 2016 at 05:18, Darrick J. Wong wrote:
>
> It's possible that the pvscsi device advertised WRITE SAME, but if the device
> sends back ILLEGAL REQUEST then the SCSI disk driver will set
> write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue writes
> of zeroes to the
On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote:
> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote:
>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
>>> One problem with seccomp was that ptrace could be used to
On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote:
> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote:
>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
>>> One problem with seccomp was that ptrace could be used to change a
>>> syscall after seccomp filtering had completed. This was a
On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote:
> There is a double free problem in the usb driver.
Which driver?
> This is caused by delayed deregister for scsi device.
> <*> at Insert USB Storage
> - USB bus #1 register
> usb_create_hcd (primary-kref==1)
> *
On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote:
> There is a double free problem in the usb driver.
Which driver?
> This is caused by delayed deregister for scsi device.
> <*> at Insert USB Storage
> - USB bus #1 register
> usb_create_hcd (primary-kref==1)
> *
On Wed, May 25, 2016 at 11:30:03PM +0900, Sergey Senozhatsky wrote:
> A cosmetic change: use the same datatypes as crypto API does.
>
> Signed-off-by: Sergey Senozhatsky
> Cc: Minchan Kim
> Cc: Joonsoo Kim
> ---
>
On Wed, May 25, 2016 at 11:30:03PM +0900, Sergey Senozhatsky wrote:
> A cosmetic change: use the same datatypes as crypto API does.
>
> Signed-off-by: Sergey Senozhatsky
> Cc: Minchan Kim
> Cc: Joonsoo Kim
> ---
> drivers/block/zram/zcomp.c| 5 ++---
> drivers/block/zram/zcomp.h| 5
On Thu 26 May 20:58 PDT 2016, Rob Herring wrote:
> +dt list
>
> On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson
> wrote:
[..]
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
> > b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
On Thu 26 May 20:58 PDT 2016, Rob Herring wrote:
> +dt list
>
> On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson
> wrote:
[..]
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
> > b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
> > new file mode 100644
> >
On Wed, May 25, 2016 at 11:30:02PM +0900, Sergey Senozhatsky wrote:
> We don't need to supply a zcomp pointer to compress/decompress
> functions, drop it.
>
> Signed-off-by: Sergey Senozhatsky
> Cc: Minchan Kim
> Cc: Joonsoo Kim
On Wed, May 25, 2016 at 11:30:02PM +0900, Sergey Senozhatsky wrote:
> We don't need to supply a zcomp pointer to compress/decompress
> functions, drop it.
>
> Signed-off-by: Sergey Senozhatsky
> Cc: Minchan Kim
> Cc: Joonsoo Kim
Could you fold this patch into previous one?
> ---
>
On Wed, May 25, 2016 at 11:30:01PM +0900, Sergey Senozhatsky wrote:
> We don't have an idle zstreams list anymore and our write path
> now works absolutely differently, preventing preemption during
> compression. This removes possibilities of read paths preempting
> writes at wrong places (which
On Wed, May 25, 2016 at 11:30:01PM +0900, Sergey Senozhatsky wrote:
> We don't have an idle zstreams list anymore and our write path
> now works absolutely differently, preventing preemption during
> compression. This removes possibilities of read paths preempting
> writes at wrong places (which
On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown)
wrote:
>
>
> On 2016/5/26 21:13, Rob Herring wrote:
>> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote:
>>> For a normal memory@ devicetree node, its reg property can contains more
>>> memory blocks.
>>>
On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown)
wrote:
>
>
> On 2016/5/26 21:13, Rob Herring wrote:
>> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote:
>>> For a normal memory@ devicetree node, its reg property can contains more
>>> memory blocks.
>>>
>>> Because we don't known
> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@sandisk.com]
> Sent: Thursday, May 26, 2016 7:19 PM
> To: Long Li ; James E.J. Bottomley
> ; Martin K. Petersen
>
> Cc: KY Srinivasan
> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@sandisk.com]
> Sent: Thursday, May 26, 2016 7:19 PM
> To: Long Li ; James E.J. Bottomley
> ; Martin K. Petersen
>
> Cc: KY Srinivasan ; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH]
On Wed, May 18, 2016 at 11:39:30PM +0100, Sitsofe Wheeler wrote:
> Hi,
>
> With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23
> 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the
> BLKZEROOUT syscall can malfunction and not zero data.
>
> When BLKZEROOUT is issued to an MD device
On Wed, May 18, 2016 at 11:39:30PM +0100, Sitsofe Wheeler wrote:
> Hi,
>
> With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23
> 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the
> BLKZEROOUT syscall can malfunction and not zero data.
>
> When BLKZEROOUT is issued to an MD device
在 2016/5/27 11:46, Jaehoon Chung 写道:
Hi Shawn,
On 05/27/2016 12:02 PM, Shawn Lin wrote:
The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for
在 2016/5/27 11:46, Jaehoon Chung 写道:
Hi Shawn,
On 05/27/2016 12:02 PM, Shawn Lin wrote:
The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for
Hi Elad, Noam,
On Thursday 26 May 2016 11:23 PM, Alexey Brodkin wrote:
>
> We just bumped into the same problem (data exchange hangs on the very first
> "ping")
> with released Linux v4.6 and linux-next on our nSIM OSCI virtual platform.
>
> I believe it was commit 05c00d82f4d1 ("net:
Hi Elad, Noam,
On Thursday 26 May 2016 11:23 PM, Alexey Brodkin wrote:
>
> We just bumped into the same problem (data exchange hangs on the very first
> "ping")
> with released Linux v4.6 and linux-next on our nSIM OSCI virtual platform.
>
> I believe it was commit 05c00d82f4d1 ("net:
+dt list
On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson
wrote:
> This binding describes the control interface for the Qualcomm WCNSS.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v1:
> - Introduce reference to wcnss block
+dt list
On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson
wrote:
> This binding describes the control interface for the Qualcomm WCNSS.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v1:
> - Introduce reference to wcnss block node for register block definition
> - Use wcnss block
Hi, Boris
Can you help to confirm if this can fix all of the issues you saw in the older
qemu.
Thanks and best regards
-Lv
> From: Zheng, Lv
> Subject: [PATCH] ACPICA / hardware: Fix address check in
> acpi_hw_get_access_bit_width()
>
> The address check in acpi_hw_get_access_bit_width()
Hi, Boris
Can you help to confirm if this can fix all of the issues you saw in the older
qemu.
Thanks and best regards
-Lv
> From: Zheng, Lv
> Subject: [PATCH] ACPICA / hardware: Fix address check in
> acpi_hw_get_access_bit_width()
>
> The address check in acpi_hw_get_access_bit_width()
ping..
在 2016/5/16 12:51, He Kuang 写道:
There's a display inconsistency when 'call-graph' config event appears
in different position. The problem can be reproduced like this:
We record signal_deliver with call-graph and signal_generate without it.
$ perf record -g -a -e
ping..
在 2016/5/16 12:51, He Kuang 写道:
There's a display inconsistency when 'call-graph' config event appears
in different position. The problem can be reproduced like this:
We record signal_deliver with call-graph and signal_generate without it.
$ perf record -g -a -e
On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
> Hello,
>
> I was updating my config by make oldconfig for a while and noticed that my USB
> OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
> over time.
>
> Looking through defconfigs some have it
On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
> Hello,
>
> I was updating my config by make oldconfig for a while and noticed that my USB
> OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
> over time.
>
> Looking through defconfigs some have it
Hi Shawn,
On 05/27/2016 12:02 PM, Shawn Lin wrote:
> The main reason to add this check is to avoid unnecessary
> mmc_request like the on-going cmd and the corresponding sbc
> if the card is removed. Although we have already checked this in
> dw_mci_handle_cd for runtime usage of sd card and
Hi Shawn,
On 05/27/2016 12:02 PM, Shawn Lin wrote:
> The main reason to add this check is to avoid unnecessary
> mmc_request like the on-going cmd and the corresponding sbc
> if the card is removed. Although we have already checked this in
> dw_mci_handle_cd for runtime usage of sd card and
Hi Vincent,
On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote:
> On 26 May 2016 at 03:14, Yuyang Du wrote:
> > Vincent reported that the first task to a new task group's cfs_rq will
> > be attached in attach_task_cfs_rq() and once more when it is enqueued
> >
Hi Vincent,
On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote:
> On 26 May 2016 at 03:14, Yuyang Du wrote:
> > Vincent reported that the first task to a new task group's cfs_rq will
> > be attached in attach_task_cfs_rq() and once more when it is enqueued
> > (see
The address check in acpi_hw_get_access_bit_width() should be byte size
based, not bit width based. This patch fixes this mistake.
Reported-by: Boris Ostrovsky
Suggested-by: Jan Beulich
Signed-off-by: Lv Zheng
---
The address check in acpi_hw_get_access_bit_width() should be byte size
based, not bit width based. This patch fixes this mistake.
Reported-by: Boris Ostrovsky
Suggested-by: Jan Beulich
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/hwregs.c |2 +-
1 file changed, 1 insertion(+), 1
On 2016/5/26 21:13, Rob Herring wrote:
> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote:
>> For a normal memory@ devicetree node, its reg property can contains more
>> memory blocks.
>>
>> Because we don't known how many memory blocks maybe contained, so we try
>> from index=0,
On 2016/5/26 21:13, Rob Herring wrote:
> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote:
>> For a normal memory@ devicetree node, its reg property can contains more
>> memory blocks.
>>
>> Because we don't known how many memory blocks maybe contained, so we try
>> from index=0,
On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Override the compatible string of the first USB controller to enable
> device mode.
>
> Signed-off-by: Thierry Reding
> ---
>
Hi all,
Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.
Changes since 20160526:
My fixes tree contains this:
mm/cma: silence warnings due to max() usage
Non-merge commits (relative to Linus' tree): 883
837 files
On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Override the compatible string of the first USB controller to enable
> device mode.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 11 +++
> 1 file changed,
Hi all,
Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.
Changes since 20160526:
My fixes tree contains this:
mm/cma: silence warnings due to max() usage
Non-merge commits (relative to Linus' tree): 883
837 files
Hi,
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Friday, May 27, 2016 12:56 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
> bit width support
>
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky
Hi,
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Friday, May 27, 2016 12:56 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
> bit width support
>
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky 05/25/16 9:17
> PM >>>
> >> On
Hi.
Assuming no objection to this patch,
I will put it into Russell's patch tracker after v4.7-rc1 is out.
2016-04-04 11:29 GMT+09:00 Masahiro Yamada :
> Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
> generate invalid images") fixed bad
Hi.
Assuming no objection to this patch,
I will put it into Russell's patch tracker after v4.7-rc1 is out.
2016-04-04 11:29 GMT+09:00 Masahiro Yamada :
> Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
> generate invalid images") fixed bad image generation in case of
>
On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea
> USB device controller. This set of patches adds very rudimentary support
> for it to the existing ChipIdea
On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea
> USB device controller. This set of patches adds very rudimentary support
> for it to the existing ChipIdea driver and enables them
Hi,
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky
> Sent: Thursday, May 26, 2016 3:17 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit
> width support
>
> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> >
Hi,
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky
> Sent: Thursday, May 26, 2016 3:17 AM
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit
> width support
>
> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> >
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
mm/oom_kill.c: In function '__oom_reap_task':
mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function
[-Wmaybe-uninitialized]
mmput_async(mm);
^
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
mm/oom_kill.c: In function '__oom_reap_task':
mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function
[-Wmaybe-uninitialized]
mmput_async(mm);
^
The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot
for noremovable devices, but there is a timing
The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot
for noremovable devices, but there is a timing
dw_mci_get_cd have already dealt with these for
both of internal card-detect and gpio card-detect.
Signed-off-by: Shawn Lin
---
drivers/mmc/host/dw_mmc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c
dw_mci_get_cd have already dealt with these for
both of internal card-detect and gpio card-detect.
Signed-off-by: Shawn Lin
---
drivers/mmc/host/dw_mmc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index
On 05/26/16 17:08, Long Li wrote:
The block sector size should be in unit of 512 bytes, not in bytes.
Signed-off-by: Long Li
---
drivers/scsi/sd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index
On 05/26/16 17:08, Long Li wrote:
The block sector size should be in unit of 512 bytes, not in bytes.
Signed-off-by: Long Li
---
drivers/scsi/sd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 428c03e..4bce17e 100644
---
On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote:
> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
>> One problem with seccomp was that ptrace could be used to change a
>> syscall after seccomp filtering had completed. This was a well
On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote:
> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
>> One problem with seccomp was that ptrace could be used to change a
>> syscall after seccomp filtering had completed. This was a well documented
>> limitation, and it was recommended to
On 2016/5/27 1:12, David Daney wrote:
> The current patch to correct this problem is here:
>
> https://lkml.org/lkml/2016/5/24/679
>
> Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next
> as soon as the current merge window ends, further simplifications of the
>
On 2016/5/27 1:12, David Daney wrote:
> The current patch to correct this problem is here:
>
> https://lkml.org/lkml/2016/5/24/679
>
> Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next
> as soon as the current merge window ends, further simplifications of the
>
Hi Jaehoon,
On 2016/5/27 8:53, Jaehoon Chung wrote:
Hi Shawn,
On 05/26/2016 12:08 PM, Shawn Lin wrote:
The main reason to add this check is to avoid unnecessary
mmc_request if the card is removed. Although we have already
check this in dw_mci_handle_cd for runtime usage of sd card and
Hi Jaehoon,
On 2016/5/27 8:53, Jaehoon Chung wrote:
Hi Shawn,
On 05/26/2016 12:08 PM, Shawn Lin wrote:
The main reason to add this check is to avoid unnecessary
mmc_request if the card is removed. Although we have already
check this in dw_mci_handle_cd for runtime usage of sd card and
在 2016/5/27 8:53, Jaehoon Chung 写道:
Hi Shawn,
On 05/26/2016 12:07 PM, Shawn Lin wrote:
dw_mci_get_cd have already dealed with these for
both of internal card-detect and gpio card-detect.
s/dealed/dealt
This patch looks good to me. Could you resend the patch? not RFC.
Ok.
Best Regards,
在 2016/5/27 8:53, Jaehoon Chung 写道:
Hi Shawn,
On 05/26/2016 12:07 PM, Shawn Lin wrote:
dw_mci_get_cd have already dealed with these for
both of internal card-detect and gpio card-detect.
s/dealed/dealt
This patch looks good to me. Could you resend the patch? not RFC.
Ok.
Best Regards,
On Thu, May 26, 2016 at 2:46 PM, Sage Weil wrote:
>
> One point of clarification, though: in the past I've squashed down fixes
> discovered during testing if the branch hasn't hit a stable tree yet
> (e.g., your tree). AIUI this is(was?) standard procedure for things in
>
On Thu, May 26, 2016 at 2:46 PM, Sage Weil wrote:
>
> One point of clarification, though: in the past I've squashed down fixes
> discovered during testing if the branch hasn't hit a stable tree yet
> (e.g., your tree). AIUI this is(was?) standard procedure for things in
> -next.
Yes, rebasing
On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
> One problem with seccomp was that ptrace could be used to change a
> syscall after seccomp filtering had completed. This was a well documented
> limitation, and it was recommended to block ptrace when defining a filter
>
On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote:
> One problem with seccomp was that ptrace could be used to change a
> syscall after seccomp filtering had completed. This was a well documented
> limitation, and it was recommended to block ptrace when defining a filter
> to avoid this problem.
1 - 100 of 892 matches
Mail list logo