* Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
From: Stefan Schmidt @ 2016-12-21 13:11 UTC (permalink / raw)
To: Andrey Smirnov, linux-wpan
Cc: Alexander Aring, netdev, linux-kernel, Chris Healy
In-Reply-To: <1482103533-13187-1-git-send-email-andrew.smirnov@gmail.com>
Hello.
On 19/12/16 00:25, Andrey Smirnov wrote:
> Driver code never touches "rstn" signal in atomic context, so there's
> no need to implicitly put such restriction on it by using gpio_set_value
> to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
> fix that.
We need to make sure we are not assuming it can be called in such a
context in the future now. But that is something we can worry about if
it comes up.
> As a an example of where such restriction might be inconvenient,
> consider a hardware design where "rstn" is connected to a pin of I2C/SPI
> GPIO expander chip.
Is this a real life issue you run into?
> Cc: Chris Healy <cphealy@gmail.com>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> drivers/net/ieee802154/at86rf230.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
> index 9f10da6..7700690 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -1710,9 +1710,9 @@ static int at86rf230_probe(struct spi_device *spi)
> /* Reset */
> if (gpio_is_valid(rstn)) {
> udelay(1);
> - gpio_set_value(rstn, 0);
> + gpio_set_value_cansleep(rstn, 0);
> udelay(1);
> - gpio_set_value(rstn, 1);
> + gpio_set_value_cansleep(rstn, 1);
> usleep_range(120, 240);
> }
>
>
Acked-by: Stefan Schmidt <stefan@osg.samsung.com>
regards
Stefan Schmidt
^ permalink raw reply
* Re: at86rf230: Allow slow GPIO pins for "rstn"
From: Nikita Yushchenko @ 2016-12-21 12:30 UTC (permalink / raw)
To: linux-wpan
Cc: Andrey Smirnov, Alexander Aring, netdev, linux-kernel,
Chris Healy, Nikita Yushchenko
In-Reply-To: <1482103533-13187-1-git-send-email-andrew.smirnov@gmail.com>
> Driver code never touches "rstn" signal in atomic context, so there's
> no need to implicitly put such restriction on it by using gpio_set_value
> to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
> fix that.
>
> As a an example of where such restriction might be inconvenient,
> consider a hardware design where "rstn" is connected to a pin of I2C/SPI
> GPIO expander chip.
>
> Cc: Chris Healy <cphealy@gmail.com>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
^ permalink raw reply
* [PATCH wpan-tools v2] wpan-ping: Add the filtering function for frame receiving
From: wsn.iot.xwq @ 2016-12-21 5:49 UTC (permalink / raw)
To: linux-wpan; +Cc: stefan, aar, Xue Wenqian
From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
The filtering for wpan-ping client and server is made by checking frame header.
Signed-off-by: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
---
wpan-ping/wpan-ping.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/wpan-ping/wpan-ping.c b/wpan-ping/wpan-ping.c
index e6df2b4..f825b22 100644
--- a/wpan-ping/wpan-ping.c
+++ b/wpan-ping/wpan-ping.c
@@ -303,6 +303,10 @@ static int measure_roundtrip(struct config *conf, int sd) {
}
gettimeofday(&start_time, NULL);
ret = recv(sd, buf, conf->packet_len, 0);
+ if (buf[0] != NOT_A_6LOWPAN_FRAME) {
+ printf("Non-wpanping packet was received\n");
+ continue;
+ }
if (seq_num != ((buf[2] << 8)| buf[3])) {
printf("Sequenze number did not match\n");
continue;
@@ -386,11 +390,13 @@ static void init_server(int sd) {
#if DEBUG
dump_packet(buf, len);
#endif
- /* Send same packet back */
- len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
- if (len < 0) {
- perror("sendto");
- continue;
+ if (buf[0] == NOT_A_6LOWPAN_FRAME) {
+ /* Send same packet back */
+ len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
+ if (len < 0) {
+ perror("sendto");
+ continue;
+ }
}
}
free(buf);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH wpan-tools] wpan-ping: Add the filtering function for frame receiving
From: Xue Wenqian @ 2016-12-21 3:11 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan, aar
In-Reply-To: <32ee4024-3e9f-4606-4ebe-3ee2c48a40f0@osg.samsung.com>
Hi,
On Tue, Dec 20, 2016 at 10:01:02AM +0100, Stefan Schmidt wrote:
>Hello.
>
>On 19/12/16 03:32, Xue Wenqian wrote:
>>Hi, Stefan
>>
>>Thank you for your reply.
>>
>>On Fri, Dec 16, 2016 at 02:04:34PM +0100, Stefan Schmidt wrote:
>>>Hello.
>>>
>>>On 16/12/16 08:30, wsn.iot.xwq@cn.fujitsu.com wrote:
>>>>From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
>>>>
>>>>Hi,
>>>>
>>>>Let me make some explanations for the patch:
>>>
>>>No need to start the commit message like a mail. Just the description
>>>is fine. :)
>>>
>>ok, I get it.
>>
>>>>1. The filtering for client is made by checking frame header and sequence number
>>>
>>>Sequence we did before as well so the additional check is for the
>>>header here.
>>>
>>I know the sequence number check you did before, the reason I rewrite
>>here is that when the sequence problem occur, the program will also
>>update new timeout value and receive again until correct frame is
>>received or timeout
>
>OK
>
>
>>>>2. Also, when client receives the incorrect frame, it will update new timeout value and receive again until correct frame is received or timeout
>>>
>>>What happens when a frame is really lost?
>>>
>>First, such doing just tries to avoid a frame lost; Second, it will affect the wpan-ping interval value, since the time consumed for header and sequence number checking maybe large sometimes.
>
>Why would the time to check these to values be long? Even on slow
>hardware this should be fast enough.
>
I made some testing before using RPi-3, treating such frame as lost.
In my testing, the wpan-ping is always running, and the ICMPv6
neighbor solicitation and neighbor advertisement packets are also
transmitted periodically. It is found that the time consumed for
checking header and sequence info may reach 20~30ms, even larger than
100ms, it is unacceptable for me.
>>Our experiment has relatively high requirement for the wpan-ping
>>interval, so I modified the code as such. If you think it is not
>>necessary, I could treat such frame as lost for the patch.
>
>Just send an updated patch with the comments I made before. I will
>give it some testing and let you know if I want anything further
>changed. Thanks.
>
ok, I'll send the patch later as you commented before.
Thank you in advance for the tesing.
regards,
Xue Wenqian
^ permalink raw reply
* Re: [PATCH bluetooth-next 4/4] ieee802154: atusb: implement .set_frame_retries ops callback
From: Alexander Aring @ 2016-12-20 11:21 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan
In-Reply-To: <9a4a8de0-9057-553e-0766-957e9ed31fad@pengutronix.de>
Hi,
On 12/20/2016 12:13 PM, Alexander Aring wrote:
>
> Hi,
>
> On 12/05/2016 02:47 PM, Stefan Schmidt wrote:
>> From firmware version 0.3 onwards we use the TX_ARET mode allowing for automatic
>> frame retransmissions. To actually make use of this feature we need to implement
>> the callback for setting the frame retries.
>>
>> If the firmware version is to old print a warning and return with invalid value.
>>
>> Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
>> ---
>> drivers/net/ieee802154/atusb.c | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
>> index 3ed34cc..1253f86 100644
>> --- a/drivers/net/ieee802154/atusb.c
>> +++ b/drivers/net/ieee802154/atusb.c
>> @@ -546,6 +546,21 @@ atusb_set_csma_params(struct ieee802154_hw *hw, u8 min_be, u8 max_be, u8 retries
>> }
>>
>> static int
>> +atusb_set_frame_retries(struct ieee802154_hw *hw, s8 retries)
>> +{
>> + struct atusb *atusb = hw->priv;
>> + struct device *dev = &atusb->usb_dev->dev;
>> +
>> + if (atusb->fw_ver_maj == 0 && atusb->fw_ver_min < 3) {
>> + dev_info(dev, "Automatic frame retransmission is only available from "
>> + "firmware version 0.3. Please update if you want this feature.");
>> + return -EINVAL;
>> + }
>> +
>
> I think the user has not change anymore to use atusb driver with new
> firmware now.
>
meant, has no chance anymore to use new atusb driver with old
firmware...
- Alex
^ permalink raw reply
* Re: [PATCH bluetooth-next 4/4] ieee802154: atusb: implement .set_frame_retries ops callback
From: Alexander Aring @ 2016-12-20 11:13 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan
In-Reply-To: <1480945640-3571-5-git-send-email-stefan@osg.samsung.com>
Hi,
On 12/05/2016 02:47 PM, Stefan Schmidt wrote:
> From firmware version 0.3 onwards we use the TX_ARET mode allowing for automatic
> frame retransmissions. To actually make use of this feature we need to implement
> the callback for setting the frame retries.
>
> If the firmware version is to old print a warning and return with invalid value.
>
> Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
> ---
> drivers/net/ieee802154/atusb.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index 3ed34cc..1253f86 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -546,6 +546,21 @@ atusb_set_csma_params(struct ieee802154_hw *hw, u8 min_be, u8 max_be, u8 retries
> }
>
> static int
> +atusb_set_frame_retries(struct ieee802154_hw *hw, s8 retries)
> +{
> + struct atusb *atusb = hw->priv;
> + struct device *dev = &atusb->usb_dev->dev;
> +
> + if (atusb->fw_ver_maj == 0 && atusb->fw_ver_min < 3) {
> + dev_info(dev, "Automatic frame retransmission is only available from "
> + "firmware version 0.3. Please update if you want this feature.");
> + return -EINVAL;
> + }
> +
I think the user has not change anymore to use atusb driver with new
firmware now.
Because this will set _currently_ when one interface comes first time up.
I say currently here, because we could change tx parameters on other
way... we just need to be sure that no other tx is currently running
anymore... and then change register values for tx parameters.
One argument +1 to use xmit_async, with workqueue inside the driver we
have no change to get knowledge about locking tx in upper-layer..., but
this is another topic. :-)
> + return atusb_write_subreg(atusb, SR_MAX_FRAME_RETRIES, retries);
> +}
> +
> +static int
> atusb_set_promiscuous_mode(struct ieee802154_hw *hw, const bool on)
> {
> struct atusb *atusb = hw->priv;
> @@ -584,6 +599,7 @@ static const struct ieee802154_ops atusb_ops = {
> .set_cca_mode = atusb_set_cca_mode,
> .set_cca_ed_level = atusb_set_cca_ed_level,
> .set_csma_params = atusb_set_csma_params,
> + .set_frame_retries = atusb_set_frame_retries,
> .set_promiscuous_mode = atusb_set_promiscuous_mode,
> };
>
> @@ -754,7 +770,8 @@ static int atusb_probe(struct usb_interface *interface,
>
> hw->parent = &usb_dev->dev;
> hw->flags = IEEE802154_HW_TX_OMIT_CKSUM | IEEE802154_HW_AFILT |
> - IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_CSMA_PARAMS;
> + IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_CSMA_PARAMS |
> + IEEE802154_HW_FRAME_RETRIES;
>
You should set this flag only if it's new firmware... But not using
TX_ARET has also other effects... It's good now that the firmware use
TX_ARET per default.
The current change is that old firmware users can't bring the interface
anymore up, because it fails with -EINVAL and not chance to turn it off. :-)
- Alex
^ permalink raw reply
* Re: [PATCH wpan-tools] wpan-ping: Add the filtering function for frame receiving
From: Stefan Schmidt @ 2016-12-20 9:01 UTC (permalink / raw)
To: wsn.iot.xwq; +Cc: linux-wpan, aar
In-Reply-To: <20161219023200.GA3609@localhost.localdomain>
Hello.
On 19/12/16 03:32, Xue Wenqian wrote:
> Hi, Stefan
>
> Thank you for your reply.
>
> On Fri, Dec 16, 2016 at 02:04:34PM +0100, Stefan Schmidt wrote:
>> Hello.
>>
>> On 16/12/16 08:30, wsn.iot.xwq@cn.fujitsu.com wrote:
>>> From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
>>>
>>> Hi,
>>>
>>> Let me make some explanations for the patch:
>>
>> No need to start the commit message like a mail. Just the description
>> is fine. :)
>>
> ok, I get it.
>
>>> 1. The filtering for client is made by checking frame header and sequence number
>>
>> Sequence we did before as well so the additional check is for the
>> header here.
>>
> I know the sequence number check you did before, the reason I rewrite
> here is that when the sequence problem occur, the program will also
> update new timeout value and receive again until correct frame is
> received or timeout
OK
>>> 2. Also, when client receives the incorrect frame, it will update new timeout value and receive again until correct frame is received or timeout
>>
>> What happens when a frame is really lost?
>>
> First, such doing just tries to avoid a frame lost; Second, it will affect the wpan-ping interval value, since the time consumed for header and sequence number checking maybe large sometimes.
Why would the time to check these to values be long? Even on slow
hardware this should be fast enough.
> Our experiment has relatively high requirement for the wpan-ping
> interval, so I modified the code as such. If you think it is not
> necessary, I could treat such frame as lost for the patch.
Just send an updated patch with the comments I made before. I will give
it some testing and let you know if I want anything further changed. Thanks.
regards
Stefan Schmidt
^ permalink raw reply
* Re: Requesting for info about 15.4 network enabling...
From: Jan Newmarch @ 2016-12-19 9:51 UTC (permalink / raw)
To: JANARDHANACHARI KELLA, linux-wpan
In-Reply-To: <CAAK7Ti89EqhctExJG8+cbeeCM9Ez2f0eE6tdAV_whC=yN_pY3g@mail.gmail.com>
I have an article in the Linux Journal for December 2016 addressing
this issue. It should become publicly available in January, but is
currently available as a paid resource from
http://www.linuxjournal.com/content/linux-journal-december-2016
Basically, you have to give the 6lowpan device a unique local or global
address. The Ipv6 address automatically assigned is a link local
address and isn't routable. You also have to set up your connection to
the external network to be a gateway. If that is a Linux box, you need
to set IPv6 forwarding in /etc/sysctl.conf. Using radvd to configure
your RPi network is also useful. Then with a bit of huffing and puffing
it should work
Cheers
Jan
--
Dr Jan Newmarch,
Head of Higher Education (ICT) @ Box Hill,
Adjunct Professor @ University of Canberra
P 61 3 9286 9971
M +61 4 0117 0509
F 61 3 9286 9100
W www.boxhill.edu.au
W jan.newmarch.name
E j.newmarch@boxhill.edu.au
E jan@newmarch.name
On Mon, 2016-12-19 at 14:35 +0530, JANARDHANACHARI KELLA wrote:
> Hi to all,
>
> I am trying to enable 6lowpan network in raspberry pi..
> I have built kernel with enabling 6lowpan network and drivers. I wish
> to route the devices from out side of the network... What I have to
> do?
> Please any one can help me, how to process...
>
>
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Luca Coelho @ 2016-12-19 9:09 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Russell King, Alasdair Kergon, Mike Snitzer, dm-devel, Shaohua Li,
Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, Greg Kroah-Hartman, Jiri Slaby, Lee Duncan,
Chris Leech, James E.J. Bottomley, Martin K. Petersen,
Nicholas A. Bellinger, Jason Wang, Alexander Aring,
Stefan Schmidt, David S. Miller, linux-arm-kernel,
linux-samsung-soc, linux-raid, netdev, linux-wireless, linux-mm,
open-iscsi, linux-scsi, target-devel, virtualization, linux-wpan
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, 2016-12-15 at 07:15 +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
For drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h:
Acked-by: Luca Coelho <luciano.coelho@intel.com>
--
Luca.
^ permalink raw reply
* Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Luca Coelho @ 2016-12-19 9:08 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Wolfgang Grandegger, Marc Kleine-Budde, Vince Bridgers,
Jay Cliburn, Chris Snook, Luis R. Rodriguez, Kalle Valo,
Maya Erez, Arend van Spriel, Franky Lin, Hante Meuleman,
Stanislaw Gruszka, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Jakub Kicinski, Larry Finger, Chaoming Li,
Greg Kroah-Hartman, David S. Miller, Alexander Aring,
Stefan Schmidt, Matthias Brugger, linux-bluetooth, linux-can,
netdev, nios2-dev, linux-wireless, wil6210,
brcm80211-dev-list.pdl, devel, linux-wpan, linux-arm-kernel,
linux-mediatek
In-Reply-To: <1481778865-27667-9-git-send-email-mst@redhat.com>
On Thu, 2016-12-15 at 07:15 +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
For the drivers/net/wireless/intel/iwlwifi/ part:
Acked-by: Luca Coelho <luciano.coelho@intel.com>
--
Luca.
^ permalink raw reply
* Requesting for info about 15.4 network enabling...
From: JANARDHANACHARI KELLA @ 2016-12-19 9:05 UTC (permalink / raw)
To: linux-wpan
Hi to all,
I am trying to enable 6lowpan network in raspberry pi..
I have built kernel with enabling 6lowpan network and drivers. I wish
to route the devices from out side of the network... What I have to
do?
Please any one can help me, how to process...
--
Sincerely Your's
Janardhanachari Kella
Contact:+91-9908469599
E-mail: eni.chari@gmail.com
^ permalink raw reply
* Re: Bluetooth 6lowpan ping6 slab corruption
From: Alexander Aring @ 2016-12-19 8:19 UTC (permalink / raw)
To: JANARDHANACHARI KELLA; +Cc: Wong, Joshua Weng Onn, linux-wpan@vger.kernel.org
In-Reply-To: <E3B98393E6037849B63EA428240A65135C5492@PGSMSX103.gar.corp.intel.com>
Hi,
On 12/19/2016 07:38 AM, Wong, Joshua Weng Onn wrote:
>> From: JANARDHANACHARI KELLA [mailto:eni.chari@gmail.com]
>> Sent: Monday, December 19, 2016 2:34 PM
>> To: Alexander Aring <aar@pengutronix.de>; Wong, Joshua Weng Onn <joshua.weng.onn.wong@intel.com>
>> Cc: linux-wpan@vger.kernel.org
>> Subject: Re: Bluetooth 6lowpan ping6 slab corruption
>>
>> hi sir,
>> why am i not able to send any message to linux-wpan@@vger.kernel.org mailing list..
>>
>>
>> with Regards
>> Janardhanachari Kella
>>
> Hi Janard,
>
> You can only send Plain Text to the mailing list. You will first need to turn off HTML encodings. Probably that was why your email was rejected.
> Also, you need to perform bottom posting and not top posting i.e. send reply at the bottom of an email.
> Third, you need to prepend the '>' character of the previous original message
>
again and for all:
check http://vger.kernel.org/majordomo-info.html
Important part is "Taboo things".
- Alex
^ permalink raw reply
* RE: Bluetooth 6lowpan ping6 slab corruption
From: Wong, Joshua Weng Onn @ 2016-12-19 6:38 UTC (permalink / raw)
To: JANARDHANACHARI KELLA, Alexander Aring; +Cc: linux-wpan@vger.kernel.org
In-Reply-To: <CAAK7Ti_wdFr6PUGzE0aDdUMTNJtNVZxRpJ7WWrV61btWcYHJJw@mail.gmail.com>
> From: JANARDHANACHARI KELLA [mailto:eni.chari@gmail.com]
> Sent: Monday, December 19, 2016 2:34 PM
> To: Alexander Aring <aar@pengutronix.de>; Wong, Joshua Weng Onn <joshua.weng.onn.wong@intel.com>
> Cc: linux-wpan@vger.kernel.org
> Subject: Re: Bluetooth 6lowpan ping6 slab corruption
>
> hi sir,
> why am i not able to send any message to linux-wpan@@vger.kernel.org mailing list..
>
>
> with Regards
> Janardhanachari Kella
>
Hi Janard,
You can only send Plain Text to the mailing list. You will first need to turn off HTML encodings. Probably that was why your email was rejected.
Also, you need to perform bottom posting and not top posting i.e. send reply at the bottom of an email.
Third, you need to prepend the '>' character of the previous original message
-Joshua-
> On Mon, Dec 19, 2016 at 5:57 AM, Wong, Joshua Weng Onn <joshua.weng.onn.wong@intel.com> wrote:
> Hi Alex,
> Hi,
>
> On 12/16/2016 09:18 AM, Wong, Joshua Weng Onn wrote:
> ...
> >
> > Thank you for informing me about this. Sorry as I was not aware of the newer
> patches that you submitted to mainline.
> > At the moment I am not able to upgrade the kernel to a recent version as the
> other teams in my department are using kernel version 4.1.27 and I have to
> follow it strictly.
> >
> > I just got an idea. Perhaps what I can do is backport the patches and apply
> them to this version of the kernel. I am not sure if it will work entirely. I'll discuss
> this with my lead first if he wants me to do this and let you know if I am pursuing
> this.
> >
>
> You can backport it, yes... but please _please_ don't do it... bring it mainline and
> then backport it.
>
> Tell that your lead as suggestion from me.
>
> It makes no sense that you backporting it only for you. This thing need to be
> fixed upstream...
>
> In my opinion, all people who backporting it will do work for nothing...
> The next guy/girl which wants to try that out runs again into such issues.
>
> These patches was sending to bluetooth-next, now I am busy with other things
> and can work on it at end of April maybe... and I think only in my free-time. This
> patch-series just needs a little cleanup and send as PATCH...
>
> - Alex
I've finally just learned how to add inline '>' characters to the previous email. Had to make some changes in my email settings.
Thank you very much for your reply.
Ok noted on that. My most sincere apologies as I am quite new to this and I am still trying to understand how open source works. Didn't realize that it will cause repetitive work for others.
I will discuss this with my technical lead and update you along the way.
Thank you.
Best regards,
Joshua
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely Your's
Janardhanachari Kella
Contact:+91-9908469599
E-mail: eni.chari@gmail.com
^ permalink raw reply
* Re: [PATCH wpan-tools] wpan-ping: Add the filtering function for frame receiving
From: Xue Wenqian @ 2016-12-19 2:32 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan, aar
In-Reply-To: <5c134ecc-9b51-7a1f-aade-8de517428b8b@osg.samsung.com>
Hi, Stefan
Thank you for your reply.
On Fri, Dec 16, 2016 at 02:04:34PM +0100, Stefan Schmidt wrote:
>Hello.
>
>On 16/12/16 08:30, wsn.iot.xwq@cn.fujitsu.com wrote:
>>From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
>>
>>Hi,
>>
>>Let me make some explanations for the patch:
>
>No need to start the commit message like a mail. Just the description
>is fine. :)
>
ok, I get it.
>>1. The filtering for client is made by checking frame header and sequence number
>
>Sequence we did before as well so the additional check is for the
>header here.
>
I know the sequence number check you did before, the reason I rewrite
here is that when the sequence problem occur, the program will also
update new timeout value and receive again until correct frame is
received or timeout
>>2. Also, when client receives the incorrect frame, it will update new timeout value and receive again until correct frame is received or timeout
>
>What happens when a frame is really lost?
>
First, such doing just tries to avoid a frame lost; Second, it will affect the wpan-ping interval value, since the time consumed for header and sequence number checking maybe large sometimes.
Our experiment has relatively high requirement for the wpan-ping
interval, so I modified the code as such. If you think it is not
necessary, I could treat such frame as lost for the patch.
>>3. The filtering for server is made by just checking frame header
>
>Guess that should help a bit to protect against 6LoWPAN traffic, but
>for every other protocol setting the not a 6LoWPAN header this will
>not work. Nothing we can do against though.
>
Yes, you're right.
>>4. For code reuse, I replace sleeping() with get_interval() function
>>
>>Signed-off-by: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
>>---
>> wpan-ping/wpan-ping.c | 86 ++++++++++++++++++++++++++++++-------------------
>> 1 file changed, 53 insertions(+), 33 deletions(-)
>>
>>diff --git a/wpan-ping/wpan-ping.c b/wpan-ping/wpan-ping.c
>>index e6df2b4..15a2a4b 100644
>>--- a/wpan-ping/wpan-ping.c
>>+++ b/wpan-ping/wpan-ping.c
>>@@ -235,28 +235,30 @@ static int print_address(char *addr, uint8_t dst_extended[IEEE802154_ADDR_LEN])
>> return 0;
>> }
>>
>>-static void sleeping(struct timeval ping_start_time, struct timeval timeout) {
>>- struct timeval curr_time;
>>- long sec, usec, interval_usec, timeout_usec;
>>- long sleep_usec = 0;
>>- gettimeofday(&curr_time, NULL);
>>- sec = curr_time.tv_sec - ping_start_time.tv_sec;
>>- usec = curr_time.tv_usec - ping_start_time.tv_usec;
>>- if (usec < 0) {
>>- usec += 1000000;
>>- sec--;
>>+/* time interval computation */
>>+static long get_interval(struct timeval start_time, struct timeval end_time, long timeout_usec) {
>>+ long sec, usec, usecs, interval_usec = 0;
>>+ sec = end_time.tv_sec - start_time.tv_sec;
>>+ usec = end_time.tv_usec - start_time.tv_usec;
>>+ usecs = sec * 1000000 + usec;
>>+ if (usecs < timeout_usec) {
>>+ interval_usec = timeout_usec - usecs;
>> }
>>- interval_usec = sec * 1000000 + usec;
>>- timeout_usec = timeout.tv_sec * 1000000 + timeout.tv_usec;
>>- if (interval_usec < timeout_usec) {
>>- sleep_usec = timeout_usec - interval_usec;
>>- usleep(sleep_usec);
>>+ return interval_usec;
>>+}
>>+
>>+/* recv timeout setting */
>>+static void set_so_rcvtimeo(int sd, struct timeval timeout) {
>>+ int ret;
>>+ ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout, sizeof(struct timeval));
>>+ if (ret < 0) {
>>+ perror("setsockopt receive timeout");
>> }
>> }
>>
>> static int measure_roundtrip(struct config *conf, int sd) {
>> unsigned char *buf;
>>- struct timeval ping_start_time, start_time, end_time, timeout;
>>+ struct timeval ping_start_time, start_time, end_time, ping_end_time, timeout, new_timeout;
>> long sec = 0, usec = 0;
>> long sec_max = 0, usec_max = 0;
>> long sec_min = 2147483647, usec_min = 2147483647;
>>@@ -266,6 +268,8 @@ static int measure_roundtrip(struct config *conf, int sd) {
>> float rtt_min = 0.0, rtt_avg = 0.0, rtt_max = 0.0;
>> float packet_loss = 100.0;
>> char addr[24];
>>+ long timeout_usec, interval_usec, sleep_usec;
>>+ int set_so_rcvtimeo_flag;
>>
>> if (conf->extended)
>> print_address(addr, conf->dst.addr.hwaddr);
>>@@ -287,10 +291,9 @@ static int measure_roundtrip(struct config *conf, int sd) {
>> timeout.tv_sec = 0;
>> timeout.tv_usec = conf->interval * 1000;
>> }
>>- ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout,sizeof(struct timeval));
>>- if (ret < 0) {
>>- perror("setsockopt receive timeout");
>>- }
>>+ timeout_usec = conf->interval * 1000;
>>+ set_so_rcvtimeo(sd, timeout);
>>+ set_so_rcvtimeo_flag = 1;
>>
>> count = 0;
>> for (i = 0; i < conf->packets; i++) {
>>@@ -302,13 +305,24 @@ static int measure_roundtrip(struct config *conf, int sd) {
>> perror("sendto");
>> }
>> gettimeofday(&start_time, NULL);
>>- ret = recv(sd, buf, conf->packet_len, 0);
>>- if (seq_num != ((buf[2] << 8)| buf[3])) {
>>- printf("Sequenze number did not match\n");
>>- continue;
>>+ while(1) {
>>+ ret = recv(sd, buf, conf->packet_len, 0);
>>+ gettimeofday(&end_time, NULL);
>>+ interval_usec = get_interval(ping_start_time, end_time, timeout_usec);
>>+ if (interval_usec > 0 && (buf[0] != '\000' || seq_num != ((buf[2] << 8)| buf[3]))) {
>
>The header check could be buf[0] != NOT_A_6LOWPAN_FRAME
>That way it is clearer what we are checking on.
>
ok, no problem.
>>+ fprintf(stderr, "Packet %i: Sequence number did not match, receive again!\n", i);
>>+ new_timeout.tv_sec = (int)(interval_usec * 1.0 / 1000000);
>>+ new_timeout.tv_usec = interval_usec - (new_timeout.tv_sec * 1000000);
>>+ set_so_rcvtimeo(sd, new_timeout);
>>+ set_so_rcvtimeo_flag = 0;
>>+ } else {
>>+ if (set_so_rcvtimeo_flag == 0) {
>>+ set_so_rcvtimeo(sd, timeout);
>>+ }
>>+ break;
>>+ }
>> }
>> if (ret > 0) {
>>- gettimeofday(&end_time, NULL);
>> count++;
>> sec = end_time.tv_sec - start_time.tv_sec;
>> sum_sec += sec;
>>@@ -338,9 +352,13 @@ static int measure_roundtrip(struct config *conf, int sd) {
>> fprintf(stdout, "%i bytes from 0x%04x seq=%i time=%.1f ms\n", ret,
>> conf->dst.addr.short_addr, (int)seq_num, (float)usec/1000);
>> } else
>>- fprintf(stderr, "Hit %i ms packet timeout\n", conf->interval);
>>+ fprintf(stderr, "Packet %i: Hit %i ms packet timeout\n", i, conf->interval);
>> /* sleeping */
>>- sleeping(ping_start_time, timeout);
>>+ gettimeofday(&ping_end_time, NULL);
>>+ sleep_usec = get_interval(ping_start_time, ping_end_time, timeout_usec);
>>+ if (sleep_usec > 0) {
>>+ usleep(sleep_usec);
>>+ }
>> }
>>
>> if (count)
>>@@ -386,11 +404,13 @@ static void init_server(int sd) {
>> #if DEBUG
>> dump_packet(buf, len);
>> #endif
>>- /* Send same packet back */
>>- len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
>>- if (len < 0) {
>>- perror("sendto");
>>- continue;
>>+ if (buf[0] == '\000') {
>
>Something like if(buf[0] == NOT_A_6LOWPAN_FRAME) would be clearer.
>
ok.
>>+ /* Send same packet back */
>>+ len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
>>+ if (len < 0) {
>>+ perror("sendto");
>>+ continue;
>>+ }
>> }
>> }
>> free(buf);
>>@@ -559,4 +579,4 @@ int main(int argc, char *argv[]) {
>> init_network(conf);
>> free(conf);
>> return 0;
>>-}
>>+}
>
>What is this change? Some extra whitespace?
>
Maybe, I'll check it later.
>regards
>Stefan Schmidt
>
Best Regards,
Xue Wenqian
^ permalink raw reply
* RE: Bluetooth 6lowpan ping6 slab corruption
From: Wong, Joshua Weng Onn @ 2016-12-19 0:27 UTC (permalink / raw)
To: Alexander Aring
Cc: alex.aring@gmail.com, jukka.rissanen@linux.intel.com,
linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org
In-Reply-To: <efdc1a54-7fdc-80b8-f46d-d663addae509@pengutronix.de>
Hi Alex,
> Hi,
>
> On 12/16/2016 09:18 AM, Wong, Joshua Weng Onn wrote:
> ...
> >
> > Thank you for informing me about this. Sorry as I was not aware of the newer
> patches that you submitted to mainline.
> > At the moment I am not able to upgrade the kernel to a recent version as the
> other teams in my department are using kernel version 4.1.27 and I have to
> follow it strictly.
> >
> > I just got an idea. Perhaps what I can do is backport the patches and apply
> them to this version of the kernel. I am not sure if it will work entirely. I'll discuss
> this with my lead first if he wants me to do this and let you know if I am pursuing
> this.
> >
>
> You can backport it, yes... but please _please_ don't do it... bring it mainline and
> then backport it.
>
> Tell that your lead as suggestion from me.
>
> It makes no sense that you backporting it only for you. This thing need to be
> fixed upstream...
>
> In my opinion, all people who backporting it will do work for nothing...
> The next guy/girl which wants to try that out runs again into such issues.
>
> These patches was sending to bluetooth-next, now I am busy with other things
> and can work on it at end of April maybe... and I think only in my free-time. This
> patch-series just needs a little cleanup and send as PATCH...
>
> - Alex
I've finally just learned how to add inline '>' characters to the previous email. Had to make some changes in my email settings.
Thank you very much for your reply.
Ok noted on that. My most sincere apologies as I am quite new to this and I am still trying to understand how open source works. Didn't realize that it will cause repetitive work for others.
I will discuss this with my technical lead and update you along the way.
Thank you.
Best regards,
Joshua
^ permalink raw reply
* [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
From: Andrey Smirnov @ 2016-12-18 23:25 UTC (permalink / raw)
To: linux-wpan
Cc: Andrey Smirnov, Alexander Aring, netdev, linux-kernel,
Chris Healy
Driver code never touches "rstn" signal in atomic context, so there's
no need to implicitly put such restriction on it by using gpio_set_value
to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
fix that.
As a an example of where such restriction might be inconvenient,
consider a hardware design where "rstn" is connected to a pin of I2C/SPI
GPIO expander chip.
Cc: Chris Healy <cphealy@gmail.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
drivers/net/ieee802154/at86rf230.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 9f10da6..7700690 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1710,9 +1710,9 @@ static int at86rf230_probe(struct spi_device *spi)
/* Reset */
if (gpio_is_valid(rstn)) {
udelay(1);
- gpio_set_value(rstn, 0);
+ gpio_set_value_cansleep(rstn, 0);
udelay(1);
- gpio_set_value(rstn, 1);
+ gpio_set_value_cansleep(rstn, 1);
usleep_range(120, 240);
}
--
2.5.5
^ permalink raw reply related
* Re: [PATCH wpan-tools] wpan-ping: Add the filtering function for frame receiving
From: Stefan Schmidt @ 2016-12-16 13:04 UTC (permalink / raw)
To: wsn.iot.xwq, linux-wpan; +Cc: aar
In-Reply-To: <1481873430-4965-1-git-send-email-wsn.iot.xwq@cn.fujitsu.com>
Hello.
On 16/12/16 08:30, wsn.iot.xwq@cn.fujitsu.com wrote:
> From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
>
> Hi,
>
> Let me make some explanations for the patch:
No need to start the commit message like a mail. Just the description is
fine. :)
> 1. The filtering for client is made by checking frame header and sequence number
Sequence we did before as well so the additional check is for the header
here.
> 2. Also, when client receives the incorrect frame, it will update new timeout value and receive again until correct frame is received or timeout
What happens when a frame is really lost?
> 3. The filtering for server is made by just checking frame header
Guess that should help a bit to protect against 6LoWPAN traffic, but for
every other protocol setting the not a 6LoWPAN header this will not
work. Nothing we can do against though.
> 4. For code reuse, I replace sleeping() with get_interval() function
>
> Signed-off-by: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
> ---
> wpan-ping/wpan-ping.c | 86 ++++++++++++++++++++++++++++++-------------------
> 1 file changed, 53 insertions(+), 33 deletions(-)
>
> diff --git a/wpan-ping/wpan-ping.c b/wpan-ping/wpan-ping.c
> index e6df2b4..15a2a4b 100644
> --- a/wpan-ping/wpan-ping.c
> +++ b/wpan-ping/wpan-ping.c
> @@ -235,28 +235,30 @@ static int print_address(char *addr, uint8_t dst_extended[IEEE802154_ADDR_LEN])
> return 0;
> }
>
> -static void sleeping(struct timeval ping_start_time, struct timeval timeout) {
> - struct timeval curr_time;
> - long sec, usec, interval_usec, timeout_usec;
> - long sleep_usec = 0;
> - gettimeofday(&curr_time, NULL);
> - sec = curr_time.tv_sec - ping_start_time.tv_sec;
> - usec = curr_time.tv_usec - ping_start_time.tv_usec;
> - if (usec < 0) {
> - usec += 1000000;
> - sec--;
> +/* time interval computation */
> +static long get_interval(struct timeval start_time, struct timeval end_time, long timeout_usec) {
> + long sec, usec, usecs, interval_usec = 0;
> + sec = end_time.tv_sec - start_time.tv_sec;
> + usec = end_time.tv_usec - start_time.tv_usec;
> + usecs = sec * 1000000 + usec;
> + if (usecs < timeout_usec) {
> + interval_usec = timeout_usec - usecs;
> }
> - interval_usec = sec * 1000000 + usec;
> - timeout_usec = timeout.tv_sec * 1000000 + timeout.tv_usec;
> - if (interval_usec < timeout_usec) {
> - sleep_usec = timeout_usec - interval_usec;
> - usleep(sleep_usec);
> + return interval_usec;
> +}
> +
> +/* recv timeout setting */
> +static void set_so_rcvtimeo(int sd, struct timeval timeout) {
> + int ret;
> + ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout, sizeof(struct timeval));
> + if (ret < 0) {
> + perror("setsockopt receive timeout");
> }
> }
>
> static int measure_roundtrip(struct config *conf, int sd) {
> unsigned char *buf;
> - struct timeval ping_start_time, start_time, end_time, timeout;
> + struct timeval ping_start_time, start_time, end_time, ping_end_time, timeout, new_timeout;
> long sec = 0, usec = 0;
> long sec_max = 0, usec_max = 0;
> long sec_min = 2147483647, usec_min = 2147483647;
> @@ -266,6 +268,8 @@ static int measure_roundtrip(struct config *conf, int sd) {
> float rtt_min = 0.0, rtt_avg = 0.0, rtt_max = 0.0;
> float packet_loss = 100.0;
> char addr[24];
> + long timeout_usec, interval_usec, sleep_usec;
> + int set_so_rcvtimeo_flag;
>
> if (conf->extended)
> print_address(addr, conf->dst.addr.hwaddr);
> @@ -287,10 +291,9 @@ static int measure_roundtrip(struct config *conf, int sd) {
> timeout.tv_sec = 0;
> timeout.tv_usec = conf->interval * 1000;
> }
> - ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout,sizeof(struct timeval));
> - if (ret < 0) {
> - perror("setsockopt receive timeout");
> - }
> + timeout_usec = conf->interval * 1000;
> + set_so_rcvtimeo(sd, timeout);
> + set_so_rcvtimeo_flag = 1;
>
> count = 0;
> for (i = 0; i < conf->packets; i++) {
> @@ -302,13 +305,24 @@ static int measure_roundtrip(struct config *conf, int sd) {
> perror("sendto");
> }
> gettimeofday(&start_time, NULL);
> - ret = recv(sd, buf, conf->packet_len, 0);
> - if (seq_num != ((buf[2] << 8)| buf[3])) {
> - printf("Sequenze number did not match\n");
> - continue;
> + while(1) {
> + ret = recv(sd, buf, conf->packet_len, 0);
> + gettimeofday(&end_time, NULL);
> + interval_usec = get_interval(ping_start_time, end_time, timeout_usec);
> + if (interval_usec > 0 && (buf[0] != '\000' || seq_num != ((buf[2] << 8)| buf[3]))) {
The header check could be buf[0] != NOT_A_6LOWPAN_FRAME
That way it is clearer what we are checking on.
> + fprintf(stderr, "Packet %i: Sequence number did not match, receive again!\n", i);
> + new_timeout.tv_sec = (int)(interval_usec * 1.0 / 1000000);
> + new_timeout.tv_usec = interval_usec - (new_timeout.tv_sec * 1000000);
> + set_so_rcvtimeo(sd, new_timeout);
> + set_so_rcvtimeo_flag = 0;
> + } else {
> + if (set_so_rcvtimeo_flag == 0) {
> + set_so_rcvtimeo(sd, timeout);
> + }
> + break;
> + }
> }
> if (ret > 0) {
> - gettimeofday(&end_time, NULL);
> count++;
> sec = end_time.tv_sec - start_time.tv_sec;
> sum_sec += sec;
> @@ -338,9 +352,13 @@ static int measure_roundtrip(struct config *conf, int sd) {
> fprintf(stdout, "%i bytes from 0x%04x seq=%i time=%.1f ms\n", ret,
> conf->dst.addr.short_addr, (int)seq_num, (float)usec/1000);
> } else
> - fprintf(stderr, "Hit %i ms packet timeout\n", conf->interval);
> + fprintf(stderr, "Packet %i: Hit %i ms packet timeout\n", i, conf->interval);
> /* sleeping */
> - sleeping(ping_start_time, timeout);
> + gettimeofday(&ping_end_time, NULL);
> + sleep_usec = get_interval(ping_start_time, ping_end_time, timeout_usec);
> + if (sleep_usec > 0) {
> + usleep(sleep_usec);
> + }
> }
>
> if (count)
> @@ -386,11 +404,13 @@ static void init_server(int sd) {
> #if DEBUG
> dump_packet(buf, len);
> #endif
> - /* Send same packet back */
> - len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
> - if (len < 0) {
> - perror("sendto");
> - continue;
> + if (buf[0] == '\000') {
Something like if(buf[0] == NOT_A_6LOWPAN_FRAME) would be clearer.
> + /* Send same packet back */
> + len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
> + if (len < 0) {
> + perror("sendto");
> + continue;
> + }
> }
> }
> free(buf);
> @@ -559,4 +579,4 @@ int main(int argc, char *argv[]) {
> init_network(conf);
> free(conf);
> return 0;
> -}
> +}
What is this change? Some extra whitespace?
regards
Stefan Schmidt
^ permalink raw reply
* Re: Bluetooth 6lowpan ping6 slab corruption
From: Alexander Aring @ 2016-12-16 9:54 UTC (permalink / raw)
To: Wong, Joshua Weng Onn
Cc: alex.aring@gmail.com, jukka.rissanen@linux.intel.com,
linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org
In-Reply-To: <E3B98393E6037849B63EA428240A65135BCA89@PGSMSX103.gar.corp.intel.com>
Hi,
On 12/16/2016 09:18 AM, Wong, Joshua Weng Onn wrote:
...
>
> Thank you for informing me about this. Sorry as I was not aware of the newer patches that you submitted to mainline.
> At the moment I am not able to upgrade the kernel to a recent version as the other teams in my department are using kernel version 4.1.27 and I have to follow it strictly.
>
> I just got an idea. Perhaps what I can do is backport the patches and apply them to this version of the kernel. I am not sure if it will work entirely. I'll discuss this with my lead first if he wants me to do this and let you know if I am pursuing this.
>
You can backport it, yes... but please _please_ don't do it... bring it
mainline and then backport it.
Tell that your lead as suggestion from me.
It makes no sense that you backporting it only for you. This thing need
to be fixed upstream...
In my opinion, all people who backporting it will do work for nothing...
The next guy/girl which wants to try that out runs again into such
issues.
These patches was sending to bluetooth-next, now I am busy with other
things and can work on it at end of April maybe... and I think only in
my free-time. This patch-series just needs a little cleanup and send as
PATCH...
- Alex
^ permalink raw reply
* Re: Flashing firmware onto atusb
From: Stefan Schmidt @ 2016-12-16 9:05 UTC (permalink / raw)
To: Alexander Aring; +Cc: Guido Günther, linux-wpan
In-Reply-To: <530ec350-374b-07fa-7a19-f743b7973932@pengutronix.de>
Hello.
On 15/12/16 20:24, Alexander Aring wrote:
>
> Hi,
>
> On 12/15/2016 06:57 PM, Stefan Schmidt wrote:
>> Hello.
>>
>> On 15/12/16 12:38, Alexander Aring wrote:
>>>
>>> Hi,
>>>
>>> On 12/15/2016 12:25 PM, Guido Günther wrote:
>>>> Hi Stefan,
>>>>
>>>> On Thu, Dec 15, 2016 at 11:44:53AM +0100, Stefan Schmidt wrote:
>>>>> Hello.
>>>>>
>>>>> On 15/12/16 10:45, Guido Günther wrote:
>>>>>> Hi,
>>>>>> I'm trying to flash firmware onto a new atusb dongle but:
>>>>>
>>>>>
>>>>> Is this one of the dongles from the recent builds or is it an old one?
>>>>> The new ones already come with version 0.3 of the firmware. :-)
>>>>
>>>> ...but I want to be able to flash my own in the future ;)
>>>>
>>>>>
>>>>>>
>>>>>> # lsusb | grep Qi
>>>>>> Bus 001 Device 014: ID 20b7:1540 Qi Hardware ben-wpan, AT86RF230-based
>>>>>>
>>>>>> # dfu-util -d 20b7:1540 -D atusb-0.3.dfu
>>>>>> dfu-util 0.9
>>>>>>
>>>>>> Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
>>>>>> Copyright 2010-2016 Tormod Volden and Stefan Schmidt
>>>>>> This program is Free Software and has ABSOLUTELY NO WARRANTY
>>>>>> Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
>>>>>>
>>>>>> dfu-util: Invalid DFU suffix signature
>>>>>> dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
>>>>>> dfu-util: Device has DFU interface, but has no DFU functional descriptor
>>>>>> Deducing device DFU version from functional descriptor length
>>>>>> Opening DFU capable USB device...
>>>>>> ID 20b7:1540
>>>>>> Run-time device DFU version 0100
>>>>>> Claiming USB DFU Runtime Interface...
>>>>>> Determining device status: state = appIDLE, status = 0
>>>>>> Device really in Runtime Mode, send DFU detach request...
>>>>>> Resetting USB...
>>>>>> dfu-util: Device has DFU interface, but has no DFU functional descriptor
>>>>>> Deducing device DFU version from functional descriptor length
>>>>>> dfu-util: Lost device after RESET?
>>>>>> # echo $?
>>>>>> 74
>>>>>>
>>>>>> dmesg has:
>>>>>>
>>>>>> # dmesg
>>>>>> [ 2802.216273] usb 1-1: reset full-speed USB device number 14 using xhci_hcd
>>>>>> [ 2807.496177] usb 1-1: USB disconnect, device number 14
>>>>>> [ 2807.760001] usb 1-1: new full-speed USB device number 15 using xhci_hcd
>>>>>> [ 2807.901993] usb 1-1: New USB device found, idVendor=20b7, idProduct=1540
>>>>>> [ 2807.901997] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
>>>>>> [ 2807.902000] usb 1-1: SerialNumber: 47303530353015102717
>>>>>>
>>>>>> Is there anything obvious I am missing?
>>>>>
>>>>> Seems you tried to flash the device when already out of the bootloader mode.
>>>>> Please try the above command again when inserting the dongle. The device is
>>>>> in the bootloader, waiting for firmware updates, as long as the red LED is
>>>>> on after insertion.
>>>>
>>>> That worked:
>>>>
>>>> # dfu-util -d 20b7:1540 -D atusb-0.3.dfu
>>>> dfu-util 0.9
>>>>
>>>> Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
>>>> Copyright 2010-2016 Tormod Volden and Stefan Schmidt
>>>> This program is Free Software and has ABSOLUTELY NO WARRANTY
>>>> Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
>>>>
>>>> Opening DFU capable USB device...
>>>> ID 20b7:1540
>>>> Run-time device DFU version 0101
>>>> Claiming USB DFU Interface...
>>>> Setting Alternate Setting #0 ...
>>>> Determining device status: state = dfuDNLOAD-IDLE, status = 8
>>>> aborting previous incomplete transfer
>>>> Determining device status: state = dfuIDLE, status = 0
>>>> dfuIDLE, continuing
>>>> DFU mode device DFU version 0101
>>>> Device returned transfer size 64
>>>> Copying data from PC to DFU device
>>>> Download [=========================] 100% 6026 bytes
>>>> Download done.
>>>> state(2) = dfuIDLE, status(0) = No error condition is present
>>>> Done!
>>>>
>>>> I was thinking about s.th. like bootloader mode in the first place but
>>>> this deceived me:
>>>>
>>>> Device really in Runtime Mode, send DFU detach request...
>>>> Resetting USB...
>>>> dfu-util: Device has DFU interface, but has no DFU functional descriptor
>>>>
>>>> so I thought dfu-util would be able to get the device back into
>>>> bootloader mode. And in fact if the device is in runtime mode already I
>>>> do see a device reset (the red led turns back on) but it the fails. Is
>>>> this a bug in dfu-util or expected? If so should it be documented like
>>>> in the attache patch?
>>>
>>> maybe this is actual the difference between dfu-util 0.7 and 0.9...
>>>
>>> I expierenced issues with dfu-util greather than 0.7, can you recheck
>>> with 0.7?
>>
>> I have been using version 0.8 for all flashing of the hundred new devices which have been produced without a single problem when flashing while the device is in the bootloader. On the other hand it never ever worked for me when doing it while the device was already in the firmware. If you are sure that it worked for you before that would be new to me. In that case it would be a regression.
>>
>
> I always flashed with dfu when the device was in firmware. The device
> resets and dfu-util upload the firmware....
>
> mhh, I am not sure if I ever tested it after this patch [0].
>
> It solved for me to use atusb in qemu above 1.6.2 but maybe has other
> side effects.
>
> My expierence with atusb firmware is that I never need to fiddle some
> right timing to call dfu-util while booting. :-/
Interesting that this worked for you while I can't remember it ever
worked for me. Maybe my old patch to make it work with newer Qemu's did
indeed break it.
For anybody wanting to dig into this it would indeed be a good starting
point. As I wrote before, for me its very much at the bottom of my todo
list.
regards
Stefan Schmidt
^ permalink raw reply
* RE: Bluetooth 6lowpan ping6 slab corruption
From: Wong, Joshua Weng Onn @ 2016-12-16 8:18 UTC (permalink / raw)
To: Alexander Aring
Cc: alex.aring@gmail.com, jukka.rissanen@linux.intel.com,
linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org
In-Reply-To: <c70d7129-be2d-4764-6f09-1153192c49be@pengutronix.de>
On 12/16/2016 07:46 AM, Wong, Joshua Weng Onn wrote:
> Hi,
>
> I have enabled 6lowpan and bluetooth 6lowpan in the kernel configuration on two systems. Both these systems are running linux and one act as a master and another act as a slave.
> I am facing a bug while in a bluetooth 6lowpan connection. This happens during a ping6. The kernel version that I am using is 4.1.27 with BlueZ 5.40 on a x86_64 architecture. The kernel reports regarding slab corruption.
>
> The steps that I have performed are as follows:
> Slave device:
> $ modprobe 6lowpan
> $ modprobe Bluetooth_6lowpan
> $ echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
> $ hciconfig hci0 leadv
>
> Master device:
> $ modprobe 6lowpan
> $ modprobe bluetooth_6lowpan
> $ echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
> $ hcitool lescan << to obtain slave BT ADDR $ echo "connect
> <remote_BT_MAC> 1" > /sys/kernel/debug/bluetooth/6lowpan_control
> $ ifconfig (look for bt0 interface) << to obtain IPv6 address of slave device
> $ ping6 -I bt0 <IPV6_ADDR> <<<<------ The console message starts to appear here during ping6
>
> The output of the console message:
>
> [ 794.985623] Slab corruption (Tainted: G U ): skbuff_head_cache start=ffff8801f568f700, len=232
> [ 795.008755] 050: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> ....kkkkkkkkkkkk [ 795.029380] Prev obj: start=ffff8801f568f600,
> len=232 [ 795.044743] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 795.061310] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 795.076752] Next obj: start=ffff8801f568f800, len=232 [
> 795.088448] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> kkkkkkkkkkkkkkkk [ 795.102365] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>
> The 6lowpan connection between the two devices is connected.
> I observed that the console message appears once when the master initiates the connection to the slave and nothing happens after that.
> Once I start doing the ping6 from master to slave, the same message appears again. This same set of message continues to be printed every 5 seconds or so.
> This also persists when ping6 is done from the slave to the master.
>
> Do you know what could possibly cause this issue?
>
> Please let me know if you require further information.
>
In short:
BTLE 6LoWPAN is broken. Patch-Series which needs some love to fix some issues (mostly races/L2 address handling with L3 stuff, use ndisc stuff, still exists open question which L2 address should be used) exists at [0].
Maybe YOU want to bring it mainline -> I have no time currently to do that.
Of maybe you can test it and tell me your expierence. :-)
If you want still to use the current code, I recommend to disable SMP...
but races still exists. Also update the kernel version to a recent one.
- Alex
[0] http://www.spinics.net/lists/linux-wpan/msg04124.html
Thank you for informing me about this. Sorry as I was not aware of the newer patches that you submitted to mainline.
At the moment I am not able to upgrade the kernel to a recent version as the other teams in my department are using kernel version 4.1.27 and I have to follow it strictly.
I just got an idea. Perhaps what I can do is backport the patches and apply them to this version of the kernel. I am not sure if it will work entirely. I'll discuss this with my lead first if he wants me to do this and let you know if I am pursuing this.
Best regards,
Joshua
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Bluetooth 6lowpan ping6 slab corruption
From: Alexander Aring @ 2016-12-16 7:44 UTC (permalink / raw)
Cc: Wong, Joshua Weng Onn, alex.aring@gmail.com,
jukka.rissanen@linux.intel.com, linux-bluetooth@vger.kernel.org,
linux-wpan@vger.kernel.org
In-Reply-To: <E3B98393E6037849B63EA428240A65135BC9D5@PGSMSX103.gar.corp.intel.com>
On 12/16/2016 07:46 AM, Wong, Joshua Weng Onn wrote:
> Hi,
>
> I have enabled 6lowpan and bluetooth 6lowpan in the kernel configuration on two systems. Both these systems are running linux and one act as a master and another act as a slave.
> I am facing a bug while in a bluetooth 6lowpan connection. This happens during a ping6. The kernel version that I am using is 4.1.27 with BlueZ 5.40 on a x86_64 architecture. The kernel reports regarding slab corruption.
>
> The steps that I have performed are as follows:
> Slave device:
> $ modprobe 6lowpan
> $ modprobe Bluetooth_6lowpan
> $ echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
> $ hciconfig hci0 leadv
>
> Master device:
> $ modprobe 6lowpan
> $ modprobe bluetooth_6lowpan
> $ echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
> $ hcitool lescan << to obtain slave BT ADDR
> $ echo "connect <remote_BT_MAC> 1" > /sys/kernel/debug/bluetooth/6lowpan_control
> $ ifconfig (look for bt0 interface) << to obtain IPv6 address of slave device
> $ ping6 -I bt0 <IPV6_ADDR> <<<<------ The console message starts to appear here during ping6
>
> The output of the console message:
>
> [ 794.985623] Slab corruption (Tainted: G U ): skbuff_head_cache start=ffff8801f568f700, len=232
> [ 795.008755] 050: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> [ 795.029380] Prev obj: start=ffff8801f568f600, len=232
> [ 795.044743] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 795.061310] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 795.076752] Next obj: start=ffff8801f568f800, len=232
> [ 795.088448] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 795.102365] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>
> The 6lowpan connection between the two devices is connected.
> I observed that the console message appears once when the master initiates the connection to the slave and nothing happens after that.
> Once I start doing the ping6 from master to slave, the same message appears again. This same set of message continues to be printed every 5 seconds or so.
> This also persists when ping6 is done from the slave to the master.
>
> Do you know what could possibly cause this issue?
>
> Please let me know if you require further information.
>
In short:
BTLE 6LoWPAN is broken. Patch-Series which needs some love to fix some
issues (mostly races/L2 address handling with L3 stuff, use ndisc stuff,
still exists open question which L2 address should be used) exists at
[0].
Maybe YOU want to bring it mainline -> I have no time currently to do that.
Of maybe you can test it and tell me your expierence. :-)
If you want still to use the current code, I recommend to disable SMP...
but races still exists. Also update the kernel version to a recent one.
- Alex
[0] http://www.spinics.net/lists/linux-wpan/msg04124.html
^ permalink raw reply
* [PATCH wpan-tools] wpan-ping: Add the filtering function for frame receiving
From: wsn.iot.xwq @ 2016-12-16 7:30 UTC (permalink / raw)
To: linux-wpan; +Cc: stefan, aar, Xue Wenqian
From: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
Hi,
Let me make some explanations for the patch:
1. The filtering for client is made by checking frame header and sequence number
2. Also, when client receives the incorrect frame, it will update new timeout value and receive again until correct frame is received or timeout
3. The filtering for server is made by just checking frame header
4. For code reuse, I replace sleeping() with get_interval() function
Signed-off-by: Xue Wenqian <wsn.iot.xwq@cn.fujitsu.com>
---
wpan-ping/wpan-ping.c | 86 ++++++++++++++++++++++++++++++-------------------
1 file changed, 53 insertions(+), 33 deletions(-)
diff --git a/wpan-ping/wpan-ping.c b/wpan-ping/wpan-ping.c
index e6df2b4..15a2a4b 100644
--- a/wpan-ping/wpan-ping.c
+++ b/wpan-ping/wpan-ping.c
@@ -235,28 +235,30 @@ static int print_address(char *addr, uint8_t dst_extended[IEEE802154_ADDR_LEN])
return 0;
}
-static void sleeping(struct timeval ping_start_time, struct timeval timeout) {
- struct timeval curr_time;
- long sec, usec, interval_usec, timeout_usec;
- long sleep_usec = 0;
- gettimeofday(&curr_time, NULL);
- sec = curr_time.tv_sec - ping_start_time.tv_sec;
- usec = curr_time.tv_usec - ping_start_time.tv_usec;
- if (usec < 0) {
- usec += 1000000;
- sec--;
+/* time interval computation */
+static long get_interval(struct timeval start_time, struct timeval end_time, long timeout_usec) {
+ long sec, usec, usecs, interval_usec = 0;
+ sec = end_time.tv_sec - start_time.tv_sec;
+ usec = end_time.tv_usec - start_time.tv_usec;
+ usecs = sec * 1000000 + usec;
+ if (usecs < timeout_usec) {
+ interval_usec = timeout_usec - usecs;
}
- interval_usec = sec * 1000000 + usec;
- timeout_usec = timeout.tv_sec * 1000000 + timeout.tv_usec;
- if (interval_usec < timeout_usec) {
- sleep_usec = timeout_usec - interval_usec;
- usleep(sleep_usec);
+ return interval_usec;
+}
+
+/* recv timeout setting */
+static void set_so_rcvtimeo(int sd, struct timeval timeout) {
+ int ret;
+ ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout, sizeof(struct timeval));
+ if (ret < 0) {
+ perror("setsockopt receive timeout");
}
}
static int measure_roundtrip(struct config *conf, int sd) {
unsigned char *buf;
- struct timeval ping_start_time, start_time, end_time, timeout;
+ struct timeval ping_start_time, start_time, end_time, ping_end_time, timeout, new_timeout;
long sec = 0, usec = 0;
long sec_max = 0, usec_max = 0;
long sec_min = 2147483647, usec_min = 2147483647;
@@ -266,6 +268,8 @@ static int measure_roundtrip(struct config *conf, int sd) {
float rtt_min = 0.0, rtt_avg = 0.0, rtt_max = 0.0;
float packet_loss = 100.0;
char addr[24];
+ long timeout_usec, interval_usec, sleep_usec;
+ int set_so_rcvtimeo_flag;
if (conf->extended)
print_address(addr, conf->dst.addr.hwaddr);
@@ -287,10 +291,9 @@ static int measure_roundtrip(struct config *conf, int sd) {
timeout.tv_sec = 0;
timeout.tv_usec = conf->interval * 1000;
}
- ret = setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&timeout,sizeof(struct timeval));
- if (ret < 0) {
- perror("setsockopt receive timeout");
- }
+ timeout_usec = conf->interval * 1000;
+ set_so_rcvtimeo(sd, timeout);
+ set_so_rcvtimeo_flag = 1;
count = 0;
for (i = 0; i < conf->packets; i++) {
@@ -302,13 +305,24 @@ static int measure_roundtrip(struct config *conf, int sd) {
perror("sendto");
}
gettimeofday(&start_time, NULL);
- ret = recv(sd, buf, conf->packet_len, 0);
- if (seq_num != ((buf[2] << 8)| buf[3])) {
- printf("Sequenze number did not match\n");
- continue;
+ while(1) {
+ ret = recv(sd, buf, conf->packet_len, 0);
+ gettimeofday(&end_time, NULL);
+ interval_usec = get_interval(ping_start_time, end_time, timeout_usec);
+ if (interval_usec > 0 && (buf[0] != '\000' || seq_num != ((buf[2] << 8)| buf[3]))) {
+ fprintf(stderr, "Packet %i: Sequence number did not match, receive again!\n", i);
+ new_timeout.tv_sec = (int)(interval_usec * 1.0 / 1000000);
+ new_timeout.tv_usec = interval_usec - (new_timeout.tv_sec * 1000000);
+ set_so_rcvtimeo(sd, new_timeout);
+ set_so_rcvtimeo_flag = 0;
+ } else {
+ if (set_so_rcvtimeo_flag == 0) {
+ set_so_rcvtimeo(sd, timeout);
+ }
+ break;
+ }
}
if (ret > 0) {
- gettimeofday(&end_time, NULL);
count++;
sec = end_time.tv_sec - start_time.tv_sec;
sum_sec += sec;
@@ -338,9 +352,13 @@ static int measure_roundtrip(struct config *conf, int sd) {
fprintf(stdout, "%i bytes from 0x%04x seq=%i time=%.1f ms\n", ret,
conf->dst.addr.short_addr, (int)seq_num, (float)usec/1000);
} else
- fprintf(stderr, "Hit %i ms packet timeout\n", conf->interval);
+ fprintf(stderr, "Packet %i: Hit %i ms packet timeout\n", i, conf->interval);
/* sleeping */
- sleeping(ping_start_time, timeout);
+ gettimeofday(&ping_end_time, NULL);
+ sleep_usec = get_interval(ping_start_time, ping_end_time, timeout_usec);
+ if (sleep_usec > 0) {
+ usleep(sleep_usec);
+ }
}
if (count)
@@ -386,11 +404,13 @@ static void init_server(int sd) {
#if DEBUG
dump_packet(buf, len);
#endif
- /* Send same packet back */
- len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
- if (len < 0) {
- perror("sendto");
- continue;
+ if (buf[0] == '\000') {
+ /* Send same packet back */
+ len = sendto(sd, buf, len, 0, (struct sockaddr *)&src, addrlen);
+ if (len < 0) {
+ perror("sendto");
+ continue;
+ }
}
}
free(buf);
@@ -559,4 +579,4 @@ int main(int argc, char *argv[]) {
init_network(conf);
free(conf);
return 0;
-}
+}
\ No newline at end of file
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Arend Van Spriel @ 2016-12-15 20:15 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Wolfgang Grandegger, Marc Kleine-Budde, Vince Bridgers,
Jay Cliburn, Chris Snook, Luis R. Rodriguez, Kalle Valo,
Maya Erez, Franky Lin, Hante Meuleman, Stanislaw Gruszka,
Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Jakub Kicinski, Larry Finger, Chaoming Li,
Greg Kroah-Hartman, David S. Miller, Alexander Aring,
Stefan Schmidt, Matthias Brugger, linux-bluetooth, linux-can,
netdev, nios2-dev, linux-wireless, wil6210,
brcm80211-dev-list.pdl, devel, linux-wpan, linux-arm-kernel,
linux-mediatek
In-Reply-To: <1481778865-27667-9-git-send-email-mst@redhat.com>
On 15-12-2016 6:15, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
For brcm80211 drivers:
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v6 1/3] ieee802154: Add CA8210 IEEE 802.15.4 device driver
From: Alexander Aring @ 2016-12-15 20:06 UTC (permalink / raw)
To: h.morris; +Cc: harrymorris12, linux-wpan, stefan, marcel
In-Reply-To: <98cb5f50-2e9b-5414-88c0-d8323a547152@cascoda.com>
Hi,
On 12/15/2016 02:52 PM, Harry Morris wrote:
> Hi Alex,
>
> On 12/12/2016 14:27, Alexander Aring wrote:
>> All these spi stuff is low-level spi functionality, why not simple use
>> the spi helper functions. E.g. "spi_write_then_read" and I don't mean
>> only just this code, I mean every code here.
>>
>> Low-level is _maybe_ needed if you using async api.
> As far as I can see, I'm unable to use the helper functions because I need (effectively) manual control of the spi chip select. The way the ca8210 API works I don't know how many bytes I'm reading in total until I read the "command length" byte. So I need to read two bytes, keep the chip select asserted while I process the length and then read the rest of the data. This is the same for the tx path since the ca8210 operates in full duplex mode, so when transmitting I may also be receiving a command that is longer than what I am transmitting so there is a risk of me de-asserting the chip select too early using a helper. Maybe I'm not completely understanding how the helpers work though.
>
Sorry to say that, but ... this is impossible with the spi subsystem.
I mean it's possible, but if you doing that there exists spi controller
drivers/hardware stuff which doesn't support it. The cs_change property
doesn't work on all hardware.
People told me to avoid it, otherwise I could easy implement receive
handling at at86rf230 driver to not drop cs after framebuffer read.
Deasserting cs after framebuffer read will drop the framebuffer
protection there and new frames can overwrite the framebuffer...
We currently always read the whole framebuffer instead first fetching
the length and then read the length only.
Is something somehow possible in your case? You should be careful using
cs_change attribute it doesn't work on all hardware.
>>> + msdulen = data_ind[22]; /* msdu_length */
>>> + if (msdulen > 127) {
>> use ieee802154_is_valid_psdu_len.
>>
>> Also this is psdu_len, in case of monitors -> monitors will filter then
>> minimum ACK frame length only.
> So the reason for this is that this *is* actually msdu length and not psdu length. What's being received is an MCPS-DATA.indication, so the chip has already performed the is_valid_psdu_len check in its MAC. Truthfully this check is probably completely unnecessary, I just added it in case something gets messed up over the SPI but I've never seen it happen. Maybe it should be removed altogether, I just thought it's a simple check to perform that could easily highlight a big problem.
>
ah, ok. If you know what the firmware filters and what not, then
everything is fine. I did the expierence e.g. at at86rf230 it's simple
not documented what they filter for length at firmware side...
but you know the firmware so everything fine.
>>> + dev_err(
>>> + &priv->spi->dev,
>>> + "received erroneously large msdu length!\n"
>>> + );
>>> + kfree_skb(skb);
>>> + return -EMSGSIZE;
>>> + }
>>> + dev_dbg(&priv->spi->dev, "skb buffer length = %d\n", msdulen);
>>> +
>>> + /* Populate hdr *
>> Doing header parsing below here will not work with monitors, monitors
>> can also receive stuff which are smaller than 29 - I don't know what's
>> already filtered on firmware side.
> Again the hardware MAC will have already filtered out any frames that are not valid data frames, so the header of the data indication will always be a fixed 29 bytes.
You are sure about this? If you receiving ack frames there will no
addressing stuff and you will parse the frame here at positions without
length checking if it's such frame.
I can understand if you saying "ack" frames will never hit the driver,
but begin to parse frames here... I don't know exactly the "why"?
802.15.4 frame parsing is very complex and we should some one code for
SoftMAC to do that.
>>
>> I see the driver doesn't implement any promiscuousmode functionality,
>> you need to care about that if you will add support for that later.
> When it comes to promiscuous mode, the psdu is just copied into the msdu of the data indication. So again there will be a fixed 29 byte header on the front, just the contents is meaningless (zeroed). Again this is because the specification doesn't say how promiscuous frames are to be passed out of the MAC.
>>> + hdr.sec.level = data_ind[29 + msdulen];
>>> + dev_dbg(&priv->spi->dev, "security level: %#03x\n", hdr.sec.level);
>>> + if (hdr.sec.level > 0) {
>>> + hdr.sec.key_id_mode = data_ind[30 + msdulen];
>>> + memcpy(&hdr.sec.extended_src, &data_ind[31 + msdulen], 8);
>>> + hdr.sec.key_id = data_ind[39 + msdulen];
>>> + }
>>> + hdr.source.mode = data_ind[0];
>>> + dev_dbg(&priv->spi->dev, "srcAddrMode: %#03x\n", hdr.source.mode);
>>> + hdr.source.pan_id = *(u16 *)&data_ind[1];
>>> + dev_dbg(&priv->spi->dev, "srcPanId: %#06x\n", hdr.source.pan_id);
>>> + memcpy(&hdr.source.extended_addr, &data_ind[3], 8);
>>> + hdr.dest.mode = data_ind[11];
>>> + dev_dbg(&priv->spi->dev, "dstAddrMode: %#03x\n", hdr.dest.mode);
>>> + hdr.dest.pan_id = *(u16 *)&data_ind[12];
>>> + dev_dbg(&priv->spi->dev, "dstPanId: %#06x\n", hdr.dest.pan_id);
>>> + memcpy(&hdr.dest.extended_addr, &data_ind[14], 8);
>>> +
>>> + /* Fill in FC implicitly */
>>> + hdr.fc.type = 1; /* Data frame */
>>> + if (hdr.sec.level)
>>> + hdr.fc.security_enabled = 1;
>>> + else
>>> + hdr.fc.security_enabled = 0;
>>> + if (data_ind[1] != data_ind[12] || data_ind[2] != data_ind[13])
>>> + hdr.fc.intra_pan = 1;
>>> + else
>>> + hdr.fc.intra_pan = 0;
>>> + hdr.fc.dest_addr_mode = hdr.dest.mode;
>>> + hdr.fc.source_addr_mode = hdr.source.mode;
>>> +
>>> + /* Add hdr to front of buffer */
>>> + hlen = ieee802154_hdr_push(skb, &hdr);
>>> +
>>> + if (hlen < 0) {
>>> + dev_crit(&priv->spi->dev, "failed to push mac hdr onto skb!\n");
>>> + kfree_skb(skb);
>>> + return hlen;
>>> + }
>>> +
>>> + skb_reset_mac_header(skb);
>>> + skb->mac_len = hlen;
>>> +
>>> + /* Add <msdulen> bytes of space to the back of the buffer */
>>> + /* Copy msdu to skb */
>>> + memcpy(skb_put(skb, msdulen), &data_ind[29], msdulen);
>>> +
>>> + ieee802154_rx_irqsafe(hw, skb, data_ind[23]/*LQI*/);
>>> + /* TODO: Set protocol & checksum? */
>>> + /* TODO: update statistics */
>>> + return 0;
>>> +}
>>> +
>>> +/**
>>> + * ca8210_net_rx() - Acts upon received SAP commands relevant to the network
>>> + * driver
>>> + * @hw: ieee802154_hw that command was received by
>>> + * @command: Octet array of received command
>>> + * @len: length of the received command
>>> + *
>>> + * Called by the spi driver whenever a SAP command is received, this function
>>> + * will ascertain whether the command is of interest to the network driver and
>>> + * take necessary action.
>>> + *
>>> + * Return: 0 or linux error code
>>> + */
>>> +static int ca8210_net_rx(struct ieee802154_hw *hw, u8 *command, size_t len)
>>> +{
>>> + struct ca8210_priv *priv = hw->priv;
>>> + unsigned long flags;
>>> + u8 status;
>>> +
>>> + dev_dbg(&priv->spi->dev, "ca8210_net_rx(), CmdID = %d\n", command[0]);
>>> +
>>> + if (command[0] == SPI_MCPS_DATA_INDICATION) {
>>> + /* Received data */
>>> + spin_lock_irqsave(&priv->lock, flags);
>>> + if (command[26] == priv->last_dsn) {
>>> + dev_dbg(
>>> + &priv->spi->dev,
>>> + "DSN %d resend received, ignoring...\n",
>>> + command[26]
>>> + );
>>> + spin_unlock_irqrestore(&priv->lock, flags);
>>> + return 0;
>>> + }
>>> + priv->last_dsn = command[26];
>>> + spin_unlock_irqrestore(&priv->lock, flags);
>>> + return ca8210_skb_rx(hw, len - 2, command + 2);
>>> + } else if (command[0] == SPI_MCPS_DATA_CONFIRM) {
>>> + status = command[3];
>>> + if (priv->async_tx_pending) {
>>> + return ca8210_async_xmit_complete(
>>> + hw,
>>> + command[2],
>>> + status
>>> + );
>>> + } else if (priv->sync_tx_pending) {
>>> + priv->sync_tx_pending = false;
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/**
>>> + * ca8210_skb_tx() - Transmits a given socket buffer using the ca8210
>>> + * @skb: Socket buffer to transmit
>>> + * @msduhandle: Data identifier to pass to the 802.15.4 MAC
>>> + * @priv: Pointer to private data section of target ca8210
>>> + *
>>> + * Return: 0 or linux error code
>>> + */
>>> +static int ca8210_skb_tx(
>>> + struct sk_buff *skb,
>>> + u8 msduhandle,
>>> + struct ca8210_priv *priv
>>> +)
>>> +{
>>> + int status;
>>> + struct ieee802154_hdr header = { 0 };
>>> + struct secspec secspec;
>>> + unsigned int mac_len;
>>> +
>>> + dev_dbg(&priv->spi->dev, "ca8210_skb_tx() called\n");
>>> +
>>> + /* Get addressing info from skb - ieee802154 layer creates a full
>>> + * packet
>>> + */
>>> + mac_len = ieee802154_hdr_peek_addrs(skb, &header);
>>> +
>> you need at least check if error occurred. Currently we support at least
>> 3 bytes FC + SEQ is there at driver level...
> Sorry but I'm not sure I understand what you mean, do I need to check for errors in the skb I'm being told to transmit? Over-air error checking is performed by the ca8210 with the use of a frame counter so maybe this doesn't apply to this situation?
I want to say here, it's possible that this transmit function get's at
least 3 bytes from userspace. Parsing addresses will fail here, because
the header is too small -> it will transmit random data.
>
>>> +/**
>>> + * ca8210_xmit_sync() - Synchronously transmits a given socket buffer using the
>>> + * ca8210
>>> + * @hw: ieee802154_hw of ca8210 to transmit from
>>> + * @skb: Socket buffer to transmit
>>> + *
>>> + * Transmits the buffer and does not return until a confirmation of the exchange
>>> + * is received from the ca8210.
>>> + *
>>> + * Return: 0 or linux error code
>>> + */
>>> +static int ca8210_xmit_sync(struct ieee802154_hw *hw, struct sk_buff *skb)
>>> +{
>>> + struct ca8210_priv *priv = hw->priv;
>>> + int status;
>>> +
>>> + dev_dbg(&priv->spi->dev, "calling ca8210_xmit_sync()\n");
>>> +
>>> + status = ca8210_skb_tx(skb, priv->nextmsduhandle++, priv);
>>> + if (status)
>>> + return status;
>>> +
>>> + priv->sync_tx_pending = true;
>>> +
>>> + while (priv->sync_tx_pending)
>>> + msleep(1);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/**
>>> + * ca8210_xmit_async() - Asynchronously transmits a given socket buffer using
>>> + * the ca8210
>>> + * @hw: ieee802154_hw of ca8210 to transmit from
>>> + * @skb: Socket buffer to transmit
>>> + *
>>> + * Hands the transmission of the buffer off to a workqueue and returns
>>> + * immediately.
>>> + *
>>> + * Return: 0 or linux error code
>>> + */
>>> +static int ca8210_xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb)
>>> +{
>>> + struct ca8210_priv *priv = hw->priv;
>>> +
>>> + dev_dbg(&priv->spi->dev, "calling ca8210_xmit_async()\n");
>>> +
>>> + priv->tx_skb = skb;
>>> + queue_work(priv->async_tx_workqueue, &priv->async_tx_work);
>>> +
>>> + return 0;
>>> +}
>>> +
>> Okay, both sync and async are here implemented for that the callbacks
>> are never made for.
>>
>> The above sync function looks like an synced operation around a async
>> operation, because you wait until it's finished.
>>
>> More bad, you use busy-waiting there, look for "wait_for_completion" in
>> linux kernel.
>>
>> Nevertheless, the sync operation will not be used when async is defined,
>> so sync operation is useless here.
>>
>> THe idea of async is that the Linux kernel doesn't do _anything_ until a
>> tx complete irq reports "tx is done" and wake the tx queue again. This
>> will not happen if you queue it to a workqueue again... which makes the
>> whole stuff synced again.
>>
>> If we one day have MLME-OPS it needs a synced xmit functionality ->
>> which will use xmit_async then - because we can and need transmit stuff
>> synced. But NOT for dataplane -> dataframes, these frames should be
>> synced completely undepended from linux kernel. The kernel doesn't wait
>> until it's done -> hardware will report it when it's done.
>>
>> The issue will begin when we have synced xmit above async
>> functionality... Then we have a workqueue above a workqueue which is bad.
> Okay so I've probably misunderstood how the sync and async functions should be implemented, sorry about that. I am still a bit confused though.
> Regarding async, you say I shouldn't use a workqueue, but the context is atomic right? So if I follow my transmission path directly it will call spi_sync which can sleep. Does this mean that I *have* to use spi_async() instead? That would be a shame since it will make transmission a lot more complicated because I have to perform multiple spi exchanges to read the correct length.
>
Yes, async is the right way to do it.
What the callback of netdevice xmit_do is "send the frame out" queue
this into a workqueue will delay it and drop the context of netdevice
xmit_do function...
You should use async in xmit_do and irq handling.
> Would it maybe be better just to implement xmit_sync and not xmit_async? Is that acceptable since it's to be deprecated? Using wait_for_completion definitely seems like a good idea though, thanks for pointing that out.
> The reason why it looks async is because of the use of the management entity primitives - the transmission path is sending an MCPS-DATA.request command and then waiting for an MCPS-DATA.confirm to come back from the chip, confirming successful transmission. Just sending the request to the chip does not guarantee that the frame was or will be transmitted.
We don't need a confirmation that the frame was transmitted here. This
is what the netdev do_xmit is for.
To handle timeout -> there exists some watchdog handler if no "tx done"
irq will be occured or the netdevice is somehow stucked.
At least at the "tx_done" irq we need some way to get knowledge about if
there was an ack or not... but this is future work.
- Alex
[0] http://lxr.free-electrons.com/source/include/linux/spi/spi.h#L678
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Lee Duncan @ 2016-12-15 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Russell King, Alasdair Kergon, Mike Snitzer, dm-devel, Shaohua Li,
Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, Greg Kroah-Hartman, Jiri Slaby,
Chris Leech, James E.J. Bottomley, Martin K. Petersen,
Nicholas A. Bellinger, Jason Wang, Alexander Aring,
Stefan Schmidt, David S. Miller, linux-arm-kernel,
linux-samsung-soc, linux-raid, netdev, linux-wireless, linux-mm,
open-iscsi, linux-scsi, target-devel, virtualization, linux-wpan
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On 12/14/2016 09:15 PM, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> index 21391fa..e55d1f5 100644
> --- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> +++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> @@ -26,7 +26,7 @@
>
> #include <linux/types.h>
>
> -typedef unsigned int __bitwise__ samsung_gpio_pull_t;
> +typedef unsigned int __bitwise samsung_gpio_pull_t;
>
> /* forward declaration if gpio-core.h hasn't been included */
> struct samsung_gpio_chip;
> diff --git a/drivers/md/dm-cache-block-types.h b/drivers/md/dm-cache-block-types.h
> index bed4ad4..389c9e8 100644
> --- a/drivers/md/dm-cache-block-types.h
> +++ b/drivers/md/dm-cache-block-types.h
> @@ -17,9 +17,9 @@
> * discard bitset.
> */
>
> -typedef dm_block_t __bitwise__ dm_oblock_t;
> -typedef uint32_t __bitwise__ dm_cblock_t;
> -typedef dm_block_t __bitwise__ dm_dblock_t;
> +typedef dm_block_t __bitwise dm_oblock_t;
> +typedef uint32_t __bitwise dm_cblock_t;
> +typedef dm_block_t __bitwise dm_dblock_t;
>
> static inline dm_oblock_t to_oblock(dm_block_t b)
> {
> diff --git a/drivers/net/ethernet/sun/sunhme.h b/drivers/net/ethernet/sun/sunhme.h
> index f430765..4a8d5b1 100644
> --- a/drivers/net/ethernet/sun/sunhme.h
> +++ b/drivers/net/ethernet/sun/sunhme.h
> @@ -302,7 +302,7 @@
> * Always write the address first before setting the ownership
> * bits to avoid races with the hardware scanning the ring.
> */
> -typedef u32 __bitwise__ hme32;
> +typedef u32 __bitwise hme32;
>
> struct happy_meal_rxd {
> hme32 rx_flags;
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> index 1ad0ec1..84813b5 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> @@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
> IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
> };
>
> -typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
> +typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
>
> /**
> * enum iwl_ucode_tlv_api - ucode api
> @@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
> #endif
> };
>
> -typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
> +typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
>
> /**
> * enum iwl_ucode_tlv_capa - ucode capabilities
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0f088f3..36d9896 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -246,7 +246,7 @@ struct lruvec {
> #define ISOLATE_UNEVICTABLE ((__force isolate_mode_t)0x8)
>
> /* LRU Isolation modes. */
> -typedef unsigned __bitwise__ isolate_mode_t;
> +typedef unsigned __bitwise isolate_mode_t;
>
> enum zone_watermarks {
> WMARK_MIN,
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 5d49488..5def8e8 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -111,8 +111,8 @@ struct uart_icount {
> __u32 buf_overrun;
> };
>
> -typedef unsigned int __bitwise__ upf_t;
> -typedef unsigned int __bitwise__ upstat_t;
> +typedef unsigned int __bitwise upf_t;
> +typedef unsigned int __bitwise upstat_t;
>
> struct uart_port {
> spinlock_t lock; /* port lock */
> diff --git a/include/linux/types.h b/include/linux/types.h
> index baf7183..d501ad3 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
> typedef u32 dma_addr_t;
> #endif
>
> -typedef unsigned __bitwise__ gfp_t;
> -typedef unsigned __bitwise__ fmode_t;
> +typedef unsigned __bitwise gfp_t;
> +typedef unsigned __bitwise fmode_t;
>
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> typedef u64 phys_addr_t;
> diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
> index c1260d8..df156f1 100644
> --- a/include/scsi/iscsi_proto.h
> +++ b/include/scsi/iscsi_proto.h
> @@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
> #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
>
> /* initiator tags; opaque for target */
> -typedef uint32_t __bitwise__ itt_t;
> +typedef uint32_t __bitwise itt_t;
> /* below makes sense only for initiator that created this tag */
> #define build_itt(itt, age) ((__force itt_t)\
> ((itt) | ((age) << ISCSI_AGE_SHIFT)))
> diff --git a/include/target/target_core_base.h b/include/target/target_core_base.h
> index c211900..0055828 100644
> --- a/include/target/target_core_base.h
> +++ b/include/target/target_core_base.h
> @@ -149,7 +149,7 @@ enum se_cmd_flags_table {
> * Used by transport_send_check_condition_and_sense()
> * to signal which ASC/ASCQ sense payload should be built.
> */
> -typedef unsigned __bitwise__ sense_reason_t;
> +typedef unsigned __bitwise sense_reason_t;
>
> enum tcm_sense_reason_table {
> #define R(x) (__force sense_reason_t )(x)
> diff --git a/include/uapi/linux/virtio_types.h b/include/uapi/linux/virtio_types.h
> index e845e8c..55c3b73 100644
> --- a/include/uapi/linux/virtio_types.h
> +++ b/include/uapi/linux/virtio_types.h
> @@ -39,8 +39,8 @@
> * - __le{16,32,64} for standard-compliant virtio devices
> */
>
> -typedef __u16 __bitwise__ __virtio16;
> -typedef __u32 __bitwise__ __virtio32;
> -typedef __u64 __bitwise__ __virtio64;
> +typedef __u16 __bitwise __virtio16;
> +typedef __u32 __bitwise __virtio32;
> +typedef __u64 __bitwise __virtio64;
>
> #endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
> diff --git a/net/ieee802154/6lowpan/6lowpan_i.h b/net/ieee802154/6lowpan/6lowpan_i.h
> index 5ac7789..ac7c96b 100644
> --- a/net/ieee802154/6lowpan/6lowpan_i.h
> +++ b/net/ieee802154/6lowpan/6lowpan_i.h
> @@ -7,7 +7,7 @@
> #include <net/inet_frag.h>
> #include <net/6lowpan.h>
>
> -typedef unsigned __bitwise__ lowpan_rx_result;
> +typedef unsigned __bitwise lowpan_rx_result;
> #define RX_CONTINUE ((__force lowpan_rx_result) 0u)
> #define RX_DROP_UNUSABLE ((__force lowpan_rx_result) 1u)
> #define RX_DROP ((__force lowpan_rx_result) 2u)
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index d37a577..b2069fb 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -159,7 +159,7 @@ enum ieee80211_bss_valid_data_flags {
> IEEE80211_BSS_VALID_ERP = BIT(3)
> };
>
> -typedef unsigned __bitwise__ ieee80211_tx_result;
> +typedef unsigned __bitwise ieee80211_tx_result;
> #define TX_CONTINUE ((__force ieee80211_tx_result) 0u)
> #define TX_DROP ((__force ieee80211_tx_result) 1u)
> #define TX_QUEUED ((__force ieee80211_tx_result) 2u)
> @@ -180,7 +180,7 @@ struct ieee80211_tx_data {
> };
>
>
> -typedef unsigned __bitwise__ ieee80211_rx_result;
> +typedef unsigned __bitwise ieee80211_rx_result;
> #define RX_CONTINUE ((__force ieee80211_rx_result) 0u)
> #define RX_DROP_UNUSABLE ((__force ieee80211_rx_result) 1u)
> #define RX_DROP_MONITOR ((__force ieee80211_rx_result) 2u)
>
For iscsi initiator, looks good.
Akced-by: Lee Duncan <lduncan@suse.com>
--
Lee Duncan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox