drivers/iommu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Fix two misspellings of "Kconfig".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/iommu/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 6cfd1b5b6e07f038..6c46e1d58987cd11 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -348,14 +348,14 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
an iommu domain will report an abort back to the device and
will not be allowed to pass through the SMMU.
- Any old kernels that existed before this KConfig was
+ Any old kernels that existed before this Kconfig was
introduced would default to _allowing_ bypass (AKA the
equivalent of NO for this config). However the default for
this option is YES because the old behavior is insecure.
There are few reasons to allow unmatched stream bypass, and
even fewer good ones. If saying YES here breaks your board
- you should work on fixing your board. This KConfig option
+ you should work on fixing your board. This Kconfig option
is expected to be removed in the future and we'll simply
hardcode the bypass disable in the code.
--
2.43.0
On 2025-02-19 2:48 pm, Geert Uytterhoeven wrote: > Fix two misspellings of "Kconfig". Honestly after 6 years and no obvious complaints I'd be inclined to just drop those two paragraphs referring to v4.x kernel behaviour, or indeed maybe make a move on the aforementioned removal of the whole thing.... Otherwise, frankly when the same thing is referred to 4 different ways in the space of 6 sentences - "this Kconfig", "this config", "this option", "This Kconfig option", "this config" - I would argue that capitalisation is not the biggest issue with this text ;) Thanks, Robin. > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > drivers/iommu/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 6cfd1b5b6e07f038..6c46e1d58987cd11 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -348,14 +348,14 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT > an iommu domain will report an abort back to the device and > will not be allowed to pass through the SMMU. > > - Any old kernels that existed before this KConfig was > + Any old kernels that existed before this Kconfig was > introduced would default to _allowing_ bypass (AKA the > equivalent of NO for this config). However the default for > this option is YES because the old behavior is insecure. > > There are few reasons to allow unmatched stream bypass, and > even fewer good ones. If saying YES here breaks your board > - you should work on fixing your board. This KConfig option > + you should work on fixing your board. This Kconfig option > is expected to be removed in the future and we'll simply > hardcode the bypass disable in the code. >
Hi Robin,
On Wed, 19 Feb 2025 at 16:16, Robin Murphy <robin.murphy@arm.com> wrote:
> On 2025-02-19 2:48 pm, Geert Uytterhoeven wrote:
> > Fix two misspellings of "Kconfig".
>
> Honestly after 6 years and no obvious complaints I'd be inclined to just
> drop those two paragraphs referring to v4.x kernel behaviour, or indeed
> maybe make a move on the aforementioned removal of the whole thing....
>
> Otherwise, frankly when the same thing is referred to 4 different ways
> in the space of 6 sentences - "this Kconfig", "this config", "this
> option", "This Kconfig option", "this config" - I would argue that
> capitalisation is not the biggest issue with this text ;)
Note that now commit 0d2cdc35e805eb50 ("io_uring: Rename KConfig to
Kconfig") is in next-20250220, these are the only misspellings of
Kconfig in the whole tree. Let's hope they don't spread by copy-'n-paste
;-)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
© 2016 - 2025 Red Hat, Inc.