* Re: question: crda timeout in cfg80211
From: Johannes Berg @ 2019-04-08 19:06 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko
In-Reply-To: <20190326124209.j6tdk5cz47kc6mdj@bars>
On Tue, 2019-03-26 at 12:42 +0000, Sergey Matyukevich wrote:
> Hi all,
>
> Linux cfg80211 regulatory subsystem uses CRDA timeout to ensure completion
> of regulatory updates, performed by user-space software. See call_crda
> functon in net/wireless/reg.c:
>
> static int call_crda(const char *alpha2)
> {
> ...
>
> queue_delayed_work(system_power_efficient_wq,
> &crda_timeout, msecs_to_jiffies(3142));
> return 0;
> }
>
> So regulatory update/reset operations shall be completed in 3142 msec.
> And that includes processing of regulatory notifiers for all the
> wireless cards in the system.
>
> It is not quite clear where this specific timeout value came from.
> Original commit (a90c7a313a1c5b) doesn't go into details about it.
>
> Any ideas where it could come from ?
No particular reason. It's just ~pi seconds, and IIRC Luis thought that
was funny :-)
Are you seeing any issues with that?
johannes
^ permalink raw reply
* Re: [RFC V3 1/2] mac80211: add hw 80211 encapsulation offloading support
From: Johannes Berg @ 2019-04-08 19:28 UTC (permalink / raw)
To: John Crispin, Kalle Valo
Cc: linux-wireless, Shashidhar Lakkavalli, Vasanthakumar Thiagarajan
In-Reply-To: <20190401131416.22646-2-john@phrozen.org>
On Mon, 2019-04-01 at 15:14 +0200, John Crispin wrote:
>
> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP: Hardware/driver supports 802.11
> + * encap for data frames.
What's this needed for,
> +void ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable);
if you have this?
But then again this one's missing docs so I don't yet know what it's
actually doing :-)
> /* reject WEP and TKIP keys if WEP failed to initialize */
> switch (params->cipher) {
> - case WLAN_CIPHER_SUITE_WEP40:
> case WLAN_CIPHER_SUITE_TKIP:
> + /* countermeasures wont work on encap offload mode so reject
> + * TKIP keys
> + */
> + if (ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP))
> + return -EINVAL;
> +
> + /* drop through */
"fall through" I believe is needed to shut up the compiler about it.
But is this really a good idea? To do this completely only on the
support check, vs. what's currently active?
And I think it should probably just disable the encap offload, rather
than reject TKIP.
> @@ -2379,6 +2386,9 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
> if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
> ieee80211_check_fast_xmit_all(local);
>
> + if (ieee80211_is_hw_80211_encap(local))
> + return -EINVAL;
That seems misplaced? After checking fast_xmit? But again, similar as
above - IMHO it'd be better to disable encap offload.
> +void ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable)
> +{
> + struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
> + struct ieee80211_local *local = sdata->local;
> +
> + if (!sdata->dev)
> + return;
> +
> + if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP))
> + enable = 0;
false?
This should probably be a WARN_ON(), after all the driver is calling
this?
> + if (!ieee80211_hw_check(&local->hw, SUPPORTS_TX_FRAG) &&
> + (local->hw.wiphy->frag_threshold != (u32)-1))
> + enable = 0;
The driver might need to know that you overrode it, so return the actual
value?
This is also asymmetric with my comment above - if you don't allow
enabling it while fragmentation is enabled, but at the same time don't
disable it when trying to enable fragmentation, suddenly the order of
the two operations starts to matter and that might be rather confusing.
> + if (enable) {
> + sdata->dev->netdev_ops = &ieee80211_dataif_8023_ops;
Can we really play with that pointer like that? Though I guess the two
are identical except for the TX so it probably won't really matter.
> +bool ieee80211_is_hw_80211_encap(struct ieee80211_local *local)
Maybe rename to "have_vif_with" instead of "is"? That gets a bit long,
but you get the point.
> +++ b/net/mac80211/key.c
> @@ -197,6 +197,9 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
> key->conf.keyidx,
> sta ? sta->sta.addr : bcast_addr, ret);
>
> + if (sdata->hw_80211_encap)
> + return -EINVAL;
> +
Seems that should be inside the "out_unsupported" label:
> out_unsupported:
> switch (key->conf.cipher) {
> case WLAN_CIPHER_SUITE_WEP40:
or possibly even inside the switch.
> + if (ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP)) {
> + /* mac80211 always supports monitor unless we do 802.11
> + * encapsulation offloading.
> + */
> + hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_MONITOR);
> + hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_MONITOR);
> + }
I really think we need this to be more flexible, Intel hardware for
example can do encap offload per queue, so theoretically we could even
enable/disable it per *station*, but I'd settle for per *interface*.
Certainly we don't want to suddenly find that monitor mode is limited
when we enable this?
Also, you still always have a way to disable it, right?
> /* mac80211 doesn't support more than one IBSS interface right now */
> for (i = 0; i < hw->wiphy->n_iface_combinations; i++) {
> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
> index 5b9952b1caf3..8feafaab88a4 100644
> --- a/net/mac80211/status.c
> +++ b/net/mac80211/status.c
> @@ -1019,6 +1019,85 @@ void ieee80211_tx_rate_update(struct ieee80211_hw *hw,
> }
> EXPORT_SYMBOL(ieee80211_tx_rate_update);
>
> +void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct sk_buff *skb)
Do we really need this, vs. just using ieee80211_tx_status_noskb()?
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1253,7 +1253,8 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
> (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
> return NULL;
>
> - if (unlikely(!ieee80211_is_data_present(hdr->frame_control))) {
> + if (!info->control.hw_80211_encap &&
> + unlikely(!ieee80211_is_data_present(hdr->frame_control))) {
> if ((!ieee80211_is_mgmt(hdr->frame_control) ||
> ieee80211_is_bufferable_mmpdu(hdr->frame_control) ||
> vif->type == NL80211_IFTYPE_STATION) &&
That could use a comment, I had to think about it for a while ;-)
> @@ -1400,6 +1401,7 @@ static void ieee80211_txq_enqueue(struct ieee80211_local *local,
> struct fq *fq = &local->fq;
> struct fq_tin *tin = &txqi->tin;
>
> + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
blank line should be after this, not before :)
> @@ -2357,9 +2359,9 @@ static inline bool ieee80211_is_tdls_setup(struct sk_buff *skb)
> skb->data[14] == WLAN_TDLS_SNAP_RFTYPE;
> }
>
> -static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
> - struct sk_buff *skb,
> - struct sta_info **sta_out)
> +int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
> + struct sk_buff *skb,
> + struct sta_info **sta_out)
> {
> struct sta_info *sta;
>
> @@ -2855,7 +2857,9 @@ void ieee80211_check_fast_xmit(struct sta_info *sta)
> struct ieee80211_chanctx_conf *chanctx_conf;
> __le16 fc;
>
> - if (!ieee80211_hw_check(&local->hw, SUPPORT_FAST_XMIT))
> + /* check for driver support and ieee80211 encap offload */
> + if (!ieee80211_hw_check(&local->hw, SUPPORT_FAST_XMIT) ||
> + sdata->hw_80211_encap)
> return;
Maybe we should treat encap offload as a sort of hardware-accelerated
fast-xmit, and enable/disable based on whether we'd normally
enable/disable fast-xmit? That way we already have all the
infrastructure for keeping track of whether we can use it or not, etc.
> /* Locking here protects both the pointer itself, and against concurrent
> @@ -3554,6 +3558,9 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
> hdr = (struct ieee80211_hdr *)skb->data;
> info = IEEE80211_SKB_CB(skb);
>
> + if (info->control.hw_80211_encap)
> + goto out;
I'm not sure this is right, you would probably still at least do the
ieee80211_tx_h_select_key() call a bit later, and possibly the A-MPDU
stuff?
You also don't assign the right vif pointer, which will probably work in
some cases but quite likely not in general.
Again, maybe treating it like fast-xmit-offload would make sense here,
and we could do this in ieee80211_xmit_fast_finish().
But that might very well not be the right model since fast-xmit is per
station, though the conditions are mostly not depending on the station,
except for auth/assoc state - which has the same issues with encap
offload though! Like ... you probably need to send EAPOL frames through
a non-encap-offload path?
> + /* TODO: Handle frames requiring wifi tx status to be notified */
:)
Maybe that means you do need ieee80211_tx_status_8023().
> + memset(info, 0, sizeof(*info));
> +
> + if (unlikely(sdata->control_port_protocol == ehdr->h_proto)) {
> + if (sdata->control_port_no_encrypt)
> + info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
> + info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO;
> + }
> +
> + if (multicast)
> + info->flags |= IEEE80211_TX_CTL_NO_ACK;
> +
> + info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
> +
> + ieee80211_tx_stats(dev, skb->len);
> +
> + if (sta) {
> + sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
> + sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
> + }
> +
> + if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
> + sdata = container_of(sdata->bss,
> + struct ieee80211_sub_if_data, u.ap);
> +
> + info->control.hw_80211_encap = true;
> + info->control.vif = &sdata->vif;
There's lots of duplicate code here, maybe split that out? Perhaps it
should be inlined, but then it can be an inline function to keep all the
stats etc.
> +netdev_tx_t ieee80211_subif_start_xmit_8023(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + struct sta_info *sta;
> +
> + if (WARN_ON(unlikely(!sdata->hw_80211_encap))) {
WARN_ON() contains unlikely()
> + if (ieee80211_lookup_ra_sta(sdata, skb, &sta))
> + goto out_free;
> +
> + ieee80211_8023_xmit(sdata, dev, sta, skb);
Does that handle ERR_PTR() sta correctly?
> @@ -4081,6 +4249,16 @@ static bool ieee80211_tx_pending_skb(struct ieee80211_local *local,
> }
> info->band = chanctx_conf->def.chan->band;
> result = ieee80211_tx(sdata, NULL, skb, true, 0);
> + } else if (info->control.hw_80211_encap) {
> + if (ieee80211_lookup_ra_sta(sdata, skb, &sta)) {
> + dev_kfree_skb(skb);
> + return true;
> + }
> +
> + if (IS_ERR(sta) || (sta && !sta->uploaded))
> + sta = NULL;
> +
> + result = ieee80211_tx_8023(sdata, skb, skb->len, sta, true);
This doesn't seem to make sense, how can you TX to a non-STA with encap
offload, you don't even know where to send the frame then?
johannes
^ permalink raw reply
* Re: Flag for detecting 802.11r Fast BSS Transition support
From: Johannes Berg @ 2019-04-08 19:52 UTC (permalink / raw)
To: Brian Norris, Matthew Wang; +Cc: linux-wireless, Kirtika Ruchandani
In-Reply-To: <20190403210200.GA93453@google.com>
On Wed, 2019-04-03 at 14:02 -0700, Brian Norris wrote:
> + Johannes
>
> On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> > Hi,
> >
> > I'm wondering if there is a flag for detecting firmware/driver support
> > for FT. It seems like checking for SME support is a pretty good proxy
> > for this, but there is a non-mac80211 driver that can do FT as well
> > (ath/wil6210). It would be great if anyone knows of a feature flag
> > specifically for FT.
>
> I chatted with Johannes, and he agreed that there was no such flag
> today. It also sounded like he was open to adding one, even if it's
> several years too late. I don't think there's any useful way people
> could (generically) use FT support today.
I guess I'm not really sure if the flag is needed, but I guess like the
original question says, it'd be more about non-mac80211 drivers.
So I guess you'd have to figure out what operations the drivers need to
support then? I'm not even sure how wpa_s would handle this for SME
offload devices.
johannes
^ permalink raw reply
* Re: [PATCH v2 0/4] Extended Key ID support
From: Johannes Berg @ 2019-04-08 19:57 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <20190319203410.25145-1-alexander@wetzel-home.de>
On Tue, 2019-03-19 at 21:34 +0100, Alexander Wetzel wrote:
> This patch series adds support for IEEE 802.11-2016 Extended Key ID
> support. Compared to the last RFC there are again quite some API
> changes, but also some bug fixes. (The bug fixes I remember are outlined
> in the different patches.)
FWIW, I've applied the first two patches here.
I'd really like you to continue with only that for now, and (try to) get
hostapd/wpa_supplicant changes upstream, perhaps with corresponding
hwsim tests. That way, we can see this working live.
We briefly discussed this at the wireless workshop, and the general
feeling seems to have been that the compat mode is probably not really
worthwhile, but I haven't quite made up my mind on that.
Still, having tests and being able to check it out would help a lot,
also as part of perhaps building a case for compat mode.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH v2] fq: fix fq_tin tx bytes overflow
From: Johannes Berg @ 2019-04-08 20:01 UTC (permalink / raw)
To: Yibo Zhao
Cc: ath10k, linux-wireless, Toke Høiland-Jørgensen,
linux-wireless-owner
In-Reply-To: <fa575f93f3936aa3be1cf6b14f87e511@codeaurora.org>
On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
>
> I understand your concern. Yes, I am using high end AP for throughput
> test. I'd say 1.2 Gbps is not the worst case since we can achieve max
> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is
> the minimum requirement. And I think, with more and more high end
> products(even higher throughput) on the ways to the market, it is highly
> possible that 30s is not a safe time before overflow.
Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
rate.
But still, the only place we expose this is debugfs, so I'm not really
sure we want to spend that.
Note that I'm generally pushing back on statistics right now - I really
want to put some trace points or eBPF hooks in places that people can
use to keep their favourite statistics, instead of trying to cover each
and every use case in the stack itself.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Johannes Berg @ 2019-04-08 20:10 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <14c9d8f7-7cf6-d7e1-a1c0-9f1a10920d4e@wetzel-home.de>
On Sun, 2019-02-24 at 14:04 +0100, Alexander Wetzel wrote:
> Finding a really good sniffer able to also capture A-MPDU frames
> including control frames would be awesome.
I think the AC-9260 you have should be a decent sniffer. The (yet
unreleased) follow-up hardware is even better, but this one is fine.
Just remember to load with amsdu_size set to the appropriate (maximum)
A-MSDU size you want to capture.
> I probably should work on the new AP, but then I always wanted to test
> coreboot and finding out my notebook is now supported is too alluring to
> resist;-)
:-)
> > I think they all should just be made to work in native mode, the
> > firmware basically supports this as you found, there must be some small
> > bugs.
>
> Agree. And with your statements that it already should work and the
> option to get ucode updates I like our chances:-) With some luck it
> could even work and I made some error the first time. I'll give that a
> second look with what I have at hand soon. But after bombing you with
> mails for what feels like most of the weekend I'll postpone that for now:-)
I was looking at the firmware now and ... well, I want to really test
this to understand what's going wrong, because it really *looks* like
even the recent ones should be supported natively, at least as far as
I've looked now.
> As mentioned above I'm currently aiming for two or three Intel AC-9260
> cards for the next development round. It's seems to be the most modern
> card and the price difference between the cards is irrelevant compared
> to both efforts and costs to get the cards working in two or three
> devices. If you thing another card would be better for development I'll
> just use that one instead...
AC-9260 should be fine, as far as Intel is concerned. Also make for good
sniffers, in my experience, we use them all the time for that.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Honor SW_CRYPTO_CONTROL in AP VLAN mode
From: Alexander Wetzel @ 2019-04-08 19:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, mpubbise, Christian.Limpach
In-Reply-To: <ad27a4098892dbd2ebd1954ba6f34ae0fea4600c.camel@sipsolutions.net>
>> Restore @SW_CRYPTO_CONTROL when interface is in AP Vlan mode and don't
>> override driver decision for unicast keys.
>>
>> Fixes commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
>> controlled devices"), which should only have allow SW crypto fallback for
>> group keys.
>
> This confuses me.
>
> The driver doesn't really know about AP_VLAN, so the original commit
> intentionally did this, I think?
>
> There was some kind of other fix related to this though?
Here how I understand the situation:
The intent of db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
controlled devices") was, to allow devices setting SW_CRYPTO_CONTROL to
still support AP_VLAN group keys. It unintentionally allowed more than
it should for that...
Prior to the commit db3bdcb9c3ff installing a group key when in AP_VLAN
mode could not work. Mac80211 was initializing ret to -EOPNOTSUPP and
then jumped to "out_unsupported" when the interface was in AP_VLAN mode
without trying to install the key and giving the driver a chance to
allow SW crypto. Software fallback was then blocked by ret != 1 with
SW_CRYPTO_CONTROL set by the driver.
But any driver setting NL80211_IFTYPE_AP_VLAN already has confirmed to
be fine with SW crypto for group keys, since these CAN only be handled
with SW crypto currently. The net effect was that ath10k - the only
driver in tree setting SW_CRYPTO_CONTROL and also NL80211_IFTYPE_AP -
was not able to send out frames encrypted with the group key at all.
Now the fix for that was commit db3bdcb9c3ff. Unfortunately this went
too far:
We now not only allows fallback to SW crypto for group keys (which the
driver allowed by setting NL80211_IFTYPE_AP_VLAN) but for ANY keys as
long as the interface is in AP_VLAN mode.
So if for some reasons ath10k is not able to install a pairwise key
mac80211 now incorrectly allows the fallback to SW crypto...
This patch here tries to fix that and excludes pairwise keys from the
special AP_VLAN handling again (but keeps it for group keys).
This understanding is based on the result of a inquiry to linux-wireless
(see https://patchwork.kernel.org/patch/10313127/) and a short
out-of-list discussion with Christian Limpach who pointed me to
http://lists.infradead.org/pipermail/ath10k/2018-November/012542.html
as the reason for the original fix in db3bdcb9c3ff.
Alexander
^ permalink raw reply
* Re: [PATCH RFC] staging: wilc1000: give usleep_range a range
From: Adham.Abozaeid @ 2019-04-08 21:01 UTC (permalink / raw)
To: adham.abozaeid; +Cc: linux-wireless, devel, linux-kernel
In-Reply-To: <1554552067-15421-1-git-send-email-hofrat@osadl.org>
Hi Nicholas
On 4/6/19 5:01 AM, Nicholas Mc Guire wrote:
> External E-Mail
>
>
> usleep_range() is called in non-atomic context so there is little point
> in setting min==max the jitter of hrtimer is determined by interruptions
> anyway. usleep_range can only perform the intended coalescence if some
> room for placing the hrtimer is provided. Given the range of milliseconds
> the delay will be anything from 2 to a few anyway - so make it 2-5 ms.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> ---
>
> Problem located with an experimental coccinelle script
> ./drivers/staging/wilc1000/wilc_wlan.c:411:4-16: WARNING: inefficient usleep_range with range 0 (min==max)
> ./drivers/staging/wilc1000/wilc_wlan.c:426:4-16: WARNING: inefficient usleep_range with range 0 (min==max)
>
> Someone that knows the motivation for setting the time to 2 millisecond
> might need to check if the 2 milliseconds where seen as tollerable max or
> min - I'm assuming it was the min so extending.
>
> Patch was compile tested with: x86_64_defconfig + Staging=y,
> WILC1000_SDIO=m, WILC1000_SPI=m, WILC1000=m
>
> Patch is against 5.1-rc3 (localversion-next is -next-20190405)
>
> drivers/staging/wilc1000/wilc_wlan.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
This
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index c238969..42da533 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -408,7 +408,7 @@ void chip_wakeup(struct wilc *wilc)
> wilc->hif_func->hif_write_reg(wilc, 1, reg & ~BIT(1));
>
> do {
> - usleep_range(2 * 1000, 2 * 1000);
> + usleep_range(2 * 1000, 5 * 1000);
> wilc_get_chipid(wilc, true);
> } while (wilc_get_chipid(wilc, true) == 0);
> } while (wilc_get_chipid(wilc, true) == 0);
> @@ -423,7 +423,7 @@ void chip_wakeup(struct wilc *wilc)
> &clk_status_reg);
>
> while ((clk_status_reg & 0x1) == 0) {
> - usleep_range(2 * 1000, 2 * 1000);
> + usleep_range(2 * 1000, 5 * 1000);
>
> wilc->hif_func->hif_read_reg(wilc, 0xf1,
> &clk_status_reg);
^ permalink raw reply
* Re: [PATCH RFC] staging: wilc1000: give usleep_range a range
From: Adham.Abozaeid @ 2019-04-08 21:10 UTC (permalink / raw)
To: hofrat; +Cc: Ajay.Kathat, gregkh, linux-wireless, devel, linux-kernel
In-Reply-To: <1554552067-15421-1-git-send-email-hofrat@osadl.org>
Hi Nicholas
On 4/6/19 5:01 AM, Nicholas Mc Guire wrote:
> External E-Mail
>
>
> Someone that knows the motivation for setting the time to 2 millisecond
> might need to check if the 2 milliseconds where seen as tollerable max or
> min - I'm assuming it was the min so extending.
2 msec is the time the chip takes to wake up from sleep.
Increasing the maximum to 5 msec will impact the throughput since this call is on the transmit path.
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index c238969..42da533 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -408,7 +408,7 @@ void chip_wakeup(struct wilc *wilc)
> wilc->hif_func->hif_write_reg(wilc, 1, reg & ~BIT(1));
>
> do {
> - usleep_range(2 * 1000, 2 * 1000);
> + usleep_range(2 * 1000, 5 * 1000);
> wilc_get_chipid(wilc, true);
> } while (wilc_get_chipid(wilc, true) == 0);
> } while (wilc_get_chipid(wilc, true) == 0);
> @@ -423,7 +423,7 @@ void chip_wakeup(struct wilc *wilc)
> &clk_status_reg);
>
> while ((clk_status_reg & 0x1) == 0) {
> - usleep_range(2 * 1000, 2 * 1000);
> + usleep_range(2 * 1000, 5 * 1000);
>
> wilc->hif_func->hif_read_reg(wilc, 0xf1,
> &clk_status_reg);
Thanks,
Adham
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context.
From: Adham.Abozaeid @ 2019-04-08 21:13 UTC (permalink / raw)
To: penguin-kernel, Ajay.Kathat, gregkh; +Cc: linux-wireless
In-Reply-To: <1554641923-11503-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On 4/7/19 5:58 AM, Tetsuo Handa wrote:
> Since wilc_set_multicast_list() is called with dev->addr_list_lock
> spinlock held, we can't use GFP_KERNEL memory allocation.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Fixes: e624c58cf8eb5116 ("staging: wilc1000: refactor code to avoid use of wilc_set_multicast_list global")
> Cc: Ajay Singh <ajay.kathat@microchip.com>
Reviewed-by: Adham Abozaeid <adham.abozaeid@microchip.com>
Thanks,
Adham
> ---
> drivers/staging/wilc1000/wilc_netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_netdev.c b/drivers/staging/wilc1000/wilc_netdev.c
> index 1787154..ba78c08 100644
> --- a/drivers/staging/wilc1000/wilc_netdev.c
> +++ b/drivers/staging/wilc1000/wilc_netdev.c
> @@ -708,7 +708,7 @@ static void wilc_set_multicast_list(struct net_device *dev)
> return;
> }
>
> - mc_list = kmalloc_array(dev->mc.count, ETH_ALEN, GFP_KERNEL);
> + mc_list = kmalloc_array(dev->mc.count, ETH_ALEN, GFP_ATOMIC);
> if (!mc_list)
> return;
>
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Ondřej Jirman @ 2019-04-08 22:26 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, linux-sunxi, Maxime Ripard, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <CAMty3ZCo53qHW4e+p=toWxLPrUua6XtaZX0YBuPfmDuW1V+e0w@mail.gmail.com>
On Mon, Apr 08, 2019 at 11:41:38AM +0530, Jagan Teki wrote:
> On Sat, Apr 6, 2019 at 5:15 AM <megous@megous.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > According to the phy datasheet, both regulators need to be enabled
> > at the same time, but we can only specify a single phy-supply in
> > the DT.
> >
> > This can be achieved by making one regulator depedning on the
> > other via vin-supply. While it's not a technically correct
> > description of the hardware, it achieves the purpose.
> >
> > All values of RX/TX delay were tested exhaustively and a middle
> > one of the working values was chosen.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 44 +++++++++++++++++++
> > 1 file changed, 44 insertions(+)
>
> This was in ML[1], I thought this change would already merged. I
> remember Chen-Yu applied and revert due to emac node not mainlined at
> that time.
>
> [1] https://patchwork.kernel.org/patch/10558281/
The patch was not merged at the time, and bitrotted a bit. Armbian folks
were applying the bitortted patch out-of-the mainline and were experiencing
NPEs. I fixed the patch, and it is also part of this series. It's patch 5.
o.
^ permalink raw reply
* Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
From: Ondřej Jirman @ 2019-04-08 22:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190408074327.vvubj2sbkvfkwscv@flea>
On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:10AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 91fecab58836..dccad79da90c 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -238,6 +238,15 @@
> > bias-pull-up;
> > };
> >
> > +
>
> Extra line
>
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2", "PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
>
> Is that the only muxing option?
I don't think so. I believe someone can use a 1-bit interface (bus-width = <1>),
and then some data pins will be free. This pinconfig is for 4-bit bus width
setup.
Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
4-bit config the default pinctrl for mmc1. To add to the confusion, on these
SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit) default.
This led to some confusion in the past.
So we can either:
- keep consistency with what is done elsewhere, and make this default, despite
not being the only option,
- or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make it
more explicit, and keep it non-default.
What do you think is better?
thank you and regards,
o.
> If so, then it should be assigned by default to mmc1
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Ondřej Jirman @ 2019-04-08 22:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190408074628.e5ers4gzlqz4coyk@flea>
On Mon, Apr 08, 2019 at 09:46:28AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:03AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 is a H6 based SBC made by Xulong, released in
> > January 2019. It has the following features:
> >
> > - Allwinner H6 quad-core 64-bit ARM Cortex-A53
> > - GPU Mali-T720
> > - 1GB or 2GB LPDDR3 RAM
> > - AXP805 PMIC
> > - AP6256 Wifi/BT 5.0
> > - USB 2.0 host port (A)
> > - USB 2.0 micro usb, OTG
> > - USB 3.0 Host + 4 port USB hub (GL3510)
> > - Gigabit Ethernet (Realtek RTL8211E phy)
> > - HDMI 2.0 port
> > - soldered eMMC (optional)
> > - 3x LED (one is on the bottom)
> > - microphone
> > - audio jack
> > - PCIe
> >
> > Add basic support for the board.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 212 ++++++++++++++++++
> > 2 files changed, 213 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > index e4dce2f6fa3a..285a7cb5135b 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > new file mode 100644
> > index 000000000000..7a2424fcaed7
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2019 Ondřej Jirman <megous@megous.com>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h6.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +
> > +/ {
> > + model = "OrangePi 3";
> > + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
>
> As Clement pointed out, this should be documented in
> Documentation/devicetree/bindings/arm/sunxi.yaml
>
> It's part of sunxi/for-next only at this point, and it will go through
> a different branch than the H6 DTS, so it would be great to have it in
> a separate patch.
>
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + power {
> > + label = "orangepi:red:power";
> > + gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> > + default-state = "on";
> > + };
> > +
> > + status {
> > + label = "orangepi:green:status";
> > + gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> > + };
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the DC jack */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&cpu0 {
> > + cpu-supply = <®_dcdca>;
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci3 {
> > + status = "okay";
> > +};
> > +
> > +&mmc0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + vmmc-supply = <®_cldo1>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci3 {
> > + status = "okay";
> > +};
> > +
> > +&pio {
> > + vcc-pc-supply = <®_bldo2>;
> > + vcc-pd-supply = <®_cldo1>;
> > +};
> > +
> > +&r_i2c {
> > + status = "okay";
> > +
> > + axp805: pmic@36 {
> > + compatible = "x-powers,axp805", "x-powers,axp806";
> > + reg = <0x36>;
> > + interrupt-parent = <&r_intc>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-supply = <®_vcc5v>;
> > + aldoin-supply = <®_vcc5v>;
> > + bldoin-supply = <®_vcc5v>;
> > + cldoin-supply = <®_vcc5v>;
> > +
> > + regulators {
> > + reg_aldo1: aldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-pl-led-ir";
> > + };
> > +
> > + reg_aldo2: aldo2 {
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc33-audio-tv-ephy-mac";
> > + };
> > +
> > + /* ALDO3 is shorted to CLDO1 */
> > + reg_aldo3: aldo3 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-1";
> > + };
> > +
> > + reg_bldo1: bldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-name = "vcc18-dram-bias-pll";
> > + };
> > +
> > + reg_bldo2: bldo2 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-name = "vcc-efuse-pcie-hdmi-pc";
> > + };
> > +
> > + bldo3 {
> > + /* unused */
> > + };
> > +
> > + bldo4 {
> > + /* unused */
> > + };
> > +
> > + reg_cldo1: cldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-2";
> > + };
> > +
> > + cldo2 {
> > + /* unused */
> > + };
> > +
> > + cldo3 {
> > + /* unused */
> > + };
> > +
> > + reg_dcdca: dcdca {
> > + regulator-always-on;
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt = <1160000>;
> > + regulator-name = "vdd-cpu";
> > + };
> > +
> > + reg_dcdcc: dcdcc {
> > + regulator-min-microvolt = <810000>;
> > + regulator-max-microvolt = <1080000>;
> > + regulator-name = "vdd-gpu";
> > + };
> > +
> > + reg_dcdcd: dcdcd {
> > + regulator-always-on;
> > + regulator-min-microvolt = <960000>;
> > + regulator-max-microvolt = <960000>;
> > + regulator-name = "vdd-sys";
> > + };
> > +
> > + reg_dcdce: dcdce {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > + regulator-name = "vcc-dram";
> > + };
> > +
> > + sw {
> > + /* unused */
> > + };
> > + };
> > + };
> > +};
> > +
> > +&uart0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart0_ph_pins>;
> > + status = "okay";
> > +};
> > +
> > +&usb2otg {
> > + dr_mode = "host";
> > + status = "okay";
> > +};
> > +
> > +&usb2phy {
> > + usb0_id_det-gpios = <&pio 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
> > + usb0_vbus-supply = <®_vcc5v>;
> > + usb3_vbus-supply = <®_vcc5v>;
> > + status = "okay";
>
> If we have an ID pin, then why is the OTG controller set to host?
This board has fixed conenction between VBUS and DCIN, so if it is powered
from DCIN and someone will try to connect it to the PC as a peripheral,
they'll get PC's VBUS shorted to the power supply connected to DCIN.
Depending on voltage difference between DCIN and PC's VBUS, you can get
overcurrent condidion and PC's port shutdown.
The board is not entirely foolproof in this regard.
- It can be host powered when connected via microUSB
- It can be self-powered and host an device on microUSB
- It can be self-powered and serve as a peripheral if you modify
a cable (cut VBUS) or the host is expecting this and has some
VBUS detection logic (most hosts will not have this)
I just didn't want to encourage use as a peripheral, because it's not
very foolproof. But I guess, DTS file will not stop anyone anyway.
I'll change it to otg, and maybe leave a small note.
regards,
o.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Ondřej Jirman @ 2019-04-08 23:22 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190408074042.74s5qckukcpore3e@flea>
On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:09AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > According to the phy datasheet, both regulators need to be enabled
> > at the same time, but we can only specify a single phy-supply in
> > the DT.
> >
> > This can be achieved by making one regulator depedning on the
> > other via vin-supply. While it's not a technically correct
> > description of the hardware, it achieves the purpose.
> >
> > All values of RX/TX delay were tested exhaustively and a middle
> > one of the working values was chosen.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 44 +++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 644946749088..5270142527f5 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -15,6 +15,7 @@
> >
> > aliases {
> > serial0 = &uart0;
> > + ethernet0 = &emac;
> > };
> >
> > chosen {
> > @@ -64,6 +65,27 @@
> > regulator-max-microvolt = <5000000>;
> > regulator-always-on;
> > };
> > +
> > + /*
> > + * The board uses 2.5V RGMII signalling. Power sequence
> > + * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > + * power rails at the same time and to wait 100ms.
> > + */
> > + reg_gmac_2v5: gmac-2v5 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "gmac-2v5";
> > + regulator-min-microvolt = <2500000>;
> > + regulator-max-microvolt = <2500000>;
> > + startup-delay-us = <100000>;
> > + enable-active-high;
> > + gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
>
> Is enable-active-high still needed? It's redundant with the
> GPIO_ACTIVE_HIGH flag.
Looking at the code, use/non-use of enable-active-high inhibits
flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
ignore it too and print a warning).
So enable-active-high is still necessary here.
See comment in gpiolib-of.c where this is handled:
/*
* The regulator GPIO handles are specified such that the
* presence or absence of "enable-active-high" solely controls
* the polarity of the GPIO line. Any phandle flags must
* be actively ignored.
*/
regards,
o.
> The indentation is wrong here as well.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH] iw: add command to inject a frame via direct mesh link to mesh peer
From: Pradeep Kumar Chitrapu @ 2019-04-08 23:29 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Pradeep Kumar Chitrapu
Add mpath command to inject ethernet frame over direct mesh link to
given peer, bypassing the mpath table lookup. This helps to send data
frames over unexcersized direct mesh path, which is not selected as
next_hop node. This can be helpful in measuring link metrics.
Format:
$ iw dev <devname> mpath probe <Peer MAC> frame <pattern>
Example:
$ iw wlan0 mpath probe aa:bb:cc:dd:ee:ff frame aa:bb:cc:dd:ee:ff:kk:ll:mm:nn:oo:pp:yy:zz
Frame pattern is supplied as hex pattern of the form aa:bb:cc without
leading 0x. Frame type and length are expected to be of ethernet frame
type.
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
---
mpath.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/mpath.c b/mpath.c
index ff0b7419fd2b..e39c24ba4403 100644
--- a/mpath.c
+++ b/mpath.c
@@ -90,6 +90,45 @@ static int print_mpath_handler(struct nl_msg *msg, void *arg)
return NL_SKIP;
}
+static int handle_mpath_probe(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ unsigned char dst[ETH_ALEN];
+ unsigned char *frame;
+ size_t frame_len;
+
+ if (argc < 3)
+ return 1;
+
+ if (mac_addr_a2n(dst, argv[0])) {
+ fprintf(stderr, "invalid mac address\n");
+ return 2;
+ }
+
+ if (strcmp("frame", argv[1]) != 0)
+ return 1;
+
+ frame = parse_hex(argv[2], &frame_len);
+ if (!frame) {
+ fprintf(stderr, "invalid frame pattern: %p\n", frame);
+ return 2;
+ }
+
+ NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, dst);
+ NLA_PUT(msg, NL80211_ATTR_FRAME, frame_len, frame);
+
+ return 0;
+ nla_put_failure:
+ return -ENOBUFS;
+}
+COMMAND(mpath, probe, "<destination MAC address> frame <frame>",
+ NL80211_CMD_PROBE_MESH_LINK, 0, CIB_NETDEV, handle_mpath_probe,
+ "Inject ethernet frame to given peer overriding the next hop\n"
+ "lookup from mpath table.\n."
+ "Example: iw dev wlan0 mpath probe xx:xx:xx:xx:xx:xx frame 01:xx:xx:00\n");
+
static int handle_mpath_get(struct nl80211_state *state,
struct nl_msg *msg,
int argc, char **argv,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 07/13] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time,
but we can only specify a single phy-supply in the DT.
This can be achieved by making one regulator depedning on the other via
vin-supply. While it's not a technically correct description of the
hardware, it achieves the purpose.
All values of RX/TX delay were tested exhaustively and a middle one of the
working values was chosen.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 5fbc5e410883..523f1d848042 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -44,6 +45,27 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ /*
+ * The board uses 2.5V RGMII signalling. Power sequence to enable
+ * the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2) power rails
+ * at the same time and to wait 100ms.
+ */
+ reg_gmac_2v5: gmac-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "gmac-2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ startup-delay-us = <100000>;
+ enable-active-high;
+ gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+
+ /* The real parent of gmac-2v5 is reg_vcc5v, but we need to
+ * enable two regulators to power the phy. This is one way
+ * to achieve that.
+ */
+ vin-supply = <®_aldo2>; /* GMAC-3V3 */
+ };
};
&cpu0 {
@@ -58,6 +80,28 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ phy-supply = <®_gmac_2v5>;
+ allwinner,rx-delay-ps = <1500>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <40000>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.21.0
^ permalink raw reply related
* [PATCH v2 10/13] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 523f1d848042..f5595653b2c5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -22,6 +22,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -37,6 +48,15 @@
};
};
+ reg_ddc: ddc-io {
+ compatible = "regulator-fixed";
+ regulator-name = "ddc-io";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ };
+
reg_vcc5v: vcc5v {
/* board wide 5V supply directly from the DC jack */
compatible = "regulator-fixed";
@@ -72,6 +92,10 @@
cpu-supply = <®_dcdca>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -91,6 +115,17 @@
status = "okay";
};
+&hdmi {
+ ddc-supply = <®_ddc>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.21.0
^ permalink raw reply related
* [PATCH v2 11/13] brcmfmac: Loading the correct firmware for brcm43456
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
SDIO based brcm43456 is currently misdetected as brcm43455 and the wrong
firmware name is used. Correct the detection and load the correct firmware
file. Chiprev for brcm43456 is "9".
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a06af0cd4a7f..22b73da42822 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -622,6 +622,7 @@ BRCMF_FW_DEF(43430A0, "brcmfmac43430a0-sdio");
/* Note the names are not postfixed with a1 for backward compatibility */
BRCMF_FW_DEF(43430A1, "brcmfmac43430-sdio");
BRCMF_FW_DEF(43455, "brcmfmac43455-sdio");
+BRCMF_FW_DEF(43456, "brcmfmac43456-sdio");
BRCMF_FW_DEF(4354, "brcmfmac4354-sdio");
BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
@@ -642,7 +643,8 @@ static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4339_CHIP_ID, 0xFFFFFFFF, 4339),
BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0x00000001, 43430A0),
BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFFFFFE, 43430A1),
- BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFFC0, 43455),
+ BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0x00000200, 43456),
+ BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFDC0, 43455),
BRCMF_FW_ENTRY(BRCM_CC_4354_CHIP_ID, 0xFFFFFFFF, 4354),
BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0xFFFFFFFF, 4373),
--
2.21.0
^ permalink raw reply related
* [PATCH v2 13/13] [DO NOT MERGE] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
bcm43356 and can be used with the brcmfmac driver. The module is powered by
the two always on regulators (not AXP805).
WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
configured so that it sets up an 1.8V input bias on this port. This is done
by the pio driver by reading the vcc-pg-supply voltage.
You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
configuration that can be found in the Xulongs's repository for H6:
https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
Mainline brcmfmac driver expects the firmware and nvram at the following
paths relative to the firmware directory:
brcm/brcmfmac43456-sdio.bin
brcm/brcmfmac43456-sdio.txt
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index f5595653b2c5..37efcca58a30 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -66,6 +66,26 @@
regulator-always-on;
};
+ reg_vcc33_wifi: vcc33-wifi {
+ /* Always on 3.3V regulator for WiFi and BT */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc33-wifi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_vcc5v>;
+ };
+
+ reg_vcc_wifi_io: vcc-wifi-io {
+ /* Always on 1.8V/300mA regulator for WiFi and BT IO */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi-io";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ vin-supply = <®_vcc33_wifi>;
+ };
+
/*
* The board uses 2.5V RGMII signalling. Power sequence to enable
* the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2) power rails
@@ -86,6 +106,14 @@
*/
vin-supply = <®_aldo2>; /* GMAC-3V3 */
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
+ post-power-on-delay-ms = <200>;
+ };
};
&cpu0 {
@@ -146,6 +174,25 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_vcc33_wifi>;
+ vqmmc-supply = <®_vcc_wifi_io>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcm: sdio-wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <1 0 IRQ_TYPE_LEVEL_LOW>; /* PM0 */
+ interrupt-names = "host-wake";
+ };
+};
+
&ohci0 {
status = "okay";
};
@@ -157,6 +204,7 @@
&pio {
vcc-pc-supply = <®_bldo2>;
vcc-pd-supply = <®_cldo1>;
+ vcc-pg-supply = <®_vcc_wifi_io>;
};
&r_i2c {
--
2.21.0
^ permalink raw reply related
* [PATCH v2 12/13] [DO NOT MERGE] arm64: dts: allwinner: h6: Add MMC1 pins
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
MMC1 is used on some H6 boards we want to support. Typical use is 4-bit
SDIO interface with a WiFi chip. Add pin definitions for this use case.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 91fecab58836..76e20167438a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -238,6 +238,14 @@
bias-pull-up;
};
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
mmc2_pins: mmc2-pins {
pins = "PC1", "PC4", "PC5", "PC6",
"PC7", "PC8", "PC9", "PC10",
--
2.21.0
^ permalink raw reply related
* [PATCH v2 04/13] net: stmmac: sun8i: force select external PHY when no internal one
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Icenowy Zheng, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio, Ondrej Jirman
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.
This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
connected via RMII interface at GPIO bank A).
Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
to address the problem of a wrong default value.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 20c19afb8316..cb7e7f53be7d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -907,6 +907,11 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
* address. No need to mask it again.
*/
reg |= 1 << H3_EPHY_ADDR_SHIFT;
+ } else {
+ /* For SoCs without internal PHY the PHY selection bit should be
+ * set to 0 (external PHY).
+ */
+ reg &= ~H3_EPHY_SELECT;
}
if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
--
2.21.0
^ permalink raw reply related
* [PATCH v2 09/13] dt-bindings: display: sun4i-drm: Add DDC power supply
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some Allwinner SoC using boards need to enable a regulator for the DDC bus
to be usable.
Add binding documentation for it.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 31ab72cba3d4..31474fb92313 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -104,6 +104,7 @@ Required properties:
output, usually to an HDMI connector.
Optional properties:
+ - ddc-supply: the VCC power supply for the DDC bus
- hvcc-supply: the VCC power supply of the controller
DWC HDMI PHY
--
2.21.0
^ permalink raw reply related
* [PATCH v2 08/13] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
transistors, before it can be used. Model this as a power supply for DDC
(via regulator framework).
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 17 ++++++++++++++++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index dc47720c99ba..a1518525fa2f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -146,16 +146,28 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
return PTR_ERR(hdmi->regulator);
}
+ hdmi->ddc_regulator = devm_regulator_get(dev, "ddc");
+ if (IS_ERR(hdmi->ddc_regulator)) {
+ dev_err(dev, "Couldn't get ddc regulator\n");
+ return PTR_ERR(hdmi->ddc_regulator);
+ }
+
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
return ret;
}
+ ret = regulator_enable(hdmi->ddc_regulator);
+ if (ret) {
+ dev_err(dev, "Failed to enable ddc regulator\n");
+ goto err_disable_regulator;
+ }
+
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
- goto err_disable_regulator;
+ goto err_disable_ddc_regulator;
}
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -208,6 +220,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
clk_disable_unprepare(hdmi->clk_tmds);
err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
+err_disable_ddc_regulator:
+ regulator_disable(hdmi->ddc_regulator);
err_disable_regulator:
regulator_disable(hdmi->regulator);
@@ -223,6 +237,7 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, struct device *master,
sun8i_hdmi_phy_remove(hdmi);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
+ regulator_disable(hdmi->ddc_regulator);
regulator_disable(hdmi->regulator);
}
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 720c5aa8adc1..6e93d55560b6 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -188,6 +188,7 @@ struct sun8i_dw_hdmi {
struct sun8i_hdmi_phy *phy;
struct dw_hdmi_plat_data plat_data;
struct regulator *regulator;
+ struct regulator *ddc_regulator;
const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control *rst_ctrl;
};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 05/13] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
H6 has a different I/O voltage bias setting method than A80. Prepare
existing code for using alternative bias voltage setting methods.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 41 +++++++++++++----------
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 5 ++-
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
index da37d594a13d..3aa210079b18 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
@@ -722,7 +722,7 @@ static const struct sunxi_pinctrl_desc sun9i_a80_pinctrl_data = {
.npins = ARRAY_SIZE(sun9i_a80_pins),
.irq_banks = 5,
.disable_strict_mode = true,
- .has_io_bias_cfg = true,
+ .io_bias_cfg_variant = IO_BIAS_CFG_V1,
};
static int sun9i_a80_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 8dd25caea2cf..b8dd58ef33b7 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -610,7 +610,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
u32 val, reg;
int uV;
- if (!pctl->desc->has_io_bias_cfg)
+ if (!pctl->desc->io_bias_cfg_variant)
return 0;
uV = regulator_get_voltage(supply);
@@ -621,23 +621,28 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
if (uV == 0)
return 0;
- /* Configured value must be equal or greater to actual voltage */
- if (uV <= 1800000)
- val = 0x0; /* 1.8V */
- else if (uV <= 2500000)
- val = 0x6; /* 2.5V */
- else if (uV <= 2800000)
- val = 0x9; /* 2.8V */
- else if (uV <= 3000000)
- val = 0xA; /* 3.0V */
- else
- val = 0xD; /* 3.3V */
-
- pin -= pctl->desc->pin_base;
-
- reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
- reg &= ~IO_BIAS_MASK;
- writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+ if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V1) {
+ /*
+ * Configured value must be equal or greater to actual
+ * voltage.
+ */
+ if (uV <= 1800000)
+ val = 0x0; /* 1.8V */
+ else if (uV <= 2500000)
+ val = 0x6; /* 2.5V */
+ else if (uV <= 2800000)
+ val = 0x9; /* 2.8V */
+ else if (uV <= 3000000)
+ val = 0xA; /* 3.0V */
+ else
+ val = 0xD; /* 3.3V */
+
+ pin -= pctl->desc->pin_base;
+
+ reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
+ reg &= ~IO_BIAS_MASK;
+ writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+ }
return 0;
}
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index ee15ab067b5f..642f667e99d2 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -95,6 +95,9 @@
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+/* Bias voltage configuration done via Pn_GRP_CONFIG registers. */
+#define IO_BIAS_CFG_V1 1
+
struct sunxi_desc_function {
unsigned long variant;
const char *name;
@@ -117,7 +120,7 @@ struct sunxi_pinctrl_desc {
const unsigned int *irq_bank_map;
bool irq_read_needs_mux;
bool disable_strict_mode;
- bool has_io_bias_cfg;
+ int io_bias_cfg_variant;
};
struct sunxi_pinctrl_function {
--
2.21.0
^ permalink raw reply related
* [PATCH v2 06/13] pinctrl: sunxi: Support I/O bias voltage setting on H6
From: megous @ 2019-04-09 0:24 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
H6 SoC has a "pio group withstand voltage mode" register (datasheet
description), that needs to be used to select either 1.8V or 3.3V I/O mode,
based on what voltage is powering the respective pin banks and is thus used
for I/O signals.
Add support for configuring this register according to the voltage of the
pin bank regulator (if enabled).
This is similar to the support for I/O bias voltage setting patch for A80
and the same concerns apply. See:
commit 402bfb3c1352 ("Support I/O bias voltage setting on A80")
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 10 ++++++++++
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++++
3 files changed, 15 insertions(+)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
index ef4268cc6227..30b1befa8ed8 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
@@ -591,6 +591,7 @@ static const struct sunxi_pinctrl_desc h6_pinctrl_data = {
.irq_banks = 4,
.irq_bank_map = h6_irq_bank_map,
.irq_read_needs_mux = true,
+ .io_bias_cfg_variant = IO_BIAS_CFG_V2,
};
static int h6_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index b8dd58ef33b7..0ab50a15a716 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -607,6 +607,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
unsigned pin,
struct regulator *supply)
{
+ unsigned short bank = pin / PINS_PER_BANK;
+ unsigned long flags;
u32 val, reg;
int uV;
@@ -642,6 +644,14 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
reg &= ~IO_BIAS_MASK;
writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+ } else if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V2) {
+ val = uV <= 1800000 ? 1 : 0;
+
+ raw_spin_lock_irqsave(&pctl->lock, flags);
+ reg = readl(pctl->membase + PIO_POW_MOD_SEL_REG);
+ reg &= ~(1 << bank);
+ writel(reg | val << bank, pctl->membase + PIO_POW_MOD_SEL_REG);
+ raw_spin_unlock_irqrestore(&pctl->lock, flags);
}
return 0;
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 642f667e99d2..4044a3cb1819 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -95,8 +95,12 @@
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+#define PIO_POW_MOD_SEL_REG 0x340
+
/* Bias voltage configuration done via Pn_GRP_CONFIG registers. */
#define IO_BIAS_CFG_V1 1
+/* Bias voltage set in the PIO_POW_MOD_SEL_REG register. */
+#define IO_BIAS_CFG_V2 2
struct sunxi_desc_function {
unsigned long variant;
--
2.21.0
^ permalink raw reply related
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