* [PATCH 2/2] ath9k: fix a buffer leak in A-MPDU completion
From: Felix Fietkau @ 2010-07-07 17:42 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1278524529-30246-1-git-send-email-nbd@openwrt.org>
When ath_tx_complete_aggr() is called, it's responsible for returning
all buffers in the linked list. This was not done when the STA lookup
failed, leading to a race condition that could leak a few buffers when
a STA just disconnected.
Fix this by immediately returning all buffers to the free list in this case.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
drivers/net/wireless/ath/ath9k/xmit.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 408d1c5..05ec36a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -329,6 +329,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
int isaggr, txfail, txpending, sendbar = 0, needreset = 0, nbad = 0;
bool rc_update = true;
struct ieee80211_tx_rate rates[4];
+ unsigned long flags;
skb = bf->bf_mpdu;
hdr = (struct ieee80211_hdr *)skb->data;
@@ -344,6 +345,10 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
sta = ieee80211_find_sta_by_hw(hw, hdr->addr1);
if (!sta) {
rcu_read_unlock();
+
+ spin_lock_irqsave(&sc->tx.txbuflock, flags);
+ list_splice_tail_init(bf_q, &sc->tx.txbuf);
+ spin_unlock_irqrestore(&sc->tx.txbuflock, flags);
return;
}
--
1.6.4.2
^ permalink raw reply related
* [PATCH 1/2] ath9k: fix a potential buffer leak in the STA teardown path
From: Felix Fietkau @ 2010-07-07 17:42 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
drivers/net/wireless/ath/ath9k/xmit.c | 52 ++++++++++++++++----------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index c3681a1..408d1c5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2430,37 +2430,37 @@ void ath_tx_node_init(struct ath_softc *sc, struct ath_node *an)
void ath_tx_node_cleanup(struct ath_softc *sc, struct ath_node *an)
{
- int i;
- struct ath_atx_ac *ac, *ac_tmp;
- struct ath_atx_tid *tid, *tid_tmp;
+ struct ath_atx_ac *ac;
+ struct ath_atx_tid *tid;
struct ath_txq *txq;
+ int i, tidno;
- for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
- if (ATH_TXQ_SETUP(sc, i)) {
- txq = &sc->tx.txq[i];
+ for (tidno = 0, tid = &an->tid[tidno];
+ tidno < WME_NUM_TID; tidno++, tid++) {
+ i = tid->ac->qnum;
- spin_lock_bh(&txq->axq_lock);
+ if (!ATH_TXQ_SETUP(sc, i))
+ continue;
- list_for_each_entry_safe(ac,
- ac_tmp, &txq->axq_acq, list) {
- tid = list_first_entry(&ac->tid_q,
- struct ath_atx_tid, list);
- if (tid && tid->an != an)
- continue;
- list_del(&ac->list);
- ac->sched = false;
-
- list_for_each_entry_safe(tid,
- tid_tmp, &ac->tid_q, list) {
- list_del(&tid->list);
- tid->sched = false;
- ath_tid_drain(sc, txq, tid);
- tid->state &= ~AGGR_ADDBA_COMPLETE;
- tid->state &= ~AGGR_CLEANUP;
- }
- }
+ txq = &sc->tx.txq[i];
+ ac = tid->ac;
- spin_unlock_bh(&txq->axq_lock);
+ spin_lock_bh(&txq->axq_lock);
+
+ if (tid->sched) {
+ list_del(&tid->list);
+ tid->sched = false;
+ }
+
+ if (ac->sched) {
+ list_del(&ac->list);
+ tid->ac->sched = false;
}
+
+ ath_tid_drain(sc, txq, tid);
+ tid->state &= ~AGGR_ADDBA_COMPLETE;
+ tid->state &= ~AGGR_CLEANUP;
+
+ spin_unlock_bh(&txq->axq_lock);
}
}
--
1.6.4.2
^ permalink raw reply related
* Localversion broken in 2.6.35-rc4, please cherrypick 7263e715
From: Pavel Roskin @ 2010-07-07 15:49 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Hello!
The localversion is not appended for builds outside the source tree.
The fix is in the mainline already, commit 7263e715. I think it should
be cherrypicked for convenience of wireless developers.
Those of us using StGIT can use
stg pick -n localversion-srctree 7263e715
--
Regards,
Pavel Roskin
^ permalink raw reply
* RE: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Nicolas Pitre @ 2010-07-07 15:46 UTC (permalink / raw)
To: Madhusudhan
Cc: 'Roger Quadros',
'Hunter Adrian (Nokia-MS/Helsinki)',
'Ohad Ben-Cohen', linux-wireless, linux-mmc, linux-omap,
linux-arm-kernel, linux,
'Coelho Luciano (Nokia-MS/Helsinki)', akpm,
'San Mehat'
In-Reply-To: <E6AFC02D8D114C129C8140932818E578@am.dhcp.ti.com>
On Wed, 7 Jul 2010, Madhusudhan wrote:
>
>
> > -----Original Message-----
> > From: Nicolas Pitre [mailto:nico@fluxnic.net]
> > Sent: Wednesday, July 07, 2010 9:03 AM
> > To: Roger Quadros
> > Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux-
> > wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
> > omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano
> > (Nokia-MS/Helsinki); akpm@linux-foundation.org; San Mehat
> > Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device
> > support
> >
> > On Wed, 7 Jul 2010, Roger Quadros wrote:
> >
> > > On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
> > > > For eMMC in omap_hsmmc, this is all done via claim_host / release_host
> > > > which call ->enable() / ->disable() methods. omap_hsmmc makes use of
> > > > mmc_power_restore_host() which calls host->bus_ops->power_restore()
> > > > which is not implemented for SDIO, but for MMC and SD it reinitializes
> > > > the card.
> >
> > This is IMHO a really bad design. The power control decision has to
> > come from the top, not from the bottom. And certainly not with a
> > U-turn dependency the omap_hsmmc is using.
> >
> > I regret to say this, but the omap_hsmmc driver is becoming a total
> > mess. The host controller driver has to be a dumb interface serving
> > requests from the hardware used by the upper layer stack, not the place
> > where decisions such as power handling should be made. Think of it like
> > an ethernet driver. No ethernet driver in Linux is telling the IP stack
> > when to shut down.
> >
>
> The point is that MMC/SD core files were patched to provide this kind of a
> support. Any controller driver can use that framework today, right?. As an
> example omap_hsmmc driver was patched and it works fine.
It is not because you are twisting the layers and customizing the core
stack around your own controller that it is good software design.
And the presence of the mmc_power_restore_host() code doesn't mean it is
sane. My point is that no one should ever use that, not even
omap_hsmmc.
Proof: it works so fine that now you must come up with yet another
contorted hack piled on top called "fake^H^H^H^Hsoftware insert/remove
events" to support power handling with SDIO cards.
This MMC_CAP_DISABLE is ridiculous. Why would this have to be a host
capability? This should be a core feature that should be _transparent_
to all hosts with no changes to any of the host drivers. When the core
code knows that the card can be shut down after some idle period, it
should do so with the *existing* API calls, namely the set_ios method.
In the SDIO case it would be a simple matter of mapping the
sdio_release_power() onto that. Instead, some contorted power
management support was sneaked in, which is misdesigned to the point of
breaking proper SDIO support for which more misdesigned features are now
needed to work around the former ones.
Now the OMAP driver is becoming a stack of its own, making decisions
that clearly should be made at a higher level of abstraction. To me
this denotes some laziness from the involved developers who didn't take
the time to design something sensible and generic in the core code, but
rather hacked a quick solution specific to omap_hmmc.c. Of course the
former would require a greater understanding of common code and some
additional effort to make the solution truly generic. Instead, the easy
solution was taken which is to stuff magic behaviors in a host driver
while other people are not paying as much attention to it than core
code.
Needless to say that I'm not impressed at all.
Nicolas
^ permalink raw reply
* RE: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Madhusudhan @ 2010-07-07 14:54 UTC (permalink / raw)
To: 'Nicolas Pitre', 'Roger Quadros'
Cc: 'Hunter Adrian (Nokia-MS/Helsinki)',
'Ohad Ben-Cohen', linux-wireless, linux-mmc, linux-omap,
linux-arm-kernel, linux,
'Coelho Luciano (Nokia-MS/Helsinki)', akpm,
'San Mehat'
In-Reply-To: <alpine.LFD.2.00.1007070954010.6020@xanadu.home>
> -----Original Message-----
> From: Nicolas Pitre [mailto:nico@fluxnic.net]
> Sent: Wednesday, July 07, 2010 9:03 AM
> To: Roger Quadros
> Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux-
> wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano
> (Nokia-MS/Helsinki); akpm@linux-foundation.org; San Mehat
> Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device
> support
>
> On Wed, 7 Jul 2010, Roger Quadros wrote:
>
> > On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
> > > For eMMC in omap_hsmmc, this is all done via claim_host / release_host
> > > which call ->enable() / ->disable() methods. omap_hsmmc makes use of
> > > mmc_power_restore_host() which calls host->bus_ops->power_restore()
> > > which is not implemented for SDIO, but for MMC and SD it reinitializes
> > > the card.
>
> This is IMHO a really bad design. The power control decision has to
> come from the top, not from the bottom. And certainly not with a
> U-turn dependency the omap_hsmmc is using.
>
> I regret to say this, but the omap_hsmmc driver is becoming a total
> mess. The host controller driver has to be a dumb interface serving
> requests from the hardware used by the upper layer stack, not the place
> where decisions such as power handling should be made. Think of it like
> an ethernet driver. No ethernet driver in Linux is telling the IP stack
> when to shut down.
>
The point is that MMC/SD core files were patched to provide this kind of a
support. Any controller driver can use that framework today, right?. As an
example omap_hsmmc driver was patched and it works fine.
Why blame the controller driver for using a support provided by core files?
Regards,
Madhu
> > Shouldn't the power control intelligence (i.e. when to turn power
> ON/OFF) lie
> > with the bus drivers?
>
> Absolutely! And in the SDIO case that should lie with each function
> drivers. Please let's stop this omap_hsmmc madness.
>
>
> Nicolas
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Nicolas Pitre @ 2010-07-07 14:02 UTC (permalink / raw)
To: Roger Quadros
Cc: Hunter Adrian (Nokia-MS/Helsinki), Ohad Ben-Cohen,
linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <4C34347F.8030000@nokia.com>
On Wed, 7 Jul 2010, Roger Quadros wrote:
> On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
> > For eMMC in omap_hsmmc, this is all done via claim_host / release_host
> > which call ->enable() / ->disable() methods. omap_hsmmc makes use of
> > mmc_power_restore_host() which calls host->bus_ops->power_restore()
> > which is not implemented for SDIO, but for MMC and SD it reinitializes
> > the card.
This is IMHO a really bad design. The power control decision has to
come from the top, not from the bottom. And certainly not with a
U-turn dependency the omap_hsmmc is using.
I regret to say this, but the omap_hsmmc driver is becoming a total
mess. The host controller driver has to be a dumb interface serving
requests from the hardware used by the upper layer stack, not the place
where decisions such as power handling should be made. Think of it like
an ethernet driver. No ethernet driver in Linux is telling the IP stack
when to shut down.
> Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie
> with the bus drivers?
Absolutely! And in the SDIO case that should lie with each function
drivers. Please let's stop this omap_hsmmc madness.
Nicolas
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Nicolas Pitre @ 2010-07-07 13:52 UTC (permalink / raw)
To: Roger Quadros
Cc: ext Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <4C343135.1090101@nokia.com>
On Wed, 7 Jul 2010, Roger Quadros wrote:
> On 07/06/2010 08:42 PM, ext Nicolas Pitre wrote:
> > On Tue, 6 Jul 2010, Roger Quadros wrote:
> >
> > > OK, this is how I see it.
> > >
> > > - Treat the non-removable card as non-removable. So no need to do card
> > > detect
> > > emulation.
> > >
> > > - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed
> > > regulator
> > > framework to define this regulator& supply. Even though you mention that
> > > it
> > > is not actually a supply, it fits well in the fixed supply framework.
> > >
> > > - When the host controller is enumerated, the mmc core will power up the
> > > slot,
> > > find the sdio card, and probe the function driver (i.e. wl1271_sdio).
> > >
> > > - if interface is not in use, the function driver must release the sdio
> > > host,
> > > and this should eventually disable the vmmc supply.
> > >
> > > - Whenever the wlan interface must be brought up, wl1271_sdio, can claim
> > > the
> > > sdio host. this will cause the vmmc supply to be enabled, for as long as
> > > the
> > > interface is up.
> > >
> > > Does this address all issues?
> >
> > This is mostly all good, except that claiming/releasing the SDIO host is
> > about access to the bus. It must be claimed right before doing any IO,
> > and released right after that, even when the card is expected to remain
> > powered. This is not the proper place to hook power control.
>
> Agreed, but is it so that SDIO power may be removed between a host_release and
> claim? This appears so from omap_hsmmc host controller.
No, it is not because a host is not claimed that power should be
dropped. The host claim/release is meant to provide exclusive access to
the card that's all.
If the OMAP controller is dropping power to the card upon
host->disable() then it is wrong. AFAICS only the OMAP controller is
playing such games at the moment and I suspect the semantics might not
be all right. Shutting down the _controller_ when it is idle might be a
good thing, but not power to the _card_. Only the function driver might
know when it is fine to lose power.
Nicolas
^ permalink raw reply
* [PATCH] NET: nl80211, fix lock imbalance and netdev referencing
From: Jiri Slaby @ 2010-07-07 13:02 UTC (permalink / raw)
To: johannes
Cc: jirislaby, linux-kernel, John W. Linville, David S. Miller,
Jouni Malinen, Samuel Ortiz, linux-wireless, netdev
Stanse found that nl80211_set_wiphy imporperly handles a lock and netdev
reference and contains unreachable code. It is because there return statement
isntead of assignment to result variable. Fix that.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jouni Malinen <j@w1.fi>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/wireless/nl80211.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 85285b4..fbfac58 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -877,7 +877,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
int idx, mbm = 0;
if (!rdev->ops->set_tx_power) {
- return -EOPNOTSUPP;
+ result = -EOPNOTSUPP;
goto bad_res;
}
--
1.7.1
^ permalink raw reply related
* [PATCH] ath9k_htc: fix memory leak in ath9k_hif_usb_alloc_urbs
From: Rajkumar Manoharan @ 2010-07-07 9:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan
Failure cases within ath9k_hif_usb_alloc_urbs are failed
to release allocated memory.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index ad9134b..61c1bee 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -745,13 +745,17 @@ static int ath9k_hif_usb_alloc_urbs(struct hif_device_usb *hif_dev)
/* RX */
if (ath9k_hif_usb_alloc_rx_urbs(hif_dev) < 0)
- goto err;
+ goto err_rx;
/* Register Read */
if (ath9k_hif_usb_alloc_reg_in_urb(hif_dev) < 0)
- goto err;
+ goto err_reg;
return 0;
+err_reg:
+ ath9k_hif_usb_dealloc_rx_urbs(hif_dev);
+err_rx:
+ ath9k_hif_usb_dealloc_tx_urbs(hif_dev);
err:
return -ENOMEM;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-07 8:02 UTC (permalink / raw)
To: Hunter Adrian (Nokia-MS/Helsinki)
Cc: Nicolas Pitre, Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <4C338927.5020400@nokia.com>
On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
> Nicolas Pitre wrote:
>> On Tue, 6 Jul 2010, Roger Quadros wrote:
>>
>>> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
>>>> Hi Roger,
>>>>
>>>> On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<roger.quadros@nokia.com>
>>>> wrote:
>>>>> My point is that shouldn't this be handled by SDIO core?
>>>> Care to explain what you mean / give a code example ?
>>> If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
>>> the SDIO/MMC core should tackle it, just like it deals with supply for slots
>>> with removable cards.
>>
>> Exact.
>>
>>>> You need card detect events in order to trigger card& sdio function
>>>> initialization and removals.
>>
>> Why would you trigger function initialization and removal? Just to turn
>> off power? That's a bit like pulling off the battery from your laptop
>> when you want to suspend it. There is a better way to go about things.
>>
>>>> Please share any alternative approach you may be thinking on.
>>> OK, this is how I see it.
>>>
>>> - Treat the non-removable card as non-removable. So no need to do card detect
>>> emulation.
>>>
>>> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
>>> framework to define this regulator& supply. Even though you mention that it
>>> is not actually a supply, it fits well in the fixed supply framework.
>>>
>>> - When the host controller is enumerated, the mmc core will power up the slot,
>>> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>>>
>>> - if interface is not in use, the function driver must release the sdio host,
>>> and this should eventually disable the vmmc supply.
>>>
>>> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
>>> sdio host. this will cause the vmmc supply to be enabled, for as long as the
>>> interface is up.
>>>
>>> Does this address all issues?
>>
>> This is mostly all good, except that claiming/releasing the SDIO host is
>> about access to the bus. It must be claimed right before doing any IO,
>> and released right after that, even when the card is expected to remain
>> powered. This is not the proper place to hook power control.
>>
>> Another function pair would be needed instead, which would do almost
>> like the suspend/resume code is already doing. Something like:
>>
>> /*
>> * Indicate to the core SDIO layer that we're not requiring that the
>> * function remain powered. If all functions for the card are in the
>> * same "no power" state, then the host controller can remove power from
>> * the card. Note: the function driver must preserve hardware states if
>> * necessary.
>> */
>> int sdio_release_power(struct sdio_func *func);
>>
>> /*
>> * Indicate to the core SDIO layer that we want power back for this
>> * SDIO function. The power may or may not actually have been removed
>> * since last call to sdio_release_power(), so the function driver must
>> * not assume any preserved state at the hardware level and re-perform
>> * all the necessary hardware config. This function returns 0 when
>> * power is actually restored, or some error code if this cannot be
>> * achieved. One error reason might be that the card is no longer
>> * available on the bus (was removed while powered down and card
>> * detection didn't trigger yet).
>> */
>> int sdio_claim_power(struct sdio_func *func);
>>
>> That's it. When the network interface is down and the hardware is not
>> needed, you call sdio_release_power(). When the request to activate the
>> network interface is received, you call sdio_claim_power() and configure
>> the hardware appropriately. If sdio_claim_power() returns an error,
>> then you just return an error to the network request, and eventually the
>> driver's remove method will be called if this is indeed because the card
>> was removed.
>>
>> In the core SDIO code, this is almost identical to a suspend/resume
>> request, except that the request comes from the function driver instead
>> of the core MMC code.
>
> For eMMC in omap_hsmmc, this is all done via claim_host / release_host
> which call ->enable() / ->disable() methods. omap_hsmmc makes use of
> mmc_power_restore_host() which calls host->bus_ops->power_restore()
> which is not implemented for SDIO, but for MMC and SD it reinitializes
> the card.
Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie
with the bus drivers?
>
> Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and
> implement host->bus_ops->power_restore() for SDIO, then the power will
> go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc
> so that it doesn't wait 9 seconds for the SDIO case
>
is the wl1271 supposed to be used only with omap_hsmmc? We need to have a
solution that works neatly irrespective of which host controller is being used.
regards,
-roger
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-07 7:48 UTC (permalink / raw)
To: ext Nicolas Pitre
Cc: ext Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <alpine.LFD.2.00.1007061316010.6020@xanadu.home>
On 07/06/2010 08:42 PM, ext Nicolas Pitre wrote:
> On Tue, 6 Jul 2010, Roger Quadros wrote:
>
>> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
>>> Hi Roger,
>>>
>>> On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<roger.quadros@nokia.com>
>>> wrote:
>>>> My point is that shouldn't this be handled by SDIO core?
>>>
>>> Care to explain what you mean / give a code example ?
>>
>> If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
>> the SDIO/MMC core should tackle it, just like it deals with supply for slots
>> with removable cards.
>
> Exact.
>
>>> You need card detect events in order to trigger card& sdio function
>>> initialization and removals.
>
> Why would you trigger function initialization and removal? Just to turn
> off power? That's a bit like pulling off the battery from your laptop
> when you want to suspend it. There is a better way to go about things.
>
>>> Please share any alternative approach you may be thinking on.
>>
>> OK, this is how I see it.
>>
>> - Treat the non-removable card as non-removable. So no need to do card detect
>> emulation.
>>
>> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
>> framework to define this regulator& supply. Even though you mention that it
>> is not actually a supply, it fits well in the fixed supply framework.
>>
>> - When the host controller is enumerated, the mmc core will power up the slot,
>> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>>
>> - if interface is not in use, the function driver must release the sdio host,
>> and this should eventually disable the vmmc supply.
>>
>> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
>> sdio host. this will cause the vmmc supply to be enabled, for as long as the
>> interface is up.
>>
>> Does this address all issues?
>
> This is mostly all good, except that claiming/releasing the SDIO host is
> about access to the bus. It must be claimed right before doing any IO,
> and released right after that, even when the card is expected to remain
> powered. This is not the proper place to hook power control.
Agreed, but is it so that SDIO power may be removed between a host_release and
claim? This appears so from omap_hsmmc host controller.
if we have sdio_claim_power() and sdio_release_power() in place then power
control should depend on it.
regards,
-roger
^ permalink raw reply
* [PATCH] mac80211: remove wep dependency
From: John W. Linville @ 2010-07-06 20:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
The current mac80211 code assumes that WEP is always available. If WEP
fails to initialize, ieee80211_register_hw will always fail.
In some cases (e.g. FIPS certification), the cryptography used by WEP is
unavailable. However, in such cases there is no good reason why CCMP
encryption (or even no link level encryption) cannot be used. So, this
patch removes mac80211's assumption that WEP (and TKIP) will always be
available for use.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/cfg.c | 5 +++++
net/mac80211/main.c | 5 +----
net/mac80211/tkip.c | 8 ++++----
net/mac80211/tkip.h | 2 +-
net/mac80211/wep.c | 18 ++++++++++++------
net/mac80211/wep.h | 2 +-
net/mac80211/wpa.c | 5 ++---
7 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e55970b..5b8b446 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -143,6 +143,11 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
return -EINVAL;
}
+ /* reject WEP and TKIP keys if WEP failed to initialize */
+ if ((alg == ALG_WEP || alg == ALG_TKIP) &&
+ IS_ERR(sdata->local->wep_tx_tfm))
+ return -EINVAL;
+
key = ieee80211_key_alloc(alg, key_idx, params->key_len, params->key,
params->seq_len, params->seq);
if (!key)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index edf7aff..0e95c75 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -637,11 +637,9 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
goto fail_sta_info;
result = ieee80211_wep_init(local);
- if (result < 0) {
+ if (result < 0)
printk(KERN_DEBUG "%s: Failed to initialize wep: %d\n",
wiphy_name(local->hw.wiphy), result);
- goto fail_wep;
- }
rtnl_lock();
@@ -694,7 +692,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
fail_rate:
rtnl_unlock();
ieee80211_wep_free(local);
- fail_wep:
sta_info_stop(local);
fail_sta_info:
destroy_workqueue(local->workqueue);
diff --git a/net/mac80211/tkip.c b/net/mac80211/tkip.c
index 7ef491e..e840c9c 100644
--- a/net/mac80211/tkip.c
+++ b/net/mac80211/tkip.c
@@ -202,9 +202,9 @@ EXPORT_SYMBOL(ieee80211_get_tkip_key);
* @payload_len is the length of payload (_not_ including IV/ICV length).
* @ta is the transmitter addresses.
*/
-void ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
- struct ieee80211_key *key,
- u8 *pos, size_t payload_len, u8 *ta)
+int ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
+ struct ieee80211_key *key,
+ u8 *pos, size_t payload_len, u8 *ta)
{
u8 rc4key[16];
struct tkip_ctx *ctx = &key->u.tkip.tx;
@@ -216,7 +216,7 @@ void ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
tkip_mixing_phase2(tk, ctx, ctx->iv16, rc4key);
- ieee80211_wep_encrypt_data(tfm, rc4key, 16, pos, payload_len);
+ return ieee80211_wep_encrypt_data(tfm, rc4key, 16, pos, payload_len);
}
/* Decrypt packet payload with TKIP using @key. @pos is a pointer to the
diff --git a/net/mac80211/tkip.h b/net/mac80211/tkip.h
index d471438..7e83dee 100644
--- a/net/mac80211/tkip.h
+++ b/net/mac80211/tkip.h
@@ -15,7 +15,7 @@
u8 *ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key, u16 iv16);
-void ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
+int ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
struct ieee80211_key *key,
u8 *pos, size_t payload_len, u8 *ta);
enum {
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index 5f3a411..54263db 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -122,19 +122,24 @@ static void ieee80211_wep_remove_iv(struct ieee80211_local *local,
/* Perform WEP encryption using given key. data buffer must have tailroom
* for 4-byte ICV. data_len must not include this ICV. Note: this function
* does _not_ add IV. data = RC4(data | CRC32(data)) */
-void ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
- size_t klen, u8 *data, size_t data_len)
+int ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
+ size_t klen, u8 *data, size_t data_len)
{
struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist sg;
__le32 icv;
+ if (IS_ERR(tfm))
+ return -1;
+
icv = cpu_to_le32(~crc32_le(~0, data, data_len));
put_unaligned(icv, (__le32 *)(data + data_len));
crypto_blkcipher_setkey(tfm, rc4key, klen);
sg_init_one(&sg, data, data_len + WEP_ICV_LEN);
crypto_blkcipher_encrypt(&desc, &sg, &sg, sg.length);
+
+ return 0;
}
@@ -168,10 +173,8 @@ int ieee80211_wep_encrypt(struct ieee80211_local *local,
/* Add room for ICV */
skb_put(skb, WEP_ICV_LEN);
- ieee80211_wep_encrypt_data(local->wep_tx_tfm, rc4key, keylen + 3,
- iv + WEP_IV_LEN, len);
-
- return 0;
+ return ieee80211_wep_encrypt_data(local->wep_tx_tfm, rc4key, keylen + 3,
+ iv + WEP_IV_LEN, len);
}
@@ -185,6 +188,9 @@ int ieee80211_wep_decrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
struct scatterlist sg;
__le32 crc;
+ if (IS_ERR(tfm))
+ return -1;
+
crypto_blkcipher_setkey(tfm, rc4key, klen);
sg_init_one(&sg, data, data_len + WEP_ICV_LEN);
crypto_blkcipher_decrypt(&desc, &sg, &sg, sg.length);
diff --git a/net/mac80211/wep.h b/net/mac80211/wep.h
index fe29d7e..58654ee 100644
--- a/net/mac80211/wep.h
+++ b/net/mac80211/wep.h
@@ -18,7 +18,7 @@
int ieee80211_wep_init(struct ieee80211_local *local);
void ieee80211_wep_free(struct ieee80211_local *local);
-void ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
+int ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
size_t klen, u8 *data, size_t data_len);
int ieee80211_wep_encrypt(struct ieee80211_local *local,
struct sk_buff *skb,
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index a14e677..8d59d27 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -183,9 +183,8 @@ static int tkip_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
skb_put(skb, TKIP_ICV_LEN);
hdr = (struct ieee80211_hdr *) skb->data;
- ieee80211_tkip_encrypt_data(tx->local->wep_tx_tfm,
- key, pos, len, hdr->addr2);
- return 0;
+ return ieee80211_tkip_encrypt_data(tx->local->wep_tx_tfm,
+ key, pos, len, hdr->addr2);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] compat-wireless: update 07-change-default-rate-alg.patch
From: Pavel Roskin @ 2010-07-06 20:24 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
---
patches/07-change-default-rate-alg.patch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/patches/07-change-default-rate-alg.patch b/patches/07-change-default-rate-alg.patch
index f0ccbce..858e1bc 100644
--- a/patches/07-change-default-rate-alg.patch
+++ b/patches/07-change-default-rate-alg.patch
@@ -29,6 +29,6 @@ at compilation time.
- ops = ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+ if (!ops && strlen(CONFIG_COMPAT_MAC80211_RC_DEFAULT))
+ ops = ieee80211_try_rate_control_ops_get(CONFIG_COMPAT_MAC80211_RC_DEFAULT);
- kparam_unblock_sysfs_write(ieee80211_default_rc_algo);
return ops;
+ }
^ permalink raw reply related
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Adrian Hunter @ 2010-07-06 19:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Quadros Roger (Nokia-MS/Helsinki), Ohad Ben-Cohen,
linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <alpine.LFD.2.00.1007061316010.6020@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 6 Jul 2010, Roger Quadros wrote:
>
>> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
>>> Hi Roger,
>>>
>>> On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<roger.quadros@nokia.com>
>>> wrote:
>>>> My point is that shouldn't this be handled by SDIO core?
>>> Care to explain what you mean / give a code example ?
>> If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
>> the SDIO/MMC core should tackle it, just like it deals with supply for slots
>> with removable cards.
>
> Exact.
>
>>> You need card detect events in order to trigger card& sdio function
>>> initialization and removals.
>
> Why would you trigger function initialization and removal? Just to turn
> off power? That's a bit like pulling off the battery from your laptop
> when you want to suspend it. There is a better way to go about things.
>
>>> Please share any alternative approach you may be thinking on.
>> OK, this is how I see it.
>>
>> - Treat the non-removable card as non-removable. So no need to do card detect
>> emulation.
>>
>> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
>> framework to define this regulator & supply. Even though you mention that it
>> is not actually a supply, it fits well in the fixed supply framework.
>>
>> - When the host controller is enumerated, the mmc core will power up the slot,
>> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>>
>> - if interface is not in use, the function driver must release the sdio host,
>> and this should eventually disable the vmmc supply.
>>
>> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
>> sdio host. this will cause the vmmc supply to be enabled, for as long as the
>> interface is up.
>>
>> Does this address all issues?
>
> This is mostly all good, except that claiming/releasing the SDIO host is
> about access to the bus. It must be claimed right before doing any IO,
> and released right after that, even when the card is expected to remain
> powered. This is not the proper place to hook power control.
>
> Another function pair would be needed instead, which would do almost
> like the suspend/resume code is already doing. Something like:
>
> /*
> * Indicate to the core SDIO layer that we're not requiring that the
> * function remain powered. If all functions for the card are in the
> * same "no power" state, then the host controller can remove power from
> * the card. Note: the function driver must preserve hardware states if
> * necessary.
> */
> int sdio_release_power(struct sdio_func *func);
>
> /*
> * Indicate to the core SDIO layer that we want power back for this
> * SDIO function. The power may or may not actually have been removed
> * since last call to sdio_release_power(), so the function driver must
> * not assume any preserved state at the hardware level and re-perform
> * all the necessary hardware config. This function returns 0 when
> * power is actually restored, or some error code if this cannot be
> * achieved. One error reason might be that the card is no longer
> * available on the bus (was removed while powered down and card
> * detection didn't trigger yet).
> */
> int sdio_claim_power(struct sdio_func *func);
>
> That's it. When the network interface is down and the hardware is not
> needed, you call sdio_release_power(). When the request to activate the
> network interface is received, you call sdio_claim_power() and configure
> the hardware appropriately. If sdio_claim_power() returns an error,
> then you just return an error to the network request, and eventually the
> driver's remove method will be called if this is indeed because the card
> was removed.
>
> In the core SDIO code, this is almost identical to a suspend/resume
> request, except that the request comes from the function driver instead
> of the core MMC code.
For eMMC in omap_hsmmc, this is all done via claim_host / release_host
which call ->enable() / ->disable() methods. omap_hsmmc makes use of
mmc_power_restore_host() which calls host->bus_ops->power_restore()
which is not implemented for SDIO, but for MMC and SD it reinitializes
the card.
Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and
implement host->bus_ops->power_restore() for SDIO, then the power will
go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc
so that it doesn't wait 9 seconds for the SDIO case
>
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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
* Compat-wireless release for 2010-07-06 is baked
From: Compat-wireless cronjob account @ 2010-07-06 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
39a2e97..5aff268 history -> origin/history
+ 2880928...03c604f master -> origin/master (forced update)
123f94f..815c416 stable -> origin/stable
* [new tag] next-20100706 -> next-20100706
* [new tag] v2.6.35-rc4 -> v2.6.35-rc4
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
494471 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Nicolas Pitre @ 2010-07-06 17:42 UTC (permalink / raw)
To: Roger Quadros
Cc: ext Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <4C333E0D.2070601@nokia.com>
On Tue, 6 Jul 2010, Roger Quadros wrote:
> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
> > Hi Roger,
> >
> > On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<roger.quadros@nokia.com>
> > wrote:
> > > My point is that shouldn't this be handled by SDIO core?
> >
> > Care to explain what you mean / give a code example ?
>
> If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
> the SDIO/MMC core should tackle it, just like it deals with supply for slots
> with removable cards.
Exact.
> > You need card detect events in order to trigger card& sdio function
> > initialization and removals.
Why would you trigger function initialization and removal? Just to turn
off power? That's a bit like pulling off the battery from your laptop
when you want to suspend it. There is a better way to go about things.
> > Please share any alternative approach you may be thinking on.
>
> OK, this is how I see it.
>
> - Treat the non-removable card as non-removable. So no need to do card detect
> emulation.
>
> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
> framework to define this regulator & supply. Even though you mention that it
> is not actually a supply, it fits well in the fixed supply framework.
>
> - When the host controller is enumerated, the mmc core will power up the slot,
> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>
> - if interface is not in use, the function driver must release the sdio host,
> and this should eventually disable the vmmc supply.
>
> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
> sdio host. this will cause the vmmc supply to be enabled, for as long as the
> interface is up.
>
> Does this address all issues?
This is mostly all good, except that claiming/releasing the SDIO host is
about access to the bus. It must be claimed right before doing any IO,
and released right after that, even when the card is expected to remain
powered. This is not the proper place to hook power control.
Another function pair would be needed instead, which would do almost
like the suspend/resume code is already doing. Something like:
/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same "no power" state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);
/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);
That's it. When the network interface is down and the hardware is not
needed, you call sdio_release_power(). When the request to activate the
network interface is received, you call sdio_claim_power() and configure
the hardware appropriately. If sdio_claim_power() returns an error,
then you just return an error to the network request, and eventually the
driver's remove method will be called if this is indeed because the card
was removed.
In the core SDIO code, this is almost identical to a suspend/resume
request, except that the request comes from the function driver instead
of the core MMC code.
Nicolas
^ permalink raw reply
* RE: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Nicolas Pitre @ 2010-07-06 17:00 UTC (permalink / raw)
To: Madhusudhan
Cc: 'Ohad Ben-Cohen', linux-wireless, linux-mmc, linux-omap,
linux-arm-kernel, linux, 'Luciano Coelho',
'Andrew Morton', 'San Mehat',
'Pandita, Vikram'
In-Reply-To: <822D79B5C25543B1A6F148B39E061459@am.dhcp.ti.com>
On Tue, 6 Jul 2010, Madhusudhan wrote:
>
>
> > -----Original Message-----
> > From: Ohad Ben-Cohen [mailto:ohad@wizery.com]
> > Sent: Tuesday, July 06, 2010 6:48 AM
> > To: Nicolas Pitre
> > Cc: linux-wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
> > omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho;
> > Andrew Morton; San Mehat; Pandita, Vikram
> > Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
> >
> > On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > > Note: the wl1271 device does support standard card detection, but
> > > AFAIK there's a limitation to use that with the specific omap
> > > controller the device is hardwired to. I will try to get more info
> > > about that, but probably Madhu can comment on that better.
> >
> >
> > Some correction and additional info:
> >
> > The wl1271 device has an issue which makes the standard card detect
> > mechanism irrelevant: it is always up, even if the power enable gpio
> > input of the device is down (the power enable input does not supply
> > the power to the chip, it's just logical digital high/low input upon
> > which the device reacts). That's why we must use software control for
> > emulating card detect with that device.
> >
> > In addition, as far as I could find out, the card detect mechanism on
> > the ZOOM is implemented by mechanical means, and thus is not relevant
> > for hardwired embedded SDIO devices (I'm not even sure card detect is
> > supported for the 3rd mmc controller).
>
> The card detect is supported through T2 GPIO interrupts only for MMC1 and
> MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is
> hardwired.
Many existing implementations simply have no (or a broken) card
detection signal. In that case, either the host controller passes the
MMC_CAP_NEEDS_POLL flag to the core so that the bus is probed on a
regular interval for card presence. Or, like in this case where the
"card" is always hardwired on the board, you simply rely on the initial
probe which is always performed at least once when the host controller
driver is registered.
Now the issue of having the card powered off when not in use is a valid
one, whether or not it is actually hardwired on the board or
hot insertable/removable. This fake insertion thing is not the best way
to go about it.
It would be way more useful, generic, and less hackish to simply improve
the generic code so to power down the card when it is 1) not claimed by
any function driver, and 2) provide an API to let a function driver
signify to the core and host controller that it is not interested by the
hardware at the moment (if the network interface is not up for example)
and therefore the core could again power down the card. This would work
in all cases with no need for exceptions for so called "enbedded
controllers".
Nicolas
^ permalink raw reply
* [PATCH] ath9k: remove unneeded calculation of minimal calibration power
From: Pavel Roskin @ 2010-07-06 16:51 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Prarit Bhargava
Remove tMinCalPower from ath9k_hw_set_def_power_cal_table(), as it's
never used. Remove corresponding arguments of the functions calculating
that value.
Original patch by Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 7 ++-----
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 ----
drivers/net/wireless/ath/ath9k/eeprom_def.c | 7 ++-----
3 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index e25a2ab..00cc3db 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -222,7 +222,7 @@ static void ath9k_hw_get_4k_gain_boundaries_pdadcs(struct ath_hw *ah,
struct ath9k_channel *chan,
struct cal_data_per_freq_4k *pRawDataSet,
u8 *bChans, u16 availPiers,
- u16 tPdGainOverlap, int16_t *pMinCalPower,
+ u16 tPdGainOverlap,
u16 *pPdGainBoundaries, u8 *pPDADCValues,
u16 numXpdGains)
{
@@ -308,8 +308,6 @@ static void ath9k_hw_get_4k_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
-
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -399,7 +397,6 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw *ah,
static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_EEP4K_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
- int16_t tMinCalPower;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR5416_EEP4K_NUM_PD_GAINS] = { 0, 0 };
u32 reg32, regOffset, regChainOffset;
@@ -452,7 +449,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw *ah,
ath9k_hw_get_4k_gain_boundaries_pdadcs(ah, chan,
pRawDataset, pCalBChans,
numPiers, pdGainOverlap_t2,
- &tMinCalPower, gainBoundaries,
+ gainBoundaries,
pdadcValues, numXpdGain);
ENABLE_REGWRITE_BUFFER(ah);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index 39a4105..cb388d2 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -223,7 +223,6 @@ static void ath9k_hw_get_ar9287_gain_boundaries_pdadcs(struct ath_hw *ah,
struct cal_data_per_freq_ar9287 *pRawDataSet,
u8 *bChans, u16 availPiers,
u16 tPdGainOverlap,
- int16_t *pMinCalPower,
u16 *pPdGainBoundaries,
u8 *pPDADCValues,
u16 numXpdGains)
@@ -303,7 +302,6 @@ static void ath9k_hw_get_ar9287_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -458,7 +456,6 @@ static void ath9k_hw_set_ar9287_power_cal_table(struct ath_hw *ah,
u8 pdadcValues[AR9287_NUM_PDADC_VALUES];
u16 gainBoundaries[AR9287_PD_GAINS_IN_MASK];
u16 numPiers = 0, i, j;
- int16_t tMinCalPower;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR9287_NUM_PD_GAINS] = {0, 0, 0, 0};
u32 reg32, regOffset, regChainOffset, regval;
@@ -530,7 +527,6 @@ static void ath9k_hw_set_ar9287_power_cal_table(struct ath_hw *ah,
pRawDataset,
pCalBChans, numPiers,
pdGainOverlap_t2,
- &tMinCalPower,
gainBoundaries,
pdadcValues,
numXpdGain);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 77b1433..57d86d4 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -593,7 +593,7 @@ static void ath9k_hw_get_def_gain_boundaries_pdadcs(struct ath_hw *ah,
struct ath9k_channel *chan,
struct cal_data_per_freq *pRawDataSet,
u8 *bChans, u16 availPiers,
- u16 tPdGainOverlap, int16_t *pMinCalPower,
+ u16 tPdGainOverlap,
u16 *pPdGainBoundaries, u8 *pPDADCValues,
u16 numXpdGains)
{
@@ -675,8 +675,6 @@ static void ath9k_hw_get_def_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
-
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -838,7 +836,7 @@ static void ath9k_hw_set_def_power_cal_table(struct ath_hw *ah,
static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
- int16_t tMinCalPower, diff = 0;
+ int16_t diff = 0;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR5416_NUM_PD_GAINS] = { 0, 0, 0, 0 };
u32 reg32, regOffset, regChainOffset;
@@ -923,7 +921,6 @@ static void ath9k_hw_set_def_power_cal_table(struct ath_hw *ah,
chan, pRawDataset,
pCalBChans, numPiers,
pdGainOverlap_t2,
- &tMinCalPower,
gainBoundaries,
pdadcValues,
numXpdGain);
^ permalink raw reply related
* Re: ath: Fix uninitialized variable warnings [v2]
From: Pavel Roskin @ 2010-07-06 16:35 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-wireless, ath9k-devel, linville
In-Reply-To: <4C331BB9.5010005@redhat.com>
On Tue, 2010-07-06 at 08:04 -0400, Prarit Bhargava wrote:
> New patch with updated description.
Your patch doesn't apply anymore.
> Fix 'make CONFIG_DEBUG_SECTION_MISMATCH=y' warning:
I tried to reproduce the warning, but could not. I guess my gcc is old
(4.4.1) or you used more options that enable warnings.
> Pavel pointed out that tMinCalPower or pMinCalPower isn't used anywhere, so
> the simplest way to fix these warnings is to get rid of the code.
That alone is the best reason. I'll resend the updated patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen @ 2010-07-06 15:54 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <AANLkTilfjBIbylUDKlTGiEC_U6pJnkC6HoENOzK2eFFq@mail.gmail.com>
On Tue, Jul 6, 2010 at 6:49 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> Hm, do we really need a Kconfig option just for a single pointer? It
> only saves sizeof(void *) bytes per host, but adds rather confusing
> config option for users and some ifdef complexity.
No strong feelings about it, I can remove that if preferred.
>
^ permalink raw reply
* Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Grazvydas Ignotas @ 2010-07-06 15:49 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-5-git-send-email-ohad@wizery.com>
On Tue, Jul 6, 2010 at 3:37 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Add support to set/get mmc_host private embedded
> data.
>
> This is needed to allow software to dynamically
> create (and remove) SDIO functions which represents
> embedded SDIO devices.
>
> Typically, it will be used to set the context of
> a driver that is creating a new SDIO function
> (and would then expect to be able to get that context
> back upon creation of the new sdio func).
>
> Signed-off-by: Ohad Ben-Cohen <ohadb@ti.com>
> ---
> drivers/mmc/core/Kconfig | 8 ++++++++
> include/linux/mmc/host.h | 16 ++++++++++++++++
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index bb22ffd..ab27eb3 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
>
> This option sets a default which can be overridden by the
> module parameter "removable=0" or "removable=1".
> +
> +config MMC_EMBEDDED_SDIO
> + boolean "MMC embedded SDIO device support"
> + help
> + If you say Y here, support will be added for embedded SDIO
> + devices (e.g. hardwired embedded WLAN SDIO devices).
> + Such devices require software support for emulating
> + card detect events.
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index f65913c..9a48486 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -209,6 +209,10 @@ struct mmc_host {
> struct led_trigger *led; /* activity led */
> #endif
>
> +#ifdef CONFIG_MMC_EMBEDDED_SDIO
> + void *embedded_data;
> +#endif
> +
Hm, do we really need a Kconfig option just for a single pointer? It
only saves sizeof(void *) bytes per host, but adds rather confusing
config option for users and some ifdef complexity.
^ permalink raw reply
* RE: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Madhusudhan @ 2010-07-06 15:34 UTC (permalink / raw)
To: 'Ohad Ben-Cohen', 'Nicolas Pitre'
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
'Luciano Coelho', 'Andrew Morton',
'San Mehat', 'Pandita, Vikram'
In-Reply-To: <AANLkTinE5LygUWJsJSEE2miZF1GK58LTr8zErkuu_7yM@mail.gmail.com>
> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad@wizery.com]
> Sent: Tuesday, July 06, 2010 6:48 AM
> To: Nicolas Pitre
> Cc: linux-wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho;
> Andrew Morton; San Mehat; Pandita, Vikram
> Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
>
> On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > Note: the wl1271 device does support standard card detection, but
> > AFAIK there's a limitation to use that with the specific omap
> > controller the device is hardwired to. I will try to get more info
> > about that, but probably Madhu can comment on that better.
>
>
> Some correction and additional info:
>
> The wl1271 device has an issue which makes the standard card detect
> mechanism irrelevant: it is always up, even if the power enable gpio
> input of the device is down (the power enable input does not supply
> the power to the chip, it's just logical digital high/low input upon
> which the device reacts). That's why we must use software control for
> emulating card detect with that device.
>
> In addition, as far as I could find out, the card detect mechanism on
> the ZOOM is implemented by mechanical means, and thus is not relevant
> for hardwired embedded SDIO devices (I'm not even sure card detect is
> supported for the 3rd mmc controller).
The card detect is supported through T2 GPIO interrupts only for MMC1 and
MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is
hardwired.
Regards,
Madhu
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-06 14:30 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <AANLkTin5W52fPzWToRrAzm56SLZI-taSuI16rCEhLWqH@mail.gmail.com>
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
> Hi Roger,
>
> On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<roger.quadros@nokia.com> wrote:
>> My point is that shouldn't this be handled by SDIO core?
>
> Care to explain what you mean / give a code example ?
If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
the SDIO/MMC core should tackle it, just like it deals with supply for slots
with removable cards.
see mmc_regulator_set_ocr()
mmc_power_up()
mmc_set_ios()
in drivers/mmc/core/core.c
and omap_hsmmc_set_ios()
in drivers/mmc/host/omap_hsmmc.c
>
>> If there are no users for the SDIO function and the card, doesn't the SDIO
>> core power down the slot and take care of re-initialization when it is
>> powered up?
>
> You need card detect events in order to trigger card& sdio function
> initialization and removals.
>
> Please share any alternative approach you may be thinking on.
OK, this is how I see it.
- Treat the non-removable card as non-removable. So no need to do card detect
emulation.
- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator & supply. Even though you mention that it is
not actually a supply, it fits well in the fixed supply framework.
- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).
- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.
- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.
Does this address all issues?
regards,
-roger
^ permalink raw reply
* Re: [PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen @ 2010-07-06 13:47 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <4C33228D.8000908@nokia.com>
Hi Roger,
On Tue, Jul 6, 2010 at 3:33 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
>> +static void omap_zoom_wlan_power(bool enable)
>> +{
>> + int val = enable ? 1 : 0;
>> +
>> + pr_info("%s: set power %d\n", __func__, val);
>> +
>> + gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
>> +}
>
> Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply
> or equivalent to supply voltage to the SDIO card?
Not really, this gpio does not supply power to the chip. It's only a
digital indication that instructs the chip to go into on or off mode.
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen @ 2010-07-06 13:44 UTC (permalink / raw)
To: Roger Quadros
Cc: Nicolas Pitre, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), Andrew Morton, San Mehat,
Pandita, Vikram
In-Reply-To: <4C3323EA.902@nokia.com>
On Tue, Jul 6, 2010 at 3:39 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> Just to clarify, is the wl1271 device always powered on the board?
Yes.
> And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this
> supply internally?
Yes. It's a digital input that the chip does not draw current from
(well, only a very minimal one).
> and what do these do ?
>
> set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
>
> clear_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
This is an internal driver bit that maintains the power state of the chip.
AFAICT, it does not "do" anything. The only place I can see it is
being used is in a debugfs entry.
^ 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