Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > This patch provides kexec_file_ops for "Image"-format kernel. In this > implementation, a binary is always loaded with a fixed offset identified > in text_offset field of its header. > diff --git a/arch/arm64/include/asm/kexec.h

Re: [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > Change this function from static to global so that arm64 can implement > its own arch_kimage_file_post_load_cleanup() later using > kexec_image_post_load_cleanup_default(). Do we need to call kexec_image_post_load_cleanup_default()? All it

Re: [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > Change this function from static to global so that arm64 can implement > its own arch_kimage_file_post_load_cleanup() later using > kexec_image_post_load_cleanup_default(). Do we need to call kexec_image_post_load_cleanup_default()? All it

Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > This patch provides kexec_file_ops for "Image"-format kernel. In this > implementation, a binary is always loaded with a fixed offset identified > in text_offset field of its header. > diff --git a/arch/arm64/include/asm/kexec.h

Re: [RFC net-next 0/5] Support for PHY test modes

On Tue, May 01, 2018 at 10:21:54AM -0700, Florian Fainelli wrote: > On 04/30/2018 04:24 PM, Andrew Lunn wrote: > >> Turning these tests on will typically result in the link partner > >> dropping the link with us, and the interface will be non-functional as > >> far as the data path is concerned

Re: [RFC net-next 0/5] Support for PHY test modes

On Tue, May 01, 2018 at 10:21:54AM -0700, Florian Fainelli wrote: > On 04/30/2018 04:24 PM, Andrew Lunn wrote: > >> Turning these tests on will typically result in the link partner > >> dropping the link with us, and the interface will be non-functional as > >> far as the data path is concerned

Re: [RFC] vfs: skip extra attributes check on removal for symlinks

On Tue, May 01, 2018 at 10:23:19AM -0700, Darrick J. Wong wrote: > On Thu, Apr 26, 2018 at 04:46:39PM -0700, Luis R. Rodriguez wrote: > > Linux filesystems cannot set extra file attributes (stx_attributes as per > > statx(2)) on a symbolic link. To set extra file attributes you issue > > ioctl(2)

Re: [RFC] vfs: skip extra attributes check on removal for symlinks

On Tue, May 01, 2018 at 10:23:19AM -0700, Darrick J. Wong wrote: > On Thu, Apr 26, 2018 at 04:46:39PM -0700, Luis R. Rodriguez wrote: > > Linux filesystems cannot set extra file attributes (stx_attributes as per > > statx(2)) on a symbolic link. To set extra file attributes you issue > > ioctl(2)

[PATCH] net: ethernet: ti: cpsw: fix packet leaking in dual_mac mode

In dual_mac mode packets arrived on one port should not be forwarded by switch hw to another port. Only Linux Host can forward packets between ports. The below test case (reported in [1]) shows that packet arrived on one port can be leaked to anoter (reproducible with dual port evms): - connect

[PATCH] net: ethernet: ti: cpsw: fix packet leaking in dual_mac mode

In dual_mac mode packets arrived on one port should not be forwarded by switch hw to another port. Only Linux Host can forward packets between ports. The below test case (reported in [1]) shows that packet arrived on one port can be leaked to anoter (reproducible with dual port evms): - connect

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Tue, 1 May 2018, Kees Cook wrote: > On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes > wrote: > > On 2018-04-30 22:16, Matthew Wilcox wrote: > >> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote: > >>> > >>> Getting the constant ordering right could be

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Tue, 1 May 2018, Kees Cook wrote: > On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes > wrote: > > On 2018-04-30 22:16, Matthew Wilcox wrote: > >> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote: > >>> > >>> Getting the constant ordering right could be part of the macro > >>>

Re: [PATCH] ata: fix spelling mistake: "directon" -> "direction"

On Sun, Apr 29, 2018 at 01:01:11PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in sil24_cerr_info message text > > Signed-off-by: Colin Ian King Applied to libata/for-4.17-fixes. Thanks. -- tejun

Re: [PATCH] ata: fix spelling mistake: "directon" -> "direction"

On Sun, Apr 29, 2018 at 01:01:11PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in sil24_cerr_info message text > > Signed-off-by: Colin Ian King Applied to libata/for-4.17-fixes. Thanks. -- tejun

Donation

Greetings To You, My Name is Mavis Wanczyk , the winner of the Power ball jackpot of $ $758.7 million in the AUGUST 24, 2017, My jackpot was a miracle to me hence my Entire family/foundation has AGREED to do this. My foundation is donating $500,000.00 USD to you. for you to help the orphans in

Donation

Greetings To You, My Name is Mavis Wanczyk , the winner of the Power ball jackpot of $ $758.7 million in the AUGUST 24, 2017, My jackpot was a miracle to me hence my Entire family/foundation has AGREED to do this. My foundation is donating $500,000.00 USD to you. for you to help the orphans in

[RFC][PATCH] memcg: Replace mm->owner with mm->memcg

Recently it was reported that mm_update_next_owner could get into cases where it was executing it's fallback for_each_process part of the loop and thus taking up a lot of time. To deal with this replace mm->owner with mm->memcg. This just reduces the complexity of everything. As much as

[RFC][PATCH] memcg: Replace mm->owner with mm->memcg

Recently it was reported that mm_update_next_owner could get into cases where it was executing it's fallback for_each_process part of the loop and thus taking up a lot of time. To deal with this replace mm->owner with mm->memcg. This just reduces the complexity of everything. As much as

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Tue, May 01 2018 at 10:42 -0600, Doug Anderson wrote: Hi, On Tue, May 1, 2018 at 9:10 AM, Lina Iyer wrote: Yes, this is incorrect in its current form. This is what it should be - static int find_match(const struct tcs_group *tcs, const struct tcs_cmd *cmd,

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Tue, May 01 2018 at 10:42 -0600, Doug Anderson wrote: Hi, On Tue, May 1, 2018 at 9:10 AM, Lina Iyer wrote: Yes, this is incorrect in its current form. This is what it should be - static int find_match(const struct tcs_group *tcs, const struct tcs_cmd *cmd, int len) {

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > diff --git a/drivers/net/phy/phy-tests.c b/drivers/net/phy/phy-tests.c ... > +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined > + * test modes > + * @phydev: the PHY device instance > + * @test: the desired test mode > + * @data: test specific data (none) > +

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > diff --git a/drivers/net/phy/phy-tests.c b/drivers/net/phy/phy-tests.c ... > +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined > + * test modes > + * @phydev: the PHY device instance > + * @test: the desired test mode > + * @data: test specific data (none) > +

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

On Tue, May 1, 2018 at 12:41 PM, Steve Grubb wrote: > On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote: >> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote: >> > The decision to log a seccomp action will always be subject to the >> > value of

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

On Tue, May 1, 2018 at 12:41 PM, Steve Grubb wrote: > On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote: >> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote: >> > The decision to log a seccomp action will always be subject to the >> > value of the kernel.seccomp.actions_logged sysctl,

Re: [PATCH] bsg referencing bus driver module

Any comments on the new patch (which, I think, addresses the concern about module being stuck in unloadable state forever; if not, there would be a leak in the bsg layer)? Or on dropping a reference to bsg_class_device's parent early before the bsg_class_device itself is gone, to implement James's

Re: [PATCH] bsg referencing bus driver module

Any comments on the new patch (which, I think, addresses the concern about module being stuck in unloadable state forever; if not, there would be a leak in the bsg layer)? Or on dropping a reference to bsg_class_device's parent early before the bsg_class_device itself is gone, to implement James's

Re: [RFC] vfs: skip extra attributes check on removal for symlinks

On Thu, Apr 26, 2018 at 04:46:39PM -0700, Luis R. Rodriguez wrote: > Linux filesystems cannot set extra file attributes (stx_attributes as per > statx(2)) on a symbolic link. To set extra file attributes you issue > ioctl(2) with FS_IOC_SETFLAGS, *all* ioctl(2) calls on a symbolic link > yield

Re: [RFC] vfs: skip extra attributes check on removal for symlinks

On Thu, Apr 26, 2018 at 04:46:39PM -0700, Luis R. Rodriguez wrote: > Linux filesystems cannot set extra file attributes (stx_attributes as per > statx(2)) on a symbolic link. To set extra file attributes you issue > ioctl(2) with FS_IOC_SETFLAGS, *all* ioctl(2) calls on a symbolic link > yield

Re: [RFC net-next 0/5] Support for PHY test modes

On 04/30/2018 04:24 PM, Andrew Lunn wrote: >> Turning these tests on will typically result in the link partner >> dropping the link with us, and the interface will be non-functional as >> far as the data path is concerned (similar to an isolation mode). This >> might warrant properly reporting

Re: [RFC net-next 0/5] Support for PHY test modes

On 04/30/2018 04:24 PM, Andrew Lunn wrote: >> Turning these tests on will typically result in the link partner >> dropping the link with us, and the interface will be non-functional as >> far as the data path is concerned (similar to an isolation mode). This >> might warrant properly reporting

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

ebied...@xmission.com (Eric W. Biederman) writes: > Kirill Tkhai do you think you would be able adapt Michal Hoko's old > patch at https://marc.info/?l=linux-kernel=143635857131756=2 > that replaces mm->owner with mm->memcg? Ouch. At least compared to the current kernel your patch is wide of

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

ebied...@xmission.com (Eric W. Biederman) writes: > Kirill Tkhai do you think you would be able adapt Michal Hoko's old > patch at https://marc.info/?l=linux-kernel=143635857131756=2 > that replaces mm->owner with mm->memcg? Ouch. At least compared to the current kernel your patch is wide of

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 06:50:51PM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: >> On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: >> >Hi Sasha, >> > >> >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: >> >> - For some

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 06:50:51PM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: >> On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: >> >Hi Sasha, >> > >> >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: >> >> - For some

Re: [PATCH] vhost: make msg padding explicit

On Tue, May 01, 2018 at 11:28:22AM -0400, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Fri, 27 Apr 2018 19:02:05 +0300 > > > There's a 32 bit hole just after type. It's best to > > give it a name, this way compiler is forced to initialize > > it with rest of the

Re: [PATCH] vhost: make msg padding explicit

On Tue, May 01, 2018 at 11:28:22AM -0400, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Fri, 27 Apr 2018 19:02:05 +0300 > > > There's a 32 bit hole just after type. It's best to > > give it a name, this way compiler is forced to initialize > > it with rest of the structure. > > > >

Re: [PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

On Tue, 2018-05-01 at 03:08 +, Greg Thelen wrote: > On Mon, Apr 30, 2018 at 4:35 PM Jason Gunthorpe wrote: > > > On Wed, Apr 25, 2018 at 03:33:39PM -0700, Greg Thelen wrote: > > > INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. > > > So declare the

Re: [PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

On Tue, 2018-05-01 at 03:08 +, Greg Thelen wrote: > On Mon, Apr 30, 2018 at 4:35 PM Jason Gunthorpe wrote: > > > On Wed, Apr 25, 2018 at 03:33:39PM -0700, Greg Thelen wrote: > > > INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. > > > So declare the kconfig dependency.

Re: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

On 04/30/2018 04:20 PM, Andrew Lunn wrote: >> +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined >> + * test modes >> + * @phydev: the PHY device instance >> + * @test: the desired test mode >> + * @data: test specific data (none) >> + * >> + * This function makes the

Re: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

On 04/30/2018 04:20 PM, Andrew Lunn wrote: >> +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined >> + * test modes >> + * @phydev: the PHY device instance >> + * @test: the desired test mode >> + * @data: test specific data (none) >> + * >> + * This function makes the

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes wrote: > On 2018-04-30 22:16, Matthew Wilcox wrote: >> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote: >>> >>> Getting the constant ordering right could be part of the macro >>> definition, maybe? i.e.: >>> >>>

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes wrote: > On 2018-04-30 22:16, Matthew Wilcox wrote: >> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote: >>> >>> Getting the constant ordering right could be part of the macro >>> definition, maybe? i.e.: >>> >>> static inline void

Re: Suboptimal inline heuristics due to non-code sections

Linus Torvalds wrote: > On Tue, May 1, 2018 at 9:46 AM Nadav Amit wrote: > >> My bad. It’s not the new-line. Let me do some more digging. > > From the gcc docs: > > Some targets require that GCC track the size of each instruction used > in

Re: Suboptimal inline heuristics due to non-code sections

Linus Torvalds wrote: > On Tue, May 1, 2018 at 9:46 AM Nadav Amit wrote: > >> My bad. It’s not the new-line. Let me do some more digging. > > From the gcc docs: > > Some targets require that GCC track the size of each instruction used > in order to generate correct code. Because the

Re: Suboptimal inline heuristics due to non-code sections

On Tue, May 1, 2018 at 9:46 AM Nadav Amit wrote: > My bad. It’s not the new-line. Let me do some more digging. From the gcc docs: Some targets require that GCC track the size of each instruction used in order to generate correct code. Because the final length of the

Re: Suboptimal inline heuristics due to non-code sections

On Tue, May 1, 2018 at 9:46 AM Nadav Amit wrote: > My bad. It’s not the new-line. Let me do some more digging. From the gcc docs: Some targets require that GCC track the size of each instruction used in order to generate correct code. Because the final length of the code produced by

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: > On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: > >Hi Sasha, > > > >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > >> - For some reason, the odds of a -rc commit to be targetted for -stable is > >> over

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: > On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: > >Hi Sasha, > > > >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > >> - For some reason, the odds of a -rc commit to be targetted for -stable is > >> over

Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list

On 18/04/18 14:34, Alban wrote: On Wed, 18 Apr 2018 13:53:56 +0100 Srinivas Kandagatla wrote: On 18/04/18 13:32, Alban wrote: I was also suggesting you to use nvmem-cell subnode, but make it a proper nvmem provider device, rather than reusing its parent

Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list

On 18/04/18 14:34, Alban wrote: On Wed, 18 Apr 2018 13:53:56 +0100 Srinivas Kandagatla wrote: On 18/04/18 13:32, Alban wrote: I was also suggesting you to use nvmem-cell subnode, but make it a proper nvmem provider device, rather than reusing its parent device. You would end up some thing

Re: Suboptimal inline heuristics due to non-code sections

On Tue, May 1, 2018 at 9:39 AM Nadav Amit wrote: > Would it be reasonable to remove new-lines in such cases? Yeah, that may be fine for some of our (already illegible) section crud. Linus

Re: Suboptimal inline heuristics due to non-code sections

On Tue, May 1, 2018 at 9:39 AM Nadav Amit wrote: > Would it be reasonable to remove new-lines in such cases? Yeah, that may be fine for some of our (already illegible) section crud. Linus

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi Lina, On Tue, May 01, 2018 at 10:10:10AM -0600, Lina Iyer wrote: > On Fri, Apr 27 2018 at 17:24 -0600, Doug Anderson wrote: > > Hi, > > > > On Fri, Apr 27, 2018 at 2:54 PM, Matthias Kaehlcke > > wrote: > > > > > Am I getting something wrong here? > > > > > > > > The

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi Lina, On Tue, May 01, 2018 at 10:10:10AM -0600, Lina Iyer wrote: > On Fri, Apr 27 2018 at 17:24 -0600, Doug Anderson wrote: > > Hi, > > > > On Fri, Apr 27, 2018 at 2:54 PM, Matthias Kaehlcke > > wrote: > > > > > Am I getting something wrong here? > > > > > > > > The for_each_set_bit()

Re: Suboptimal inline heuristics due to non-code sections

Nadav Amit wrote: > Linus Torvalds wrote: > >> On Tue, May 1, 2018 at 6:40 AM Josh Poimboeuf wrote: >> >>> But if I remove the section completely by removing the >>> pushsection/popsection, then copy_overflow() gets

Re: Suboptimal inline heuristics due to non-code sections

Nadav Amit wrote: > Linus Torvalds wrote: > >> On Tue, May 1, 2018 at 6:40 AM Josh Poimboeuf wrote: >> >>> But if I remove the section completely by removing the >>> pushsection/popsection, then copy_overflow() gets inlined. >> >>> So GCC's inlining decisions are somehow influenced by the

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, May 1, 2018 at 7:24 AM Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:42:03 -0700 > Joel Fernandes wrote: > > In recent tests with IRQ on/off tracepoints, a large performance > > overhead ~10% is noticed when running hackbench. This is root

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, May 1, 2018 at 7:24 AM Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:42:03 -0700 > Joel Fernandes wrote: > > In recent tests with IRQ on/off tracepoints, a large performance > > overhead ~10% is noticed when running hackbench. This is root caused to > > calls to rcu_irq_enter_irqson

stall/hang on 4.15 kernel with some Xeon skylake CPUs and extended APIC

Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC (x2apic) is enabled in the BIOS. The issue happens on specific CPUs only and follows the CPUs. We had (4) quad socket systems with Xeon 6134 CPUs; 2 out of 4 were

stall/hang on 4.15 kernel with some Xeon skylake CPUs and extended APIC

Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC (x2apic) is enabled in the BIOS. The issue happens on specific CPUs only and follows the CPUs. We had (4) quad socket systems with Xeon 6134 CPUs; 2 out of 4 were

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi, On Tue, May 1, 2018 at 9:10 AM, Lina Iyer wrote: > Yes, this is incorrect in its current form. This is what it should be - > > static int find_match(const struct tcs_group *tcs, const struct tcs_cmd > *cmd, > int len) > { >int i, j; > >

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi, On Tue, May 1, 2018 at 9:10 AM, Lina Iyer wrote: > Yes, this is incorrect in its current form. This is what it should be - > > static int find_match(const struct tcs_group *tcs, const struct tcs_cmd > *cmd, > int len) > { >int i, j; > >/* Check for

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote: > On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote: > > The decision to log a seccomp action will always be subject to the > > value of the kernel.seccomp.actions_logged sysctl, even for processes > > that are

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote: > On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote: > > The decision to log a seccomp action will always be subject to the > > value of the kernel.seccomp.actions_logged sysctl, even for processes > > that are being inspected via the

Re: Suboptimal inline heuristics due to non-code sections

Linus Torvalds wrote: > On Tue, May 1, 2018 at 6:40 AM Josh Poimboeuf wrote: > >> But if I remove the section completely by removing the >> pushsection/popsection, then copy_overflow() gets inlined. > >> So GCC's inlining decisions are

Re: Suboptimal inline heuristics due to non-code sections

Linus Torvalds wrote: > On Tue, May 1, 2018 at 6:40 AM Josh Poimboeuf wrote: > >> But if I remove the section completely by removing the >> pushsection/popsection, then copy_overflow() gets inlined. > >> So GCC's inlining decisions are somehow influenced by the existence of >> some random

bug-introducing patches

Working on AUTOSEL, it became even more obvious to me how difficult it is for a patch to get a proper review. Maintainers found it difficult to keep up with the upstream work for their subsystem, and reviewing additional -stable patches put even more load on them which some suggested would be more

bug-introducing patches

Working on AUTOSEL, it became even more obvious to me how difficult it is for a patch to get a proper review. Maintainers found it difficult to keep up with the upstream work for their subsystem, and reviewing additional -stable patches put even more load on them which some suggested would be more

Re: [PATCH 04/21] bindings: display: Add compatible for A64 DE2 pipeline

On Tue, May 1, 2018 at 11:31 AM, Chen-Yu Tsai wrote: > On Wed, May 2, 2018 at 12:17 AM, Rob Herring wrote: >> On Mon, Apr 30, 2018 at 05:10:41PM +0530, Jagan Teki wrote: >>> Allwinner A64 has DE2 pipeline similar to other Allwinner >>> SOC's like A83T, H3/H5. >>

Re: [PATCH 04/21] bindings: display: Add compatible for A64 DE2 pipeline

On Tue, May 1, 2018 at 11:31 AM, Chen-Yu Tsai wrote: > On Wed, May 2, 2018 at 12:17 AM, Rob Herring wrote: >> On Mon, Apr 30, 2018 at 05:10:41PM +0530, Jagan Teki wrote: >>> Allwinner A64 has DE2 pipeline similar to other Allwinner >>> SOC's like A83T, H3/H5. >> >> 'dt-bindings: ' for the

Re: [PATCH 01/21] dt-bindings: clock: Add compatible for A64 DE2 CCU

On Tue, May 1, 2018 at 11:19 AM, Chen-Yu Tsai wrote: > On Wed, May 2, 2018 at 12:16 AM, Rob Herring wrote: >> On Mon, Apr 30, 2018 at 05:10:38PM +0530, Jagan Teki wrote: >>> Allwinner A64 has DE2 CCU which is similar to H3/H5 SoC. >>> >>> Signed-off-by: Jagan Teki

Re: [PATCH 01/21] dt-bindings: clock: Add compatible for A64 DE2 CCU

On Tue, May 1, 2018 at 11:19 AM, Chen-Yu Tsai wrote: > On Wed, May 2, 2018 at 12:16 AM, Rob Herring wrote: >> On Mon, Apr 30, 2018 at 05:10:38PM +0530, Jagan Teki wrote: >>> Allwinner A64 has DE2 CCU which is similar to H3/H5 SoC. >>> >>> Signed-off-by: Jagan Teki >>> --- >>>

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Wed, Apr 18, 2018 at 07:20:10PM +0300, Michael S. Tsirkin wrote: > On Wed, Apr 18, 2018 at 08:47:10AM +0530, Anshuman Khandual wrote: > > On 04/15/2018 05:41 PM, Christoph Hellwig wrote: > > > On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote: > > implemented as DMA

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Wed, Apr 18, 2018 at 07:20:10PM +0300, Michael S. Tsirkin wrote: > On Wed, Apr 18, 2018 at 08:47:10AM +0530, Anshuman Khandual wrote: > > On 04/15/2018 05:41 PM, Christoph Hellwig wrote: > > > On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote: > > implemented as DMA

Re: [V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On Tue, May 01, 2018 at 07:31:36AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Perf stat doesn't count the uncore event aliases from the same uncore > block in a group, for example: > > perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I

Re: [V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On Tue, May 01, 2018 at 07:31:36AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Perf stat doesn't count the uncore event aliases from the same uncore > block in a group, for example: > > perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 > # time

Re: [PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

On Tue, 01 May 2018 09:14:39 PDT (-0700), r...@kernel.org wrote: On Sat, Apr 28, 2018 at 10:37:56PM +, Wesley Terpstra wrote: Will do, thanks! Don't top post to lists. I've applied this. I assume you'll have things other than the PWM... Thanks! We have a handful of out-of-tree drivers

Re: [PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

On Tue, 01 May 2018 09:14:39 PDT (-0700), r...@kernel.org wrote: On Sat, Apr 28, 2018 at 10:37:56PM +, Wesley Terpstra wrote: Will do, thanks! Don't top post to lists. I've applied this. I assume you'll have things other than the PWM... Thanks! We have a handful of out-of-tree drivers

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On Tue, 01 May 2018 14:25:54 +0100, Bjorn Helgaas wrote: Hi Bjorn, > On Tue, May 01, 2018 at 01:59:20PM +0100, Marc Zyngier wrote: > > On 01/05/18 13:38, Sinan Kaya wrote: > > > +Marc, > > > > > > On 4/30/2018 5:27 PM, Sinan Kaya wrote: > > >> On 4/30/2018 5:17 PM, Bjorn Helgaas wrote: > >

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On Tue, 01 May 2018 14:25:54 +0100, Bjorn Helgaas wrote: Hi Bjorn, > On Tue, May 01, 2018 at 01:59:20PM +0100, Marc Zyngier wrote: > > On 01/05/18 13:38, Sinan Kaya wrote: > > > +Marc, > > > > > > On 4/30/2018 5:27 PM, Sinan Kaya wrote: > > >> On 4/30/2018 5:17 PM, Bjorn Helgaas wrote: > >

Re: [PATCH 04/21] bindings: display: Add compatible for A64 DE2 pipeline

On Wed, May 2, 2018 at 12:17 AM, Rob Herring wrote: > On Mon, Apr 30, 2018 at 05:10:41PM +0530, Jagan Teki wrote: >> Allwinner A64 has DE2 pipeline similar to other Allwinner >> SOC's like A83T, H3/H5. > > 'dt-bindings: ' for the subject prefix. > >> >> Signed-off-by: Jagan Teki

Re: [PATCH 04/21] bindings: display: Add compatible for A64 DE2 pipeline

On Wed, May 2, 2018 at 12:17 AM, Rob Herring wrote: > On Mon, Apr 30, 2018 at 05:10:41PM +0530, Jagan Teki wrote: >> Allwinner A64 has DE2 pipeline similar to other Allwinner >> SOC's like A83T, H3/H5. > > 'dt-bindings: ' for the subject prefix. > >> >> Signed-off-by: Jagan Teki >> --- >>

Re: [PATCH] clk:aspeed: Fix reset bits for PCI/VGA and PECI

Hi Rob, Thanks for your review. Please see my answers inline. On 5/1/2018 8:02 AM, Rob Herring wrote: On Thu, Apr 26, 2018 at 10:22:32AM -0700, Jae Hyun Yoo wrote: This commit fixes incorrect setting of reset bits for PCI/VGA and PECI modules. 1. Reset bit for PCI/VGA is 8. 2. PECI reset bit

Re: [PATCH] clk:aspeed: Fix reset bits for PCI/VGA and PECI

Hi Rob, Thanks for your review. Please see my answers inline. On 5/1/2018 8:02 AM, Rob Herring wrote: On Thu, Apr 26, 2018 at 10:22:32AM -0700, Jae Hyun Yoo wrote: This commit fixes incorrect setting of reset bits for PCI/VGA and PECI modules. 1. Reset bit for PCI/VGA is 8. 2. PECI reset bit

Re: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

On Tue, May 01, 2018 at 10:32:34AM -0400, Liming Sun wrote: > This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver > extension on Mellanox BlueField SoC platform. > > Signed-off-by: Liming Sun > --- > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 >

Re: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

On Tue, May 01, 2018 at 10:32:34AM -0400, Liming Sun wrote: > This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver > extension on Mellanox BlueField SoC platform. > > Signed-off-by: Liming Sun > --- > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 > ++ >

Re: bug-introducing patches (or: -rc cycles suck)

On Mon, Apr 30, 2018 at 09:12:08PM +0200, Julia Lawall wrote: > > >On Mon, 30 Apr 2018, Sasha Levin wrote: > >> Working on AUTOSEL, it became even more obvious to me how difficult it is >> for a patch to get a proper review. Maintainers found it difficult to keep >> up with the upstream work for

Re: bug-introducing patches (or: -rc cycles suck)

On Mon, Apr 30, 2018 at 09:12:08PM +0200, Julia Lawall wrote: > > >On Mon, 30 Apr 2018, Sasha Levin wrote: > >> Working on AUTOSEL, it became even more obvious to me how difficult it is >> for a patch to get a proper review. Maintainers found it difficult to keep >> up with the upstream work for

Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs

On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki wrote: > Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them > as default. > > Signed-off-by: Jagan Teki > --- > drivers/clk/sunxi-ng/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > >

Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs

On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki wrote: > Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them > as default. > > Signed-off-by: Jagan Teki > --- > drivers/clk/sunxi-ng/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/sunxi-ng/Kconfig

Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role

On Tue, May 01, 2018 at 03:26:57PM +0200, Paul Kocialkowski wrote: > Hi, > > Le mardi 01 mai 2018 à 07:25 -0500, Bin Liu a écrit : > > On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote: > > > Hi, > > > > > > Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit : > > > > Okay,

Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role

On Tue, May 01, 2018 at 03:26:57PM +0200, Paul Kocialkowski wrote: > Hi, > > Le mardi 01 mai 2018 à 07:25 -0500, Bin Liu a écrit : > > On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote: > > > Hi, > > > > > > Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit : > > > > Okay,

Re: [PATCH 12/21] bindings: display: Add compatible for A64 tcon-tv

On Mon, Apr 30, 2018 at 05:10:49PM +0530, Jagan Teki wrote: > tcon-tv on Allwinner A64 has similar behavior like Allwinner A83T. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1

Re: [PATCH 12/21] bindings: display: Add compatible for A64 tcon-tv

On Mon, Apr 30, 2018 at 05:10:49PM +0530, Jagan Teki wrote: > tcon-tv on Allwinner A64 has similar behavior like Allwinner A83T. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH 11/21] bindings: display: Add compatible for A64 Mixer1

On Mon, Apr 30, 2018 at 05:10:48PM +0530, Jagan Teki wrote: > Mixer1 on Allwinner A64 has similar behavior like Allwinner A83T. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1 insertion(+)

Re: [PATCH 11/21] bindings: display: Add compatible for A64 Mixer1

On Mon, Apr 30, 2018 at 05:10:48PM +0530, Jagan Teki wrote: > Mixer1 on Allwinner A64 has similar behavior like Allwinner A83T. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH 10/21] drm/sun4i: Enable DesignWare HDMI for Allwinner 64-bit SoCs

On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki wrote: > Allwinner 64-bit SoC like H5/A64 has DesignWare HDMI so > enable them as default. Should we not also enable it by default for SUN8I (A83T, H3, R40?, etc.) > Signed-off-by: Jagan Teki >

Re: [PATCH 10/21] drm/sun4i: Enable DesignWare HDMI for Allwinner 64-bit SoCs

On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki wrote: > Allwinner 64-bit SoC like H5/A64 has DesignWare HDMI so > enable them as default. Should we not also enable it by default for SUN8I (A83T, H3, R40?, etc.) > Signed-off-by: Jagan Teki > --- > drivers/gpu/drm/sun4i/Kconfig | 1 + > 1 file

Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support

On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote: > HDMI on Allwinner A64 has similar behavior like H3/H5, so > reuse the same dts node details for A64. > > Signed-off-by: Jagan Teki > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 >

Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support

On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote: > HDMI on Allwinner A64 has similar behavior like H3/H5, so > reuse the same dts node details for A64. > > Signed-off-by: Jagan Teki > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 > +++ >

<    3   4   5   6   7   8   9   10   11   12   >