Enable DS0 for only those platforms on which it is functional
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/pm33xx-core.c| 5 +
drivers/soc/ti/pm33xx.c | 9 +
include/linux/platform_data/pm33xx.h | 2 ++
3 files changed, 16 insertions(+)
diff --git
Enable DS0 for only those platforms on which it is functional
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/pm33xx-core.c| 5 +
drivers/soc/ti/pm33xx.c | 9 +
include/linux/platform_data/pm33xx.h | 2 ++
3 files changed, 16 insertions(+)
diff --git
1) Remove redundant variables, from Colin Ian King.
2) Expected switch fall-through annotations, from Gustavo A. R. Silva
Please pull, thanks!
The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703:
Linux 4.18 (2018-08-12 13:41:04 -0700)
are available in the Git
1) Remove redundant variables, from Colin Ian King.
2) Expected switch fall-through annotations, from Gustavo A. R. Silva
Please pull, thanks!
The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703:
Linux 4.18 (2018-08-12 13:41:04 -0700)
are available in the Git
Nothing super serious:
1) Convert sparc32 over to NO_BOOTMEM, from Mike Rapoport.
2) Use dma_noncoherent_ops on sparc32, from Christoph Hellwig
3) Fix kbuild defconfig handling on sparc32, from Masahiro Yamada.
Please pull, thanks a lot.
The following changes since commit
Nothing super serious:
1) Convert sparc32 over to NO_BOOTMEM, from Mike Rapoport.
2) Use dma_noncoherent_ops on sparc32, from Christoph Hellwig
3) Fix kbuild defconfig handling on sparc32, from Masahiro Yamada.
Please pull, thanks a lot.
The following changes since commit
Hi,
On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
>
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the
Hi,
On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
>
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the
The ncsi_pkg_info_all_nl() .dumpit handler is missing the NLM_F_MULTI
flag, causing additional package information after the first to be lost.
Also fixup a sanity check in ncsi_write_package_info() to reject out of
range package IDs.
Signed-off-by: Samuel Mendoza-Jonas
---
The ncsi_pkg_info_all_nl() .dumpit handler is missing the NLM_F_MULTI
flag, causing additional package information after the first to be lost.
Also fixup a sanity check in ncsi_write_package_info() to reject out of
range package IDs.
Signed-off-by: Samuel Mendoza-Jonas
---
Hello Greg,
On (08/21/18 15:57), Greg Kroah-Hartman wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there. Am I wrong?
>
> sysfs data is always null terminated.
>
> What exactly are you trying to do here? If a
Hello Greg,
On (08/21/18 15:57), Greg Kroah-Hartman wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there. Am I wrong?
>
> sysfs data is always null terminated.
>
> What exactly are you trying to do here? If a
Create auxiliary trace data log files when invoked with option
--itrace=d as in
[root@s35lp76 perf] ./perf report -i perf.data.aux1 --stdio --itrace=d
perf report creates several data files in the current directory
named aux.smp.## where ## is a 2 digit hex number with
leading zeros
Create auxiliary trace data log files when invoked with option
--itrace=d as in
[root@s35lp76 perf] ./perf report -i perf.data.aux1 --stdio --itrace=d
perf report creates several data files in the current directory
named aux.smp.## where ## is a 2 digit hex number with
leading zeros
Joe Perches wrote on Tue, Aug 21, 2018:
> On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> > I think that could work, but at the point making a separate
> > compiler-common.h and not including compiler-gcc.h for clang sounds
> > better to me... More importantly here, either solution
Joe Perches wrote on Tue, Aug 21, 2018:
> On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> > I think that could work, but at the point making a separate
> > compiler-common.h and not including compiler-gcc.h for clang sounds
> > better to me... More importantly here, either solution
On Mon, Aug 13, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
>
> Hi Linus,
>
> Please pull the IDA patchset. It depends on the XArray patchset, so
> ignore this pull request if you've decided not to pull the XArray patches.
> The new IDA API is similar to ida_simple_get() but better named.
On Mon, Aug 13, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
>
> Hi Linus,
>
> Please pull the IDA patchset. It depends on the XArray patchset, so
> ignore this pull request if you've decided not to pull the XArray patches.
> The new IDA API is similar to ida_simple_get() but better named.
On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> I think that could work, but at the point making a separate
> compiler-common.h and not including compiler-gcc.h for clang sounds
> better to me... More importantly here, either solution sound complex
> enough to require more than a
On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> I think that could work, but at the point making a separate
> compiler-common.h and not including compiler-gcc.h for clang sounds
> better to me... More importantly here, either solution sound complex
> enough to require more than a
Good day,
My name is Richard Jeffery I have a client, who died as a result of
heart-related condition on the 10th of December, 2015. I have contacted
you to assist in distributing the estate left behind by my client, who
shares the same last name as yours. Would discuss more when I hear from
Good day,
My name is Richard Jeffery I have a client, who died as a result of
heart-related condition on the 10th of December, 2015. I have contacted
you to assist in distributing the estate left behind by my client, who
shares the same last name as yours. Would discuss more when I hear from
Nick Desaulniers wrote on Tue, Aug 21, 2018:
> On Tue, Aug 21, 2018 at 9:45 AM Joe Perches wrote:
> > > Tested with gcc-7 and clang-8.
> >
> > clang-8? Isn't the latest officlal clang 6.0.1 ?
> [...]
> > So if something other than 6.0.x is required,
> > then some additional check should probably
Nick Desaulniers wrote on Tue, Aug 21, 2018:
> On Tue, Aug 21, 2018 at 9:45 AM Joe Perches wrote:
> > > Tested with gcc-7 and clang-8.
> >
> > clang-8? Isn't the latest officlal clang 6.0.1 ?
> [...]
> > So if something other than 6.0.x is required,
> > then some additional check should probably
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180821:
The akpm-current tree gained a conflict against the mips tree.
Non-merge commits (relative to Linus' tree): 2206
2327 files changed, 76092
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180821:
The akpm-current tree gained a conflict against the mips tree.
Non-merge commits (relative to Linus' tree): 2206
2327 files changed, 76092
Add DT bindings for PHY interface built into USB3 controller
implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../bindings/phy/uniphier-usb3-hsphy.txt | 69 ++
.../bindings/phy/uniphier-usb3-ssphy.txt | 57 ++
2 files
Add DT bindings for PHY interface built into USB3 controller
implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../bindings/phy/uniphier-usb3-hsphy.txt | 69 ++
.../bindings/phy/uniphier-usb3-ssphy.txt | 57 ++
2 files
This series adds support for PHY interface built into USB controller
implemented in Socionext UniPhier SoCs.
The USB3 PHY driver supports High-Speed PHY and Super-Speed PHY included in
the USB3 glue layer, and the USB2 PHY driver supports High-Speed PHY
integrated into system controller.
Changes
Add a driver for PHY interface built into USB3 controller
implemented in UniPhier SoCs.
This driver supports High-Speed PHY and Super-Speed PHY.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Motoya Tanigawa
Signed-off-by: Masami Hiramatsu
---
drivers/phy/Kconfig | 1
This series adds support for PHY interface built into USB controller
implemented in Socionext UniPhier SoCs.
The USB3 PHY driver supports High-Speed PHY and Super-Speed PHY included in
the USB3 glue layer, and the USB2 PHY driver supports High-Speed PHY
integrated into system controller.
Changes
Add a driver for PHY interface built into USB3 controller
implemented in UniPhier SoCs.
This driver supports High-Speed PHY and Super-Speed PHY.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Motoya Tanigawa
Signed-off-by: Masami Hiramatsu
---
drivers/phy/Kconfig | 1
Add a driver for PHY interface built into USB2 controller implemented on
UniPhier SoCs. This driver supports HS-PHY for Pro4 and LD11.
Signed-off-by: Kunihiko Hayashi
---
drivers/phy/socionext/Kconfig | 13 ++
drivers/phy/socionext/Makefile| 1 +
Add DT bindings for PHY interface built into USB2 controller
implemented on Socionext UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../devicetree/bindings/phy/uniphier-usb2-phy.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Add a driver for PHY interface built into USB2 controller implemented on
UniPhier SoCs. This driver supports HS-PHY for Pro4 and LD11.
Signed-off-by: Kunihiko Hayashi
---
drivers/phy/socionext/Kconfig | 13 ++
drivers/phy/socionext/Makefile| 1 +
Add DT bindings for PHY interface built into USB2 controller
implemented on Socionext UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../devicetree/bindings/phy/uniphier-usb2-phy.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644
On Tue, Aug 21, 2018 at 04:20:44PM +0200, Arnd Bergmann wrote:
> Building UCM with CONFIG_INFINIBAND_USER_ACCESS=m results in a
> set of link errors including:
>
> drivers/infiniband/core/ucm.o: In function `ib_ucm_event_handler':
> ucm.c:(.text+0x6dc): undefined reference to
On Tue, Aug 21, 2018 at 04:20:44PM +0200, Arnd Bergmann wrote:
> Building UCM with CONFIG_INFINIBAND_USER_ACCESS=m results in a
> set of link errors including:
>
> drivers/infiniband/core/ucm.o: In function `ib_ucm_event_handler':
> ucm.c:(.text+0x6dc): undefined reference to
Hi,
On 08/21/2018 10:10 PM, Dave Gerlach wrote:
> Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
> the operating-points-v2 table in the device tree and calls
> _opp_add_static_v2 for each to add them to the table. It counts each
> iteration through this loop as an added
Hi,
On 08/21/2018 10:10 PM, Dave Gerlach wrote:
> Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
> the operating-points-v2 table in the device tree and calls
> _opp_add_static_v2 for each to add them to the table. It counts each
> iteration through this loop as an added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however on platforms making
use of the
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however on platforms making
use of the
Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a new config option so it can move
memblock_next_valid_pfn to generic code file. All the latter optimizations
are based on this config.
The memblock initialization time on arm/arm64 can benefit from this.
Signed-off-by: Jia He
Reviewed-by: Pavel Tatashin
---
Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a new config option so it can move
memblock_next_valid_pfn to generic code file. All the latter optimizations
are based on this config.
The memblock initialization time on arm/arm64 can benefit from this.
Signed-off-by: Jia He
Reviewed-by: Pavel Tatashin
---
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement.
E.g. if pfn and pfn+1 are in the same memblock region, we can simply pfn++
instead of doing the binary search in
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement.
E.g. if pfn and pfn+1 are in the same memblock region, we can simply pfn++
instead of doing the binary search in
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next
On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
>
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?
Absolutely.
Or preferably not rebasing at all, just starting from a good solid
base for new development in the first
On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
>
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?
Absolutely.
Or preferably not rebasing at all, just starting from a good solid
base for new development in the first
Hi Vinod,
On 9 August 2018 at 15:05, Baolin Wang wrote:
> From: Eric Long
>
> The Spreadtrum DMA can support the link-list transaction mode, which means
> DMA controller can do transaction one by one automatically once we linked
> these transaction by link-list register.
>
> Signed-off-by: Eric
Hi Vinod,
On 9 August 2018 at 15:05, Baolin Wang wrote:
> From: Eric Long
>
> The Spreadtrum DMA can support the link-list transaction mode, which means
> DMA controller can do transaction one by one automatically once we linked
> these transaction by link-list register.
>
> Signed-off-by: Eric
On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
> >
> > Please consider pulling the XArray patch set.
>
> So this merge window has been horrible, but I was just about to start
> looking at it.
>
> And no. I'm not going to
On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
> >
> > Please consider pulling the XArray patch set.
>
> So this merge window has been horrible, but I was just about to start
> looking at it.
>
> And no. I'm not going to
The following patch introduced an issue.
commit f6206f00d8c5 ("dmaengine: mic_x100_dma: use the new helper to
simplify the code")
This issue is :
kfree(mic_dma_dev)
.
dma_async_device_unregister(mic_dma_dev->device);
Free the memory, and use it again.
So use
The following patch introduced an issue.
commit f6206f00d8c5 ("dmaengine: mic_x100_dma: use the new helper to
simplify the code")
This issue is :
kfree(mic_dma_dev)
.
dma_async_device_unregister(mic_dma_dev->device);
Free the memory, and use it again.
So use
On 08/21/2018 06:37 PM, Naoya Horiguchi wrote:
> On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
>> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi
>> wrote:
>>
>>> I've updated the patchset based on feedbacks:
>>>
>>> - updated comments (from Andrew),
>>> - moved calling
On 08/21/2018 06:37 PM, Naoya Horiguchi wrote:
> On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
>> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi
>> wrote:
>>
>>> I've updated the patchset based on feedbacks:
>>>
>>> - updated comments (from Andrew),
>>> - moved calling
On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
>
> Please consider pulling the XArray patch set.
So this merge window has been horrible, but I was just about to start
looking at it.
And no. I'm not going to pull this.
For some unfathomable reason, you have based it on the libnvdimm
On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
>
> Please consider pulling the XArray patch set.
So this merge window has been horrible, but I was just about to start
looking at it.
And no. I'm not going to pull this.
For some unfathomable reason, you have based it on the libnvdimm
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/Kconfig
between commit:
04f264d3a8b0 ("compiler.h: Allow arch-specific asm/compiler.h")
from the mips tree and commit:
7358e371b0ef ("arch: enable relative relocations for arm64, power and x86")
from the
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/Kconfig
between commit:
04f264d3a8b0 ("compiler.h: Allow arch-specific asm/compiler.h")
from the mips tree and commit:
7358e371b0ef ("arch: enable relative relocations for arm64, power and x86")
from the
Russell, will you pick this patch?
On 2018/7/25 15:13, YueHaibing wrote:
> +CC Christoph Hellwig
>
> On 2018/7/25 15:07, YueHaibing wrote:
>> Sean Wang reported dma_zalloc_coherent doesn't work as expect on his
>> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
>>
Russell, will you pick this patch?
On 2018/7/25 15:13, YueHaibing wrote:
> +CC Christoph Hellwig
>
> On 2018/7/25 15:07, YueHaibing wrote:
>> Sean Wang reported dma_zalloc_coherent doesn't work as expect on his
>> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
>>
On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi
> wrote:
>
> > I've updated the patchset based on feedbacks:
> >
> > - updated comments (from Andrew),
> > - moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to
>
On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi
> wrote:
>
> > I've updated the patchset based on feedbacks:
> >
> > - updated comments (from Andrew),
> > - moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to
>
Hi Andrew
On 8/22/2018 5:08 AM, Andrew Morton Wrote:
> On Tue, 21 Aug 2018 14:14:30 +0800 Jia He wrote:
>
>> Hi Pasha
>>
>> On 8/17/2018 9:08 AM, Pasha Tatashin Wrote:
>>>
Signed-off-by: Jia He
---
mm/memblock.c | 37 +
1 file changed,
Hi Andrew
On 8/22/2018 5:08 AM, Andrew Morton Wrote:
> On Tue, 21 Aug 2018 14:14:30 +0800 Jia He wrote:
>
>> Hi Pasha
>>
>> On 8/17/2018 9:08 AM, Pasha Tatashin Wrote:
>>>
Signed-off-by: Jia He
---
mm/memblock.c | 37 +
1 file changed,
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18 next-20180821]
[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
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18 next-20180821]
[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
On Tue, Aug 21, 2018 at 5:45 PM Sergey Senozhatsky
wrote:
>
> Hi,
>
> Did you intend to remove lkml mailing list from Cc?
>
No, that was an accident. I resent it so it's on the record.
I will submit a v2 patch with an updated commit message then.
On Tue, Aug 21, 2018 at 5:45 PM Sergey Senozhatsky
wrote:
>
> Hi,
>
> Did you intend to remove lkml mailing list from Cc?
>
No, that was an accident. I resent it so it's on the record.
I will submit a v2 patch with an updated commit message then.
On Tue, Aug 14, 2018 at 04:45:23PM -0700, Andrew Morton wrote:
> The changelog doesn't describe the end-user impact of the bug, which is
> very desirable when tagging a patch for -stable backporting. Can we
> have that paragraph please?
The end-user impact is that echoing to writeback_dev would
On Tue, Aug 14, 2018 at 04:45:23PM -0700, Andrew Morton wrote:
> The changelog doesn't describe the end-user impact of the bug, which is
> very desirable when tagging a patch for -stable backporting. Can we
> have that paragraph please?
The end-user impact is that echoing to writeback_dev would
On 08/21/2018 05:51 PM, kbuild test robot wrote:
> Hi Mike,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a no
On 08/21/2018 05:51 PM, kbuild test robot wrote:
> Hi Mike,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a no
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
On (08/21/18 15:00), Andy Shevchenko wrote:
> > Returning the length of dst/-EOVERFLOW is a bit inconvenient, because
> > "the length" forces us to have size_t return, which is unsigned.
>
> We have for ages ssize_t to workaround that.
OK.
[..]
> Wouldn't be better to split out something like
>
On (08/21/18 15:00), Andy Shevchenko wrote:
> > Returning the length of dst/-EOVERFLOW is a bit inconvenient, because
> > "the length" forces us to have size_t return, which is unsigned.
>
> We have for ages ssize_t to workaround that.
OK.
[..]
> Wouldn't be better to split out something like
>
On Tue, Aug 21, 2018 at 04:05:22PM -0700, Eduardo Valentin wrote:
> On Tue, Aug 21, 2018 at 03:09:37PM -0700, Andi Kleen wrote:
> > On Tue, Aug 21, 2018 at 02:15:28PM -0700, Eduardo Valentin wrote:
> > > On a system with X86_FEATURE_ARCH_PERFMON disabled
> > > and with a model not known by family
On Tue, Aug 21, 2018 at 04:05:22PM -0700, Eduardo Valentin wrote:
> On Tue, Aug 21, 2018 at 03:09:37PM -0700, Andi Kleen wrote:
> > On Tue, Aug 21, 2018 at 02:15:28PM -0700, Eduardo Valentin wrote:
> > > On a system with X86_FEATURE_ARCH_PERFMON disabled
> > > and with a model not known by family
Thanks, this sounds like what I need. However, since this is a
custom-purpose system, I am tempted to go with CMA and simply
preallocated 200MB on start
On Mon, Aug 20, 2018 at 1:58 PM Alan Cox wrote:
>
> > b) IOMMU can solve this problem for me by providing a device-specific
> > contiguous view
Thanks, this sounds like what I need. However, since this is a
custom-purpose system, I am tempted to go with CMA and simply
preallocated 200MB on start
On Mon, Aug 20, 2018 at 1:58 PM Alan Cox wrote:
>
> > b) IOMMU can solve this problem for me by providing a device-specific
> > contiguous view
Hi Linus,
I was too busy for reviewing patches the last few weeks, so
everything has been in linux-next for a multiple weeks (except
for some fixes, that I initially planned to send for 4.18-rc,
but even those have been in -next for some time now). Stephen
Rothwell noticed a merge conflict in
Hi Linus,
I was too busy for reviewing patches the last few weeks, so
everything has been in linux-next for a multiple weeks (except
for some fixes, that I initially planned to send for 4.18-rc,
but even those have been in -next for some time now). Stephen
Rothwell noticed a merge conflict in
* Rafael J. Wysocki [691231 23:00]:
> From: Rafael J. Wysocki
>
> If the tick has been stopped already, but the governor has not asked to
> stop it (which it can do sometimes), the idle loop should invoke
> tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> of this case
* Rafael J. Wysocki [691231 23:00]:
> From: Rafael J. Wysocki
>
> If the tick has been stopped already, but the governor has not asked to
> stop it (which it can do sometimes), the idle loop should invoke
> tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> of this case
From: "Joel Fernandes (Google)"
Directories and inodes don't necessarily need to be in the same
lockdep class. For ex, hugetlbfs splits them out too to prevent
false positives in lockdep. Annotate correctly after new inode
creation. If its a directory inode, it will be put into a different
From: "Joel Fernandes (Google)"
Directories and inodes don't necessarily need to be in the same
lockdep class. For ex, hugetlbfs splits them out too to prevent
false positives in lockdep. Annotate correctly after new inode
creation. If its a directory inode, it will be put into a different
On 08/21/2018 07:07 PM, Tony Krowiak wrote:
On 08/21/2018 11:25 AM, Cornelia Huck wrote:
On Mon, 20 Aug 2018 13:41:32 -0400
Tony Krowiak wrote:
On 08/20/2018 10:23 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Provides the sysfs
On 08/21/2018 07:07 PM, Tony Krowiak wrote:
On 08/21/2018 11:25 AM, Cornelia Huck wrote:
On Mon, 20 Aug 2018 13:41:32 -0400
Tony Krowiak wrote:
On 08/20/2018 10:23 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Provides the sysfs
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[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/Mike
On 08/21/2018 03:03 PM, kbuild test robot wrote:
> Hi Mike,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a no
On 08/21/2018 03:03 PM, kbuild test robot wrote:
> Hi Mike,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a no
1 - 100 of 1128 matches
Mail list logo
