Hi,
switched back to my new mail addres... sorry.
On Wed, Aug 2, 2017 at 5:55 PM, Alexander Aring <alex.aring@xxxxxxxxx> wrote:
> Hi,
>
> 2017-08-02 14:59 GMT-04:00 Alexander Aring <aring@xxxxxxxxxxxx>:
>> Hi,
>>
>> On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@xxxxxx> wrote:
>>> Hi Alex,
>>>
>>> I've changed the Kernel module so that i read the Framebuffer as SRAM and
>>> not as FrameBuffer.
>>> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
>>> 0.
>>>
>>> But the Kernel Module can not identity the frame length any more.
>>>
>>> The Sniffed packages (all Packages have 143 byte length) do not show the
>>> behaviour any more.
>>>
>>> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>>>
>>
>> I think frame buffer read access only.
>>
>> "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
>> during a Frame Buffer read access, or on the radio transceiver’s
>> state change from
>> RX_ON or RX_AACK_ON to another state.", see [0].
>
> Please try this patch:
>
> diff --git a/drivers/net/ieee802154/at86rf230.c
> b/drivers/net/ieee802154/at86rf230.c
> index 548d9d026a85..a54f0a0d3fef 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -709,6 +709,8 @@ at86rf230_rx_read_frame_complete(void *context)
> struct sk_buff *skb;
> u8 len, lqi;
>
> + ieee802154_start_queue(lp->hw);
> +
> len = buf[1];
> if (!ieee802154_is_valid_psdu_len(len)) {
> dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
> @@ -824,6 +826,9 @@ static irqreturn_t at86rf230_isr(int irq, void *data)
>
> disable_irq_nosync(irq);
>
> + if (!lp->is_tx)
> + ieee802154_stop_queue(lp->hw);
> +
> ctx = kzalloc(sizeof(*ctx), GFP_ATOMIC);
> if (!ctx) {
> enable_irq(irq);
>
> I think I know what could be going on...
>
> It's "... to another state."... Maybe when a RX irq occurs during the
> spi async handling there could be some "xmit" callbacks... This will
> change the transceiver into another state... (not directly, but so far
> I know it queues for state change). So when it will automatically go
> into RX_AACK_ON then it will change the state to something else and
> allows framebuffer overwrite.
it could be that there exists a race when stop queue is running and
currently a xmit is going on...
I currently have no idea how to solve it and need to have more details
what happens when the transceiver is in BUSY_RX and we do another
state change? Will it be queued or not (so after BUSY_RX it will
change to RX_ON and then another state)?
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
