All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: "Peter Delevoryas" <pdel@fb.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "patrick@stwcx.xyz" <patrick@stwcx.xyz>,
	"rashmica.g@gmail.com" <rashmica.g@gmail.com>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH 1/1] hw: aspeed_gpio: Fix GPIO array indexing
Date: Mon, 27 Sep 2021 12:05:20 +0200	[thread overview]
Message-ID: <9c12c735-2cb4-0902-7d43-ccba7888b098@kaod.org> (raw)
In-Reply-To: <24C5D588-770A-476C-A329-993619106251@fb.com>

On 9/25/21 16:28, Peter Delevoryas wrote:
> 
>> On Sep 25, 2021, at 4:03 AM, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Hi Peter,
>>
>>> On 9/24/21 08:19, pdel@fb.com wrote:
>>> From: Peter Delevoryas <pdel@fb.com>
>>> The gpio array is declared as a dense array:
>>> ...
>>> qemu_irq gpios[ASPEED_GPIO_NR_PINS];
>>> (AST2500 has 228, AST2400 has 216, AST2600 has 208)
>>> However, this array is used like a matrix of GPIO sets
>>> (e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
>>> size_t offset = set * GPIOS_PER_SET + gpio;
>>> qemu_set_irq(s->gpios[offset], !!(new & mask));
>>> This can result in an out-of-bounds access to "s->gpios" because the
>>> gpio sets do _not_ have the same length. Some of the groups (e.g.
>>> GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
>>> To fix this, I converted the gpio array from dense to sparse, to that
>>> match both the hardware layout and this existing indexing code.
>>
>> This is one logical change: 1 patch
>>
>>> Also, I noticed that some of the property specifications looked wrong:
>>> the lower 8 bits in the input and output u32's correspond to the first
>>> group label, and the upper 8 bits correspond to the last group label.
>>
>> Another logical change: another patch :)
>>
>> So please split this patch in 2. Maybe easier to fix GPIOSetProperties
>> first, then convert from dense to sparse array.
>>
> 
> Good point, I’ll split it up then!

Yes. We can surely merge the GPIOSetProperties patch quickly.

I hope Rashmica has some time to check the second part.
  
Thanks,

C.


> 
>> Regards,
>>
>> Phil.
>>
>>> I looked at the datasheet and several of these declarations seemed
>>> incorrect to me (I was basing it off of the I/O column). If somebody
>>> can double-check this, I'd really appreciate it!
>>> Some were definitely wrong though, like "Y" and "Z" in the 2600.
>>> @@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
>>>       [3] = {0xffffffff,  0xffffffff,  {"M", "N", "O", "P"} },
>>>       [4] = {0xffffffff,  0xffffffff,  {"Q", "R", "S", "T"} },
>>>       [5] = {0xffffffff,  0x0000ffff,  {"U", "V", "W", "X"} },
>>> -    [6] = {0xffffff0f,  0x0fffff0f,  {"Y", "Z", "AA", "AB"} },
>>> +    [6] = {0x0fffffff,  0x0fffffff,  {"Y", "Z", "AA", "AB"} },
>>>       [7] = {0x000000ff,  0x000000ff,  {"AC"} },
>>>   };
>>> @@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
>>>       [1] = {0xffffffff,  0xffffffff,  {"E", "F", "G", "H"} },
>>>       [2] = {0xffffffff,  0xffffffff,  {"I", "J", "K", "L"} },
>>>       [3] = {0xffffffff,  0xffffffff,  {"M", "N", "O", "P"} },
>>> -    [4] = {0xffffffff,  0xffffffff,  {"Q", "R", "S", "T"} },
>>> -    [5] = {0xffffffff,  0x0000ffff,  {"U", "V", "W", "X"} },
>>> -    [6] = {0xffff0000,  0x0fff0000,  {"Y", "Z", "", ""} },
>>> +    [4] = {0xffffffff,  0x00ffffff,  {"Q", "R", "S", "T"} },
>>> +    [5] = {0xffffffff,  0xffffff00,  {"U", "V", "W", "X"} },
>>> +    [6] = {0x0000ffff,  0x0000ffff,  {"Y", "Z", "", ""} },
>>>   };
>>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>>> ---
>>>   hw/gpio/aspeed_gpio.c         | 80 +++++++++++++++--------------------
>>>   include/hw/gpio/aspeed_gpio.h |  5 +--
>>>   2 files changed, 35 insertions(+), 50 deletions(-)



  reply	other threads:[~2021-09-27 10:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24  6:19 [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing pdel
2021-09-24  6:19 ` [PATCH 1/1] " pdel
2021-09-25 11:02   ` Philippe Mathieu-Daudé
2021-09-25 14:28     ` Peter Delevoryas
2021-09-27 10:05       ` Cédric Le Goater [this message]
2021-09-28  3:43 [PATCH 0/1] " pdel
2021-09-28  3:43 ` [PATCH 1/1] " pdel
2021-10-04  9:07   ` Cédric Le Goater
2021-10-04 11:43     ` Cédric Le Goater
2021-10-08  3:19       ` Peter Delevoryas

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=9c12c735-2cb4-0902-7d43-ccba7888b098@kaod.org \
    --to=clg@kaod.org \
    --cc=f4bug@amsat.org \
    --cc=joel@jms.id.au \
    --cc=patrick@stwcx.xyz \
    --cc=pdel@fb.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rashmica.g@gmail.com \
    /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.