From: Allen Pais
On Wed, 17 Feb 2021 14:57:12 +0530, Allen Pais wrote:
> The following out of memory errors are seen on kexec reboot
> from the optee core.
>
> [0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed
> [0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error
On Tue, 10 Nov 2020 11:24:36 -0800, Ray Jui wrote:
Yes it's true that for master write-read events both
IS_S_RD_EVENT_SHIFT and IS_S_RX_EVENT_SHIFT are coming together.
So before the slave starts transmitting data to the master, it should
first read all data from rx-fifo i.e.
On Thu, 5 Nov 2020 15:13:04 +0530, Rayagonda Kokatanur wrote:
>> So the suggestion was to set HW threshold for rx fifo interrupt, not
>> really a SW property. By setting it in DT, makes it easier to
>> customize for target system, module param needs or ioctl makes it
>> dependent on userpsace to
On Wed, 4 Nov 2020 10:01:06 -0800, Ray Jui wrote:
+#define MAX_SLAVE_RX_PER_INT 10
>>>
In patch [3/6], you've enabled IS_S_RX_THLD_SHIFT in slave ISR bitmask,
however it's not actually used in processing rx events.
Instead of hardcoding this threshold here,
On Sun, 11 Oct 2020 23:52:53 +0530, Rayagonda Kokatanur wrote:
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
>
> - } else if (status & BIT(IS_S_RD_EVENT_SHIFT)) {
> - /* Start of SMBUS for Master Read */
> +
x14
[ 371.174458] start_kernel+0x404/0x430
Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave
mode")
Signed-off-by: Dhananjay Phadke
---
drivers/i2c/busses/i2c-bcm-iproc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/i
On 8/7/2020, Florian Fainelli wrote:
> > When i2c client unregisters, synchronize irq before setting
> > iproc_i2c->slave to NULL.
> >
> > (1) disable_irq()
> > (2) Mask event enable bits in control reg
> > (3) Erase slave address (avoid further writes to rx fifo)
> > (4) Flush tx and rx FIFOs
>
x14
[ 371.174458] start_kernel+0x404/0x430
Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave
mode")
Signed-off-by: Dhananjay Phadke
---
drivers/i2c/busses/i2c-bcm-iproc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/i
Ray Jui wrote:
>
> Any progress yet?
>
> I don't know if Dhananjay is actively working on this or not.
>
> Rayagonda, given that you have the I2C slave setup already, do you think
> you can help to to test and above sequence from Wolfram (by using the
> widened delay window as instructed)?
>
Ray Jui wrote:
>>> I think the following sequence needs to be implemented to make this
>>> safe, i.e., after 'synchronize_irq', no further slave interrupt will be
>>> fired.
>>>
>>> In 'bcm_iproc_i2c_unreg_slave':
>>>
>>> 1. Set an atomic variable 'unreg_slave' (I'm bad in names so please come
Ray Jui wrote:
>
> On 7/22/2020 3:41 AM, Wolfram Sang wrote:
> >
> >>> + synchronize_irq(iproc_i2c->irq);
> >>
> >> If one takes a look at the I2C slave ISR routine, there are places where
> >> IRQ can be re-enabled in the ISR itself. What happens after we mask all
> >> slave interrupt and when
xbc
[ 371.170322] arch_call_rest_init+0xc/0x14
[ 371.174458] start_kernel+0x404/0x430
Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave
mode")
Signed-off-by: Dhananjay Phadke
---
drivers/i2c/busses/i2c-bcm-iproc.c | 5 +++--
1 file changed, 3 insertions(+)
This looks good to me, I might chop off these #if 0 'ed functions in
my next round of patches.
Acked-by: Dhananjay Phadke <[EMAIL PROTECTED]>
On 11/5/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains the following cleanups:
> - static functions in .c files s
This looks good to me, I might chop off these #if 0 'ed functions in
my next round of patches.
Acked-by: Dhananjay Phadke [EMAIL PROTECTED]
On 11/5/07, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch contains the following cleanups:
- static functions in .c files shouldn't be marked inline
That "00 0e 1e ..." is netxen's mac address, so sounds like the NIC is
dumping a frame in the skb already freed (and poisoned) by the stack.
I suppose -RT kernels preempt the softirq, giving a chance for this race.
The netxen driver doesn't seem to clear the mapped address of the skb in
rx
That 00 0e 1e ... is netxen's mac address, so sounds like the NIC is
dumping a frame in the skb already freed (and poisoned) by the stack.
I suppose -RT kernels preempt the softirq, giving a chance for this race.
The netxen driver doesn't seem to clear the mapped address of the skb in
rx
16 matches
Mail list logo
