On 12/6/18, 11:04 PM, "Daniel Lezcano" wrote:
>
> On 07/12/2018 02:13, Tao Ren wrote:
>> Not sure if I missed any emails from you, but looks like the patch is not
>> included in your tree? Are we planning to include the patch in 4.21 merge
>> window?
>
> Yes, I have it in the tree. I updated
On 12/6/18, 11:04 PM, "Daniel Lezcano" wrote:
>
> On 07/12/2018 02:13, Tao Ren wrote:
>> Not sure if I missed any emails from you, but looks like the patch is not
>> included in your tree? Are we planning to include the patch in 4.21 merge
>> window?
>
> Yes, I have it in the tree. I updated
On 07/12/2018 02:13, Tao Ren wrote:
> On 11/5/18, 11:00 AM, "Tao Ren" wrote:
>
>> On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
>>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
>>> apply ?
>>>
>> Personally I don't think it needs to go to stable, because I don't
On 07/12/2018 02:13, Tao Ren wrote:
> On 11/5/18, 11:00 AM, "Tao Ren" wrote:
>
>> On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
>>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
>>> apply ?
>>>
>> Personally I don't think it needs to go to stable, because I don't
On 11/5/18, 11:00 AM, "Tao Ren" wrote:
> On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
>> apply ?
>>
> Personally I don't think it needs to go to stable, because I don't see any
> functional failures caused by this
On 11/5/18, 11:00 AM, "Tao Ren" wrote:
> On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
>> apply ?
>>
> Personally I don't think it needs to go to stable, because I don't see any
> functional failures caused by this
On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
> apply ?
Personally I don't think it needs to go to stable, because I don't see any
functional failures caused by this invalid register access.
Thanks,
Tao Ren
On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
> apply ?
Personally I don't think it needs to go to stable, because I don't see any
functional failures caused by this invalid register access.
Thanks,
Tao Ren
On 05/11/2018 19:43, Tao Ren wrote:
> On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>>
>> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>>
>>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>>> for masking interrupts on ast2500 chips, and it's not even listed in
>>>
On 05/11/2018 19:43, Tao Ren wrote:
> On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>>
>> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>>
>>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>>> for masking interrupts on ast2500 chips, and it's not even listed in
>>>
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>
> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>
> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly,
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly,
On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
> for masking interrupts on ast2500 chips, and it's not even listed in
> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
> chips.
>
> Similarly,
On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
> for masking interrupts on ast2500 chips, and it's not even listed in
> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
> chips.
>
> Similarly,
TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
for masking interrupts on ast2500 chips, and it's not even listed in
ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
chips.
Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
not
TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
for masking interrupts on ast2500 chips, and it's not even listed in
ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
chips.
Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
not
18 matches
Mail list logo
