Skip to content

Conversation

@tbursztyka
Copy link
Contributor

@tbursztyka tbursztyka commented Nov 3, 2017

This is a takeover of the PR #60

With proper style applied, all unaccepted part removed, and further improvements on top.
Wifi control interface (via net-mgmt) worked out.

@tbursztyka
Copy link
Contributor Author

I still don't get why github shows the commit in the wrong order...

@galak
Copy link
Contributor

galak commented Nov 3, 2017

I'm going to close #60 than, since this takes it over.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch could be sent separately as this is not winc1500 related.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was part of original PR, plus: this driver is the one making use of that change.

In a way this PR is more an Net OFFLOAD show off than just a wifi driver only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are going to remove offload driver from l2, then we could do it right away. No need to wait for the winc1500 driver here. There are no other offloading device available so doing this removal is fine imho.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if you want to keep it part of this set, then that is fine too. It just looked like the first commit could be separated from this set.

@pfalcon pfalcon requested review from GAnthony and jukkar November 3, 2017 17:27
@pfalcon
Copy link
Contributor

pfalcon commented Nov 3, 2017

Btw, I hope interested parties are aware that WINC1500 supports proper L2 integration mode (Ethernet emulation, as common), so could be integrated without NET_OFFLOAD hacks. (Just a FYI note.)

@tbursztyka
Copy link
Contributor Author

@pfalcon I noticed it, looking at the HAL. However, that won't fit with future work bringing wifi generic net_mgmt interface. Also, in future, we could make the net stack building only the bare necessary parts when there would be only offloaded interface(s), to reduce the amount of code on host side. Such a thing we could not do if winc1500 appears as an ethernet interface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this line can be omitted because we are already adding this path in

ext/hal/atmel/asf/common/components/wifi/winc1500/CMakeLists.txt

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is redundant with something done in drivers/wifi/CMakeLists.txt and can be removed.

@tbursztyka
Copy link
Contributor Author

@SebastianBoe Thanks, indeed works just fine.

@tbursztyka tbursztyka force-pushed the winc1500 branch 4 times, most recently from b0a431f to 31407af Compare November 15, 2017 13:18
@tbursztyka tbursztyka changed the title (do not merge yet) WINC1500 Support WINC1500 Support Nov 15, 2017
@tbursztyka
Copy link
Contributor Author

@SebastianBoe I applied your changes btw.

@SebastianBoe
Copy link
Contributor

@tbursztyka : Please treat my +1 as a 0. I did not mean to affect the merge-ability, only give some feedback.

@tbursztyka
Copy link
Contributor Author

@SebastianBoe ok

@tbursztyka
Copy link
Contributor Author

I'll remove this TEST patch, which is not meant to get in the tree anyway.

@tbursztyka
Copy link
Contributor Author

@galak there are already ASF components into ext/hal. Does that mean that everytime a bit of code goes to ext/hal it needs to go through TSC? (First time I play in that ext field, so just asking)

@galak
Copy link
Contributor

galak commented Apr 13, 2018

@galak there are already ASF components into ext/hal. Does that mean that everytime a bit of code goes to ext/hal it needs to go through TSC? (First time I play in that ext field, so just asking)

Yes, we haven't been great about this, but any new import of code int EXT needs to go through the TSC and board for license review.

@tbursztyka
Copy link
Contributor Author

@galak ok, how do we arrange that then?

@nashif
Copy link
Member

nashif commented May 4, 2018

@galak ok, how do we arrange that then?

@tbursztyka please create the README per http://docs.zephyrproject.org/contribute/contribute_non-apache.html and send it over to me.

@tbursztyka
Copy link
Contributor Author

