On 2023/3/25 14:08, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-
On 2023/3/25 14:08, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changi
On 2023/3/25 14:08, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Ya
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapopo
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/sparc/K
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
Users that *
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/sh/mm/K
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensibl
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
Users that
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/nios2/K
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uytterhoeven
Reviewed-by: Zi Yan
Signed-off-by: Mike Rap
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
ar
From: "Mike Rapoport (IBM)"
The default value of ARCH_FORCE_MAX_ORDER matches the generic default
defined in the MM code, the architecture does not support huge pages, so
there is no need to keep ARCH_FORCE_MAX_ORDER option available.
Drop it.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm64/K
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changing MAX_ORDER before actually amending it and
r
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/Kco
From: "Mike Rapoport (IBM)"
Hi,
Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
they all have wrong and misleading prompt and help text for this option.
Besides, some define insane limits for possible values of
ARCH_FORCE_MAX_ORDER, some carefully define ranges only for a s
On 3/24/23 6:42?PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Hi,
>
> Hi Jens,
>
> Thanks for the report.
>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>> case. Beware that this email is
Jens Axboe writes:
> Hi,
Hi Jens,
Thanks for the report.
> I got a report sent to me from mariadb, in where 5.10.158 works fine and
> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
> case. Beware that this email is long, as I'm trying to include
> everything that may be rel
On 3/24/23 6:15 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 3/24/23 1:27?AM, Christophe Leroy wrote:
>>> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
I got a report sent to me from mariadb, in where 5.10.158 works fine and
5.10.162 is broken. And in fact, current 6.3-rc also fa
Jens Axboe writes:
> On 3/24/23 1:27?AM, Christophe Leroy wrote:
>> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>>> case. Beware that this email is l
This is follow up change after 14b5d59a261b ("powerpc/pseries: Fix
formatting to make code look more beautiful") to conform to kernel
coding style.
Signed-off-by: Petr Vaněk
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerp
Hi,
On 23/03/2023 23:34, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 7c4a254d78f89546d0e74a40617ef24c6151c8d1 Add linux-next
> specific files for 20230323
>
> Error/Warning reports:
>
> https://lore.kernel
On Fri, Mar 24, 2023 at 10:30:07AM -0400, Zi Yan wrote:
> On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
>
> > From: "Mike Rapoport (IBM)"
> >
> > Hi,
> >
> > Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
> > they all have wrong and misleading prompt and help text for this o
On Fri, Mar 24, 2023 at 04:14:22PM +, Mark Rutland wrote:
> On Fri, Mar 24, 2023 at 04:43:32PM +0100, Uros Bizjak wrote:
> > On Fri, Mar 24, 2023 at 3:13 PM Mark Rutland wrote:
> > >
> > > On Sun, Mar 05, 2023 at 09:56:19PM +0100, Uros Bizjak wrote:
> > > > Cast _oldp to the type of _ptr to av
On Fri, Mar 24, 2023 at 04:43:32PM +0100, Uros Bizjak wrote:
> On Fri, Mar 24, 2023 at 3:13 PM Mark Rutland wrote:
> >
> > On Sun, Mar 05, 2023 at 09:56:19PM +0100, Uros Bizjak wrote:
> > > Cast _oldp to the type of _ptr to avoid incompatible-pointer-types
> > > warning.
> >
> > Can you give an e
On Fri, Mar 24, 2023 at 3:13 PM Mark Rutland wrote:
>
> On Sun, Mar 05, 2023 at 09:56:19PM +0100, Uros Bizjak wrote:
> > Cast _oldp to the type of _ptr to avoid incompatible-pointer-types warning.
>
> Can you give an example of where we are passing an incompatible pointer?
An example is patch 10/
On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
> they all have wrong and misleading prompt and help text for this option.
>
> Besides, some define insane limits for possible values of
> A
On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-off-by: Mike Rapoport (IBM)
> Acked-
On Sun, Mar 05, 2023 at 09:56:19PM +0100, Uros Bizjak wrote:
> Cast _oldp to the type of _ptr to avoid incompatible-pointer-types warning.
Can you give an example of where we are passing an incompatible pointer?
That sounds indicative of a bug in the caller, but maybe I'm missing some
reason this
On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-off-by: Mike Rapoport (IBM)
> Acked-
On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
> ports as well as the two 10G ports. The SFP slot is now fully supported,
> instead of being modeled as a fixed-link.
>
> Linux hangs around when the serdes is ini
On 3/24/23 1:27?AM, Christophe Leroy wrote:
> Hi,
>
> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>> Hi,
>>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>> case. Beware that this email is long, as
Hi Nick,
On 3/22/23 19:25, Nick Desaulniers wrote:
On Fri, Feb 24, 2023 at 7:58 AM Björn Töpel wrote:
Alexandre Ghiti writes:
+cc linux-kbuild, llvm, Nathan, Nick
On 2/15/23 15:36, Alexandre Ghiti wrote:
From: Alexandre Ghiti
I tried a lot of things, but I struggle to understand, does
On Tue, Mar 14, 2023 at 04:31:51PM +0800, ye.xingc...@zte.com.cn wrote:
> From: Ye Xingchen
>
> crypto/algapi.h is included more than once.
>
> Signed-off-by: Ye Xingchen
> ---
> arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 -
> 1 file changed, 1 deletion(-)
Patch applied. Thanks.
--
Email: H
On Fri, Mar 24, 2023 at 10:08:39AM +0100, Philippe Mathieu-Daudé wrote:
> On 23/3/23 18:36, Andy Shevchenko wrote:
> > Replace open-coded implementations of pci_resource_n() in pci.h.
...
> > #define pci_resource_n(dev, bar) (&(dev)->resource[(bar)])
> > -#define pci_resource_start(dev, bar)
On Fri, Mar 24, 2023 at 10:02:15AM +0100, Philippe Mathieu-Daudé wrote:
> On 23/3/23 18:36, Andy Shevchenko wrote:
> > The pci_bus_for_each_resource() can hide the iterator loop since
> > it may be not used otherwise. With this, we may drop that iterator
> > variable definition.
> >
> > Signed-off
> 2023年3月23日 21:39，Christoph Hellwig 写道：
>
> On Thu, Mar 23, 2023 at 09:07:31PM +, Jiaxun Yang wrote:
>>
>>
>>> 2023年3月23日 07:29，Christoph Hellwig 写道：
>>>
>>> The series looks fine to me. How should we merge it?
>>
>> Perhaps go through dma-mapping tree?
>
> Is patch a 6.3 candidate
On 23/3/23 18:36, Andy Shevchenko wrote:
Replace open-coded implementations of pci_resource_n() in pci.h.
Signed-off-by: Andy Shevchenko
---
include/linux/pci.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index
On 23/3/23 18:36, Andy Shevchenko wrote:
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
---
drivers/eisa/pci_eisa.c | 4 +
On 23/3/23 18:36, Andy Shevchenko wrote:
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Review
Hi,
Le 23/03/2023 à 19:54, Jens Axboe a écrit :
> Hi,
>
> I got a report sent to me from mariadb, in where 5.10.158 works fine and
> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
> case. Beware that this email is long, as I'm trying to include
> everything that may be releva
43 matches
Mail list logo
