"
> , "Sean Wang" , "Liam
> Girdwood" , "Rob Herring" ,
> linux-kernel@vger.kernel.org, "Richard Fontana" , "Mark
> Brown" , linux-arm-ker...@lists.infradead.org, "René van
> Dorst" , "Thomas Gleixner" ,
> &quo
Hi
When is new version ready? First 2 patches are still in next for 5.4 and i see
no fix so i guess it is still broken.
Regards Frank
Am 29. August 2019 08:24:36 MESZ schrieb Hsin-hsiung Wang
:
>Hi Frank/Matthias,
>
>Thanks for your comments.
>The root cause seems I didn't split the code well.
Hi Frank/Matthias,
On Fri, 2019-08-23 at 19:16 +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 23. August 2019 um 17:42 Uhr
> > Von: "Matthias Brugger"
>
> > I suppose that's because 3/10 has code that should be in 2/10 and for some
> > reason 3/10 was not pushed for linux-next inclusion.
> Gesendet: Freitag, 23. August 2019 um 17:42 Uhr
> Von: "Matthias Brugger"
> I suppose that's because 3/10 has code that should be in 2/10 and for some
> reason 3/10 was not pushed for linux-next inclusion. Although it has the same
> Acked-for-mfd-by tag.
>
> @Frank, can you test if adding 3/10
Seems chip-id in 5.3 is read here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/mt6397-core.c?h=v5.3-rc5#n282
It is before platform_get_irq which may call irq-init changed in the
problematic commit.
I will add a dev_info here in next-code to see value of id
On 23/08/2019 17:26, Frank Wunderlich wrote:
>
>
> Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger
> :
>> are you sure that you provide the correct chip_id here? I saw 0x2023
>> (if I
>> remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>> so I'm
>> not sure if
As far as i understand does old init-function not rely on the chip-id, so it
seems that with this commit a prior bug is shown.
maybe the chip-id (should be 0x23 like constant) is set later after irq-request
or completely missing for mt6323
Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger
:
>are you sure that you provide the correct chip_id here? I saw 0x2023
>(if I
>remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>so I'm
>not sure if the problem really lies here. I didn't dig into the code to
>find
chip_id is created.
Regards,
Matthias
>
> regards Frank
>
>
>> Gesendet: Freitag, 23. August 2019 um 05:45 Uhr
>> Von: "Hsin-Hsiung Wang"
>> Betreff: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core
>> driver
>>
>> In order to
On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generations of PMICs so far.
>
> Acked-for-mfd-by: Lee Jones
> Signed-off-by: Hsi
Hsiung Wang"
> Betreff: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core
> driver
>
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generati
In order to support different types of irq design, we decide to add
separate irq drivers for different design and keep mt6397 mfd core
simple and reusable to all generations of PMICs so far.
Acked-for-mfd-by: Lee Jones
Signed-off-by: Hsin-Hsiung Wang
---
drivers/mfd/Makefile| 3 +-
12 matches
Mail list logo
