Return-Path: Date: Mon, 7 Dec 2015 14:25:12 +0100 From: Alexander Aring To: Michael Hennerich Cc: Stefan Schmidt , marcel@holtmann.org, linux-wpan@vger.kernel.org, linux-bluetooth@vger.kernel.org Subject: Re: [PATCH] drivers/net/ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154 Message-ID: <20151207132506.GA20826@omega> References: <1449220149-14096-1-git-send-email-michael.hennerich@analog.com> <566181E6.9070306@osg.samsung.com> <56657561.70305@osg.samsung.com> <56657926.5070604@analog.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <56657926.5070604@analog.com> List-ID: Hi, On Mon, Dec 07, 2015 at 01:18:46PM +0100, Michael Hennerich wrote: > On 12/07/2015 01:02 PM, Stefan Schmidt wrote: > >Hello. > > > >I found some time at the weekend hooking it up on my raspberry pi. > > > >On 04/12/15 13:07, Stefan Schmidt wrote: > >>Hello. > >> > >>On 04/12/15 10:09, michael.hennerich@analog.com wrote: > >> > >>>The ADF7242 requires an add-on firmware for the automatic IEEE 802.15.4 > >>>operating modes. The firmware file is currently made available on the > >>>ADF7242 wiki page here [1] > >> > >>Just being curious here. Is there any way to get the firmware source > >>and/or compile your own? Its the first hardware for IEEE 802.15.4 I > >>have seen that have a special firmware for this which triggers my > >>curiosity. :) > > > Unfortunately No - We don't release the firmware assembly code. > Or the required compiler. > > > >> > >>Anyway, this has not that much to do with the driver review here as it > >>can obviously go in with the binary firmware. We just need to make > >>sure to also bring the firmware into the linux-firmware repo in time. > >> > >>>[1] > >>>http://wiki.analog.com/resources/tools-software/linux-drivers/networking-mac802154/adf7242 > >>> > > > >There are two firmware zip files listed: > >ram_lab_7242_2_0_ieee15dot4_full_r5.zip > > > > > >rom_ram_7242_2_0_ieee15dot4_full_r3.zip > > > > > > > >Both contain a adf7242_firmware.bin file but also some different data > >file. Which one is the correct one here? Some explanation would be helpful. > > Please use the latest R5 release file. I'll remove the old one soon. > The older firmware had problems with the back-off exponent randomization. > > > > > > > >>>[2] > >>>http://sourceforge.net/p/linux-zigbee/kernel/ci/devel/tree/drivers/ieee802154/adf7242.c > >>> > >>> > >>>Signed-off-by: Michael Hennerich > >>>--- > >>> .../devicetree/bindings/net/ieee802154/adf7242.txt | 18 + > >>> drivers/net/ieee802154/Kconfig | 5 + > >>> drivers/net/ieee802154/Makefile | 1 + > >>> drivers/net/ieee802154/adf7242.c | 1183 > >>>++++++++++++++++++++ > >>> 4 files changed, 1207 insertions(+) > >>> create mode 100644 > >>>Documentation/devicetree/bindings/net/ieee802154/adf7242.txt > >>> create mode 100644 drivers/net/ieee802154/adf7242.c > >>> > >>>diff --git > >>>a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt > >>>b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt > >>>new file mode 100644 > >>>index 0000000..dea5124 > >>>--- /dev/null > >>>+++ b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt > >>>@@ -0,0 +1,18 @@ > >>>+* ADF7242 IEEE 802.15.4 * > >>>+ > >>>+Required properties: > >>>+ - compatible: should be "adi,adf7242" > >>>+ - spi-max-frequency: maximal bus speed (12.5 MHz) > >>>+ - reg: the chipselect index > >>>+ - interrupts: the interrupt generated by the device via pin > >>>IRQ1. > >>>+ IRQ_TYPE_LEVEL_HIGH (4) or IRQ_TYPE_EDGE_FALLING (1) > > > > > >IRQ1 would be pin7 on the interface connector, right? I'm using this one > >but I have trouble when transmitting > > Yes IRQ1 is Pin7 on the PMOD connector. > > > > >adf7242 spi32766.0: Error xmit: Retry count exceeded Status=0x3 > > > That's failure NOACK. Is there a node on the same channel/PAN which could > response? > reading proc/interrupts should show some interrupts in this case... > Stefan, maybe you testing with the ATUSB firmware which going _not_ into RX_AACK_ON. This was one of my lastest changes according to the ATUSB firmware. Please check that, otherwise the atusb doesn't send ack frames if ackrequest bit is set after receiving. - Alex