@nashif See 13th commit of this PR. (I guess it won't need to be applied though?)

@nashif
Copy link
Member

nashif commented May 7, 2018

@nashif See 13th commit of this PR. (I guess it won't need to be applied though?)

thanks, I submitted this for review.

@galak
Copy link
Contributor

galak commented May 7, 2018

@nashif See 13th commit of this PR. (I guess it won't need to be applied though?)

thanks, I submitted this for review.

Any reason not to pull in the 3.39 release of asf? Also can we add somewhere in the readme where the code we are pull in is coming from inside of ASF since its a pretty large package (ie some comment about grabbing code from ./common/components/wifi/winc1500/drivers + whatever else we need to import).

@tbursztyka
Copy link
Contributor Author

Any reason not to pull in the 3.39 release of asf? Also can we add somewhere in the readme where the code we are pull in is coming from inside of ASF since its a pretty large package (ie some comment about grabbing code from ./common/components/wifi/winc1500/drivers + whatever else we need to import).

ASF is changing of minor version pretty fast (and this export dates already from last December), but the big issue is they change their API minor version after minor version. When I did the switch to 3.35 I had to change all the relevant code coming from legacy PR, which was not a small task. (And the API changes were only name changes, stupid code style changes like "let's use came case names now!" etc... no logic changes at all.) So it works with 3.35, let's just keep it that way.

@nashif
Copy link
Member

nashif commented May 10, 2018

this has been approved by the board now.

@tbursztyka
Copy link
Contributor Author

@galak can you unlock the PR?

@nashif
Copy link
Member

nashif commented May 15, 2018

@tbursztyka

Also can we add somewhere in the readme where the code we are pull in is coming from inside of ASF since its a pretty large package (ie some comment about grabbing code from ./common/components/wifi/winc1500/drivers + whatever else we need to import).

can you address this please?

Tomasz Bursztyka and others added 13 commits May 15, 2018 08:53
origin: extracted from Atmel ASF version 3.35.1

Signed-off-by: Tomasz Bursztyka <[email protected]>
Adding support for WINC1500 WiFi chip.

It introduces the wifi drivers sub-directory.

It provides a Full-MAC for 802.11 and an offloaded network stack as
well. The driver uses Atmel's winc1500 HAL.

Signed-off-by: Dario Pennisi <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Massimiliano Agneni <[email protected]>
Signed-off-by: Tomasz Bursztyka <[email protected]>
Previous way was cumbersome (based on an old way for cc2520 actually),
so moving towards the more recent and proper way.

This will enable anybody to actually provide gpio configuration for a
winc1500 out of any board specific location.

Signed-off-by: Tomasz Bursztyka <[email protected]>
There is no point having undocumented and local config options when
Kconfig can be used to expose these relevantly.

Signed-off-by: Tomasz Bursztyka <[email protected]>
As legacy API is meant to be removed.

Signed-off-by: Tomasz Bursztyka <[email protected]>
This call is already made in nm_bus_wrapper along with SPI.
In nm_bus_wrapper however: moving the call out of #ifdefsf as it is
generic call, whatever bus would be choosen.

Signed-off-by: Tomasz Bursztyka <[email protected]>
This cleans up the callback functions and isolate each part to a
relevant handler to improve readability.

Signed-off-by: Tomasz Bursztyka <[email protected]>
These output are fine while debugging, but useless otherwise.

Signed-off-by: Tomasz Bursztyka <[email protected]>
It does not seem to be useful atm. So let's remove it.

Signed-off-by: Tomasz Bursztyka <[email protected]>
Scan, connect and disconnect for now.

Signed-off-by: Tomasz Bursztyka <[email protected]>
There will be other drivers, and mixing up all these files together will
create a mess so better having a dedicated place for winc1500, at least.

Signed-off-by: Tomasz Bursztyka <[email protected]>
Enabling relevant hardware, currently only winc1500 on
quark_se_c1000_devboard. But it could be easily extended to other
drivers/boards.

Signed-off-by: Tomasz Bursztyka <[email protected]>
Atmel ASF is BSD-3-Clause

Signed-off-by: Tomasz Bursztyka <[email protected]>
@tbursztyka
Copy link
Contributor Author

updated. Looks like newer version of ASF are again different in were they put code... (for instance 3.37 embeds also all the stupid tiny examples in the winc1500 common directory)

@nashif nashif merged commit 89ac6b5 into zephyrproject-rtos:master May 17, 2018
@tbursztyka tbursztyka deleted the winc1500 branch May 17, 2018 12:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Networking EXT Has change or related to ext/ (obsolete)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants