On Wed, Jan 6, 2021 at 1:12 PM Miguel Ojeda
wrote:
>
> - Normally, you will want to use scripts/get_maintainer.pl to know
> to whom send a given change. In this case, I am Cc'ing Rob, Geert and
> the devicetree mailing list which were missing.
(Actually Cc'ing Rob.)
Cheers,
Miguel
ng out how this is done.
> Thanks to Miguel Ojeda for extensively commenting on my previous patch.
You're welcome!
A couple tips:
- Normally, you will want to use scripts/get_maintainer.pl to know
to whom send a given change. In this case, I am Cc'ing Rob, Geert and
the devicetree mailing list whic
On Tue, Dec 22, 2020 at 10:03 PM Nick Desaulniers
wrote:
>
> remove_arg_zero is declared as __must_check. Looks like it can return
> -EFAULT on failure.
>
> Cc: Masahiro Yamada
> Cc: Miguel Ojeda
> Reported-by: Guenter Roeck
> Signed-off-by: Nick Desaulniers
Cc'ing Al
Hi Ralf,
Something quick I noticed...
On Tue, Jan 5, 2021 at 4:05 PM Ralf Schlatterbeck wrote:
>
> + display-height-chars:
> +description: Height of the display, in character cells,
Spurious comma instead of period.
Cheers,
Miguel
Hi Ralf,
On Tue, Jan 5, 2021 at 4:04 PM Ralf Schlatterbeck wrote:
>
> Add HD44780 character display connected via I2C I/O expander.
> Re-uses the high-level interface of the existing HD44780 driver.
>
> Signed-off-by: Ralf Schlatterbeck
Thanks for the driver! See a first quick review below.
Hi Linus,
This one is not a bug fix; but it is not a new feature either...
If you prefer changes like this one to be sent in the merge window,
I will re-send it later on.
If this gets into v5.11, then Masahiro is planning to try to make
the warning an error for v5.12. This commit has already
In any case, if no maintainer suggests something else, looks good to
me (and it is no worse than the status quo unless the `pr_err()` can
somehow kill it), so:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Wed, Dec 30, 2020 at 4:55 PM Arnd Bergmann wrote:
>
> Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently
> drop the table and all code referenced from it when CONFIG_CPU_IDLE
> is disabled.
Re-Cc'ing Nick (Arnd's email had a wrong address).
Cheers,
Miguel
On Wed, Dec 30, 2020 at 4:55 PM Arnd Bergmann wrote:
>
> Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently
> drop the table and all code referenced from it when CONFIG_CPU_IDLE
> is disabled.
Looks good,
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Mon, Dec 21, 2020 at 11:02 AM Guenter Roeck wrote:
>
> On 12/20/20 10:18 PM, Masahiro Yamada wrote:
> With a change like this, I'd have expected that there is a coccinelle
> script or similar to ensure that claims made in the commit message
> are true.
It is only a warning -- the compiler
On Mon, Dec 21, 2020 at 7:20 AM Masahiro Yamada wrote:
>
> Sorry for the delay.
No problem!
> Now I sent out the fix for lantiq_etop.c
>
> https://lore.kernel.org/patchwork/patch/1355595/
I saw it, thanks for the Cc!
> The reason of the complication was
> I was trying to merge the following
On Mon, Dec 21, 2020 at 6:01 PM Andrew Lunn wrote:
>
> So please leave the warning in place, and maybe somebody else will
> fully fix it.
For context: the plan is to enable the warning unconditionally
starting with 5.11. After that, the idea is making it an error as soon
as reasonable (e.g. 5.12
On Thu, Dec 17, 2020 at 10:45 PM Pavel Machek wrote:
>
> Well.. not everyone has 32 cores in their notebook.
It is true that complex Rust, like complex C++, does have high
compilation times. But it all depends on how much one relies on
certain language features. Straightforward Rust code is
On Sun, Dec 13, 2020 at 7:21 PM Joe Perches wrote:
>
> clang-format is not a tool to rewrite code only neaten its layout.
>
> coccinelle _might_ be able to do this for limited cases where the
> show function is in the same compilation unit/file, but even then
> it would not be a trivial script.
On Sun, Dec 13, 2020 at 4:38 PM 'Matthias Urlichs' via Clang Built
Linux wrote:
>
> If your change to a function breaks its callers, it's your job to fix
No function has changed. This patch enables a warning (that for some
reason is an error in the case of Guenter).
Even if this was a hard
On Sun, Dec 13, 2020 at 4:16 PM Greg KH wrote:
>
> Because if you get a report of something breaking for your change, you
> need to work to resolve it, not argue about it. Otherwise it needs to
> be dropped/reverted.
Nobody has argued that. In fact, I explicitly said the opposite: "So I
think
On Sun, Dec 13, 2020 at 1:55 PM Guenter Roeck wrote:
>
> Witz komm raus, Du bist umzingelt.
Please, explain this reference. :-)
> The key here is "if nobody complains". I would argue that it is _your_
> responsibility to do those builds, and not the reponsibility of others
> to do it for you.
On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck wrote:
>
> This patch results in:
>
> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of
> 'request_irq' declared with attribute 'warn_unused_result'
>
>
Hi Linus,
This time there have been quite a few changes in auxdisplay thanks to
a refactor by Lars Poeschel to share code in order to introduce a new driver.
I am sending these earlier than usual. Please also note I am using
a different email address than usual, too.
Cheers,
Miguel
The
On Thu, Dec 10, 2020 at 11:35 AM Marco Elver wrote:
>
> It looks like there's no clear MAINTAINER for this. :-/
> It'd still be good to fix this for 5.11.
Richard seems to be the author, not sure if he picks patches (CC'd).
I guess Masahiro or akpm (Cc'd) would be two options; otherwise, I
On Thu, Dec 3, 2020 at 8:26 AM Lukas Bulwahn wrote:
>
> It is not a competition between checkpatch and clang-format, but if it would
> be:
Please note that clang-tidy is a different tool, it is designed to
write lints based on the AST rather than formatting.
> But jokes aside: Dwaipayan Ray, a
ion/doc-guide/sphinx.rst | 2 +-
> Documentation/process/clang-format.rst | 2 +-
Thanks!
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Dec 3, 2020 at 12:55 AM Axel Rasmussen wrote:
>
> This is what clang-format yields. Are you thinking it would be better
> to line everything up with the ( in uffd_error( ?
Yeah, sometimes clang-format cannot do a good job with the 80 column
limit + 8 tabs.
You are definitely not forced
On Sat, Nov 28, 2020 at 8:34 PM Masahiro Yamada wrote:
>
> Revert commit cebc04ba9aeb ("add CONFIG_ENABLE_MUST_CHECK").
>
> A lot of warn_unused_result warnings existed in 2006, but until now
> they have been fixed thanks to people doing allmodconfig tests.
>
> Our goal is to always enable
On Fri, Nov 27, 2020 at 10:51 PM wrote:
>
> From
> RFC MAINTAINERS tag for cleanup robot
> https://lkml.org/lkml/2020/11/21/190
Please use lore.kernel.org for links.
> The prefix used by subsystems in their commit log is arbitrary.
> To elimitate the time and effort to manually find a
On Sat, Nov 21, 2020 at 8:44 PM Masahiro Yamada wrote:
>
> Revert commit cebc04ba9aeb ("add CONFIG_ENABLE_MUST_CHECK").
>
> A lot of warn_unused_result warnings existed in 2006, but until now
> they have been fixed thanks to people doing allmodconfig tests.
>
> Our goal is to always enable
On Fri, Nov 27, 2020 at 10:21 AM Lee Jones wrote:
>
> It's a per-subsystem convention thing.
I think some allow both, too. For people that send tree-wide patches,
it would be if we agreed on the convention...
Cheers,
Miguel
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote:
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
Agreed, I was not blaming maintainers -- just trying to point out that
the problem is there :-)
In those cases, it is
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
>
> To make the intent clear, you have to first be certain that you
> understand the intent; otherwise by adding either a break or a
> fallthrough to suppress the warning you are just destroying the
> information that "the intent of this code
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski wrote:
>
> And just to spell it out,
>
> case ENUM_VALUE1:
> bla();
> break;
> case ENUM_VALUE2:
> bla();
> default:
> break;
>
> is a fairly idiomatic way of indicating that not all values of the enum
> are expected
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.
No, I have not said that. Please don't put words in my mouth (again).
I have said *authoring* lines of *this* kind
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> Well, I used git. It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.
I can see ~10k insertions over
On Mon, Nov 23, 2020 at 4:37 AM Masahiro Yamada wrote:
>
> I can move it to compiler_attribute.h
>
> This attribute is supported by gcc, clang, and icc.
> https://godbolt.org/z/ehd6so
>
> I can send v2.
>
> I do not mind renaming, but it should be done in a separate patch.
Of course -- sorry, I
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches. Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.
Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it? All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions
On Sat, Nov 21, 2020 at 8:44 PM Masahiro Yamada wrote:
>
> Our goal is to always enable __must_check where appreciate, so this
> CONFIG option is no longer needed.
This would be great. It also implies we can then move it to
`compiler_attributes.h` since it does not depend on config options
Hi Gustavo,
On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
Thanks for this.
Since this warning is reliable in both/all compilers and we are
On Wed, Nov 18, 2020 at 1:08 AM Nick Desaulniers
wrote:
>
> It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and
> -include compiler_types.h like the main kernel does, though testing that
> produces a whole sea of warnings to cleanup.
(Re; for Gustavo to consider since he took it
On Mon, Nov 16, 2020 at 2:41 PM wrote:
>
> From: Lars Poeschel
>
> The three struct charlcd_ops contain the same data, so we only need one
> of this structures. The other two are removed.
>
> Signed-off-by: Lars Poeschel
Thanks Lars, picking this up.
Cheers,
Miguel
On Mon, Nov 16, 2020 at 2:22 PM wrote:
>
> From: Lars Poeschel
>
> charlcd drivers need to provide some print function to charlcd. For
> hd44780 based panel driver this function was missing. We provide the
> generic hd44780_common_print function which should be suitable.
>
> Fixes:
cases.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
It makes things clearer having a `break` added, so I like that warning.
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
Looks fine on visual inspection:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
asive.
I would add a comment noting this as a reminder -- it also helps to
entice a cleanup.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Mon, Nov 16, 2020 at 7:26 AM Gustavo A. R. Silva
wrote:
>
> Reviewed-by: Gustavo A. R. Silva
.org :-)
Cheers,
Miguel
On Mon, Nov 16, 2020 at 7:48 AM Ian Rogers wrote:
>
> GCC [0-9]+ :-) Perhaps just a reference to the GCC bug rather than a date.
That would be very good.
> In linux/compiler_attributes.h add:
> #define __GCC4_has_attribute_disable_tail_calls 0
> to the #ifndef __has_attribute block. We can't do
On Sat, Nov 14, 2020 at 9:14 PM Ian Rogers wrote:
>
> Unfortunately no GCC version actually has this fixed.
Then we can say GCC <= 11 does not support it yet or something like that.
> This seems overly complex and unnecessary.
How is 1 condition more complex than 3 different ones?
Cheers,
On Wed, Nov 11, 2020 at 10:26 AM kernel test robot wrote:
>
> From: kernel test robot
>
> drivers/auxdisplay/lcd2s.c:373:3-8: No need to set .owner here. The core will
> do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Generated by:
Hi Zou,
On Sat, Nov 14, 2020 at 9:11 AM Zou Wei wrote:
>
> ./drivers/auxdisplay/lcd2s.c:373:3-8: No need to set .owner here. The core
> will do it.
Thanks a lot for the patch. This patch was already submitted by the
kernel test bot, please see
On Sat, Nov 14, 2020 at 1:08 AM 'Ian Rogers' via Clang Built Linux
wrote:
>
> To ensure the stack frames are on the stack tail calls optimizations
> need to be inhibited. If your compiler supports an attribute use it,
> otherwise use an asm volatile barrier.
>
> The barrier fix was suggested
On Fri, Nov 13, 2020 at 1:09 AM Nick Desaulniers
wrote:
>
> Thank you for the explicit diagnostics observed. Something fishy is
> going on though, https://godbolt.org/z/Gbxbxa is how I expect MSVC to
> handle include/linux/compiler_attributes.h.
>
> The C preprocessor should make it such that
On Thu, Nov 12, 2020 at 10:49 PM Moore, Robert wrote:
>
> 1>c:\acpica\source\components\utilities\utdelete.c(270): warning C4013:
> '__attribute__' undefined; assuming extern returning int
> 1>c:\acpica\source\components\utilities\utdelete.c(270): error C2065:
> '__fallthrough__': undeclared
On Wed, Nov 11, 2020 at 8:19 AM Ard Biesheuvel wrote:
>
> I am still not convinced we need this change, as I don't see how the
> concerns regarding __section apply to __alias. But if we do, can we
> please use the same approach, i.e., revert the current patch, and
> queue it again after v5.11-rc1
Hi Randy,
On Fri, Nov 6, 2020 at 5:35 PM Randy Dunlap wrote:
>
> I'm not sure that I understand the question...
>
> Include
> Reported-by: Randy Dunlap
> if possible. If not, then don't. It's not a big deal.
>
> Integrate the fix from Lars in whatever way works for you.
Thanks Randy -- I asked
On Fri, Nov 6, 2020 at 8:26 PM Dan Carpenter wrote:
>
> The kfree() needs to be moved down a line to prevent a use after free.
Thanks Dan for catching this one up while in -next. I'll pick it up.
Cheers,
Miguel
On Mon, Nov 9, 2020 at 10:32 AM wrote:
>
> From: Lars Poeschel
>
> When building the hd44780_common driver without a driver that actually
> uses it like panel or hd44780 you got a build error, because
> hd44780_common uses charlcd, but did not select it. It's users did
> select it.
> This is
On Sat, Nov 7, 2020 at 8:08 AM Nick Desaulniers wrote:
>
> Partial revert of commit e2079e93f562 ("kbuild: Do not enable
> -Wimplicit-fallthrough for clang for now")
Wait, it says partial revert because it is one, but doing it this way
does not enable the option back for GCC (and Clang).
seudo-keyword in
> commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo
> keyword for switch/case use")
I think the title is missing the "implicit"?
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Nov 6, 2020 at 11:11 AM Lars Poeschel wrote:
>
> I got an email [1] with a report about a build failure in
> hd44780_common. The fix is simple but I don't know the process from here
> on. Should I post a v7 of the whole patchset or only a follow-up patch
> for the fix ?
Either would work
On Thu, Nov 5, 2020 at 1:35 AM Nick Desaulniers wrote:
>
> I'll help you paint your bikeshed. Oh, but what color? I see a red
> door, and I want it painted black.
>
> Sounds to me like Miguel could win over a critic by addressing some of
> your (quite valid) concerns. ;)
I am happy to take the
On Thu, Nov 5, 2020 at 1:33 AM Nick Desaulniers wrote:
>
> Yeah, that's annoying. Why don't you send me a patch that downgrades
> it from hard error to polite warning (in case someone made a typo),
> and I'll review it?
Sure!
Cheers,
Miguel
; clang sources.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Nov 3, 2020 at 10:58 AM wrote:
>
> Changes in v6:
> - patch 2: Fix Kconfig so that auxdisplay is now a submenu again
> - patch 23: Fix some typos in commit message
Thanks a lot for all the work, Lars. Queued in -next.
Cheers,
Miguel
Hi Joe,
First of all, thanks for taking the time to write your reasoning.
On Wed, Nov 4, 2020 at 5:17 AM Joe Perches wrote:
>
> The current kernel is v5.10 which requires clang 10.0 or higher.
For building, yes.
> This patch is not to be applied or backported to old kernels so no
> person is
On Wed, Nov 4, 2020 at 4:15 AM Joe Perches wrote:
>
> No one ever will use clang-format on the current kernel sources
> without having a recent version of clang and clang-format.
Why? Many distros come with clang-format pre-packaged, and in fact the
original patch (that you commented on) argued
On Wed, Nov 4, 2020 at 2:08 AM Nick Desaulniers wrote:
>
> Miguel,
> Really? :P I'd bet if you picked up this patch no one would notice.
>
> I recommend a simpler approach to multiple version support, which is
> just matching the one version recommended for the rest of LLVM tools.
> Sure,
On Wed, Nov 4, 2020 at 1:56 AM Joe Perches wrote:
>
> Do remember that this patch is for the current kernel and
> not any old version that someone might be compiling.
>
> The current kernel _requires_ clang 10.0+ and that would
> obviously provide clang-format 10+ as well.
You can use
Hi Joe,
On Tue, Nov 3, 2020 at 7:29 PM Joe Perches wrote:
>
> Now that the clang minimum supported version is > 10.0, enable the
> commented out conditional reformatting key:value lines in the file.
>
> Signed-off-by: Joe Perches
> ---
>
> Hey Miguel.
>
> I don't use this, but on its face it
Hi Lars,
On Thu, Oct 29, 2020 at 10:52 AM wrote:
>
> Changes in v5:
> - patch 1: Fix a commit message typo: of -> on
> - patch 2: Remove some unnecessary newlines
> - patch 8: Fix some typos
> - patch 14: Fix commit message typo: it's -> its
> - patch 15: this patch is squashed together from the
Hi Lars,
On Thu, Oct 29, 2020 at 10:57 AM wrote:
>
> diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
> index 81757eeded68..a56171d1a1ba 100644
> --- a/drivers/auxdisplay/Kconfig
> +++ b/drivers/auxdisplay/Kconfig
> @@ -14,12 +14,31 @@ menuconfig AUXDISPLAY
>
> If
Hi Lars,
A few extra typos in this commit message.
On Thu, Oct 29, 2020 at 10:58 AM wrote:
>
> Skip printing characters at the end of a display line. This fits to the
> behaviour we already had, that the cursor is nailed to last position of
to last -> to the last
> a line.
> This might
On Fri, Oct 30, 2020 at 4:07 AM Joe Perches wrote:
>
> Like the old __section macro, the __alias macro uses macro # stringification
> to create quotes around the symbol name used in the __attribute__.
Hmm... isn't this V2? It seems none of the Acks/Reviews were picked
up, did something major
On Wed, Oct 28, 2020 at 9:11 AM Peter Zijlstra wrote:
>
> Subject: tools/perf: Remove broken __no_tail_call attribute
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Oct 27, 2020 at 11:37 PM Arnd Bergmann wrote:
>
> Sounds good, I'll take that. Are the clang and icc version numbers
> the actual ones we should list here, or is this just an example?
Actual ones -- well, the best approximation I could get from the
available versions in Compiler Explorer
On Tue, Oct 27, 2020 at 12:57 AM Arnd Bergmann wrote:
>
> +#ifdef __has_builtin
> +#define has_builtin(x) __has_builtin(x)
> +#else
> +#define has_builtin(x) (0)
> +#endif
Could this be
#ifndef __has_builtin
# define __has_builtin(x) 0
#endif
? i.e. mimicking what we do for
f changes is
reasonable too, so no need to apply the script directly. In any case,
if you prefer that Linus picks it up himself right away for this -rc1,
it looks good to me (with the caveat that it isn't tested):
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Oct 22, 2020 at 4:36 AM Joe Perches wrote:
>
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
I performed visual inspection (one by one...) and the only thing I saw
is that sometimes the `__attribute__` has a whitespace
On Wed, Oct 21, 2020 at 8:35 PM Joe Perches wrote:
>
> Perhaps something to add as a generic test in checkpatch.
Agreed! It would be nice to check all of them. Even checking for
`attribute` and `__attribute__` could be potentially reasonable (i.e.
so that people are reminded to consider adding
On Wed, Oct 21, 2020 at 9:07 PM Joe Perches wrote:
>
> Using quotes in __section caused/causes differences
> between clang and gcc.
Yeah, it is a good cleanup get.
Thanks!
> https://lkml.org/lkml/2020/9/29/2187
Can you please put this in a Link: like Ard suggested? (and ideally
find the
On Wed, Oct 21, 2020 at 7:42 PM Nick Desaulniers
wrote:
>
> If you used some of the macros from
> include/linux/compiler_attributes.h like __section and __aligned, I
> would prefer it. Please consider spelling out __attribute__(()) an
> antipattern.
+1, the shorthands should be used unless
On Fri, Oct 16, 2020 at 4:33 AM Miguel Ojeda
wrote:
>
> Picking these for linux-next (including Rob's Reviewed-by). I have
> spotted a few typos that I corrected -- I will note them by email.
Hmm, I think we should do another round instead, since I found what
looks to be an unintend
On Mon, Oct 5, 2020 at 2:27 PM wrote:
>
> We create a hd44780_common_print function. It is derived from the
> original charlcd_print. charlcd_print becomes a device independent print
> function, that then only calles via it's ops function pointers, into the
Typos: calles -> calls, it's -> its
>
On Mon, Oct 5, 2020 at 3:01 PM wrote:
>
> + while (*esc && i < LCD2S_CHARACTER_SIZE + 2) {
> + shift ^= 4;
> + if (*esc >= '0' && *esc <= '9') {
> + value |= (*esc - '0') << shift;
> + } else if (*esc >= 'A' && *esc <= 'Z') {
>
On Mon, Oct 5, 2020 at 3:01 PM wrote:
>
> + while (*esc && cgoffset < 8) {
> + shift ^= 4;
> + if (*esc >= '0' && *esc <= '9') {
> + value |= (*esc - '0') << shift;
> + } else if (*esc >= 'A' && *esc <= 'F') {
> +
On Mon, Oct 5, 2020 at 3:01 PM wrote:
>
> The init_display function is moved over to hd44780_common. charlcd uses
> it via it's ops function pointer and drivers initialize the ops with the
it's -> its
(Already corrected in my queue)
Cheers,
Miguel
On Mon, Oct 5, 2020 at 2:27 PM wrote:
>
> diff --git a/drivers/auxdisplay/hd44780_common.c
> b/drivers/auxdisplay/hd44780_common.c
> new file mode 100644
> index ..073f47397f7d
> --- /dev/null
> +++ b/drivers/auxdisplay/hd44780_common.c
> @@ -0,0 +1,21 @@
> +//
On Mon, Oct 5, 2020 at 2:27 PM wrote:
>
> We use an enum for calling the functions in charlcd, that turn the
> backlight on or off. This enum is generic and can be used for other
> charlcd turn of / turn off operations as well.
Typo: of -> on
(Already corrected in my queue)
Cheers,
Miguel
Hi Lars,
On Tue, Oct 6, 2020 at 10:38 AM Lars Poeschel wrote:
>
> Changes in v4:
> - modtronix -> Modtronix in new lcd2s driver
> - Kconfig: remove "default n" in new lcd2s driver
>
> Changes in v3:
> - Fix some typos in Kconfig stuff
> - Fix kernel test robot reported error: Missed
On Wed, Oct 14, 2020 at 8:05 PM Joe Perches wrote:
>
> Any 'formatting off/on' marker should be tool agnostic.
Agreed, they should have used a compiler-agnostic name for the marker.
Cheers,
Miguel
On Wed, Oct 14, 2020 at 10:40 AM Joe Perches wrote:
>
> Eek no.
>
> Mindless use of either tool isn't a great thing.
That is up to opinion. I (and others) definitely want to get to the
point the kernel sources are automatically formatted, because it has
significant advantages. The biggest is
Hi Lars,
On Mon, Oct 5, 2020 at 2:27 PM wrote:
>
> This tries to make charlcd device independent.
Thanks a lot for the work!
I see you have written the differences between versions in each patch,
but given there are 32 patches, it'd be nice to comment which ones have
changed so that folks that
Hi Jarod,
On Fri, Oct 2, 2020 at 7:44 PM Jarod Wilson wrote:
>
> .clang-format |4 +-> #ifdef
> CONFIG_NET_POLL_CONTROLLER
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Joe,
On Thu, Oct 1, 2020 at 12:56 AM Joe Perches wrote:
>
> So I installed the powerpc cross compiler, and
> nope, that doesn't work, it makes a mess.
Thanks a lot for reviving the script and sending the treewide cleanup!
> So it looks like the best option is to exclude these
> 2 files from
Hi Nick,
On Tue, Sep 29, 2020 at 9:43 PM Nick Desaulniers
wrote:
>
> The stringification operator, `#`, in the preprocessor escapes strings.
> For example, `# "foo"` becomes `"\"foo\""`. GCC and Clang differ in how
> they treat section names that contain \".
>
> The portable solution is to not
Hi Lars,
On Mon, Sep 21, 2020 at 4:47 PM wrote:
>
> This tries to make charlcd device independent.
Thanks a lot for the series!
> [1] https://marc.info/?l=linux-kernel=157121432124507
Nit: please use lore.kernel.org and the Link: tag instead.
Cheers,
Miguel
Hi Lars, Willy,
On Tue, Sep 22, 2020 at 12:04 PM Willy Tarreau wrote:
>
> The points you mention are good enough indicators that it's extremely
> unlikely anyone has ever used that feature with these drivers. So I
> think it's best to keep your changes and wait to see if anyone pops
> up with an
Hi Linus,
Luc requested me to pick a sparse fix on my queue, so here it goes
along with other two trivial Compiler Attributes ones (also from Luc).
Cheers,
Miguel
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are
101 - 200 of 1034 matches
Mail list logo
