All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] MFD fixes for v5.2
Date: Tue, 18 Jun 2019 09:15:53 +0100	[thread overview]
Message-ID: <20190618081553.GL16364@dell> (raw)
In-Reply-To: <CAHk-=wgTL5sYCGxX8+xQqyBRWRUE05GAdL58+UTG8bYwjFxMkw@mail.gmail.com>

On Mon, 17 Jun 2019, Linus Torvalds wrote:

> On Mon, Jun 17, 2019 at 3:01 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Enjoy!
> 
> No.
> 
> This is still entirely wrong.
> 
> You can't just randomly cast an "u32 *" to "unsigned long *".
> 
> It wasn't correct when you did it the other way in regmap_read(), but
> it's also not correct when you now for it this way for
> for_each_set_bit().
> 
> You can do
> 
>     u32 regmap_bits;
>     unsigned long bits;
> 
> and then
> 
>     ret = regmap_read(stmfx->map, STMFX_REG_IRQ_PENDING, &regmap_bits);
>     ...
>     bits = regmap_bits;
>     for_each_set_bit(n, &bits, STMFX_REG_IRQ_SRC_MAX) ..
> 
> but casting pointers at either point is *completely* wrong.
> 
> Yes, yes, it happens to work on little-endian, but on a 64-bit
> big-endian machine, the low 32 bits of the "unsigned int" will have
> absolutely _zero_ overlap with the low 32 bits of the "unsigned long"
> in memory.
> 
> When you moved the cast to for_each_set_bit(), it only moves the
> access of the bogus bits to another place instead.
> 
> So that patch doesn't fix anything at all, it only moves the same error around.

Good catch.  Thank you for taking the time to review Linus.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  parent reply	other threads:[~2019-06-18  8:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 10:00 [GIT PULL] MFD fixes for v5.2 Lee Jones
2019-06-17 17:33 ` Linus Torvalds
2019-06-17 19:05   ` Dan Carpenter
2019-06-17 19:06   ` [PATCH] mfd: stmfx: Fix an endian bug in stmfx_irq_handler() Dan Carpenter
2019-06-17 19:06     ` Dan Carpenter
2019-06-17 19:06     ` Dan Carpenter
2019-06-18  8:16     ` Lee Jones
2019-06-18  8:16       ` Lee Jones
2019-06-18  8:16       ` Lee Jones
2019-06-18 20:55       ` Linus Torvalds
2019-06-18 20:55         ` Linus Torvalds
2019-06-18 20:55         ` Linus Torvalds
2019-06-19  5:58         ` Lee Jones
2019-06-19  5:58           ` Lee Jones
2019-06-19  5:58           ` Lee Jones
2019-06-20 15:18           ` Amelie DELAUNAY
2019-06-20 15:18             ` Amelie DELAUNAY
2019-06-20 15:18             ` Amelie DELAUNAY
2019-06-18  8:15   ` Lee Jones [this message]
2019-06-24 14:34 ` [GIT PULL v2] MFD fixes for v5.2 Lee Jones
2019-06-24 19:45   ` Linus Torvalds
2019-06-25  6:28     ` Lee Jones
2019-06-24 20:05   ` pr-tracker-bot
2019-06-24 20:05 ` [GIT PULL] " pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190618081553.GL16364@dell \
    --to=lee.jones@linaro.org \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.