headers
Miguel Botón | 1 Jan 01:16
Picon

[PATCH 1/2] ssb: add 'ssb_pcihost_set_power_state' function

This patch adds the 'ssb_pcihost_set_power_state' function.

This function allows us to set the power state of a PCI device
(for example b44 ethernet device). 

Signed-off-by: Miguel Botón <mboton <at> gmail.com>

diff --git a/include/linux/ssb/ssb.h b/include/linux/ssb/ssb.h
index a21ab29..aa70fd0 100644
--- a/include/linux/ssb/ssb.h
+++ b/include/linux/ssb/ssb.h
@@ -349,6 +349,13 @@ static inline void ssb_pcihost_unregister(struct pci_driver *driver)
 {
 	pci_unregister_driver(driver);
 }
+
+static inline
+void ssb_pcihost_set_power_state(struct ssb_device *sdev, pci_power_t state)
+{
+	if (sdev->bus->bustype == SSB_BUSTYPE_PCI)
+		pci_set_power_state(sdev->bus->host_pci, state);
+}
 #endif /* CONFIG_SSB_PCIHOST */

--

-- 
	Miguel Botón
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miguel Botón | 1 Jan 01:17
Picon

[PATCH 2/2] b44: power down PHY when interface down

This is just this patch (http://lkml.org/lkml/2007/7/1/51) but adapted
to the 'b44' ssb driver.

Signed-off-by: Miguel Botón <mboton <at> gmail.com>

diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 49e9172..ea2a2b5 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -128,6 +128,8 @@ static void b44_init_rings(struct b44 *);
 #define B44_FULL_RESET		1
 #define B44_FULL_RESET_SKIP_PHY	2
 #define B44_PARTIAL_RESET	3
+#define B44_CHIP_RESET_FULL	4
+#define B44_CHIP_RESET_PARTIAL	5

 static void b44_init_hw(struct b44 *, int);

@@ -1259,7 +1261,7 @@ static void b44_clear_stats(struct b44 *bp)
 }

 /* bp->lock is held. */
-static void b44_chip_reset(struct b44 *bp)
+static void b44_chip_reset(struct b44 *bp, int reset_kind)
 {
 	struct ssb_device *sdev = bp->sdev;

@@ -1281,6 +1283,13 @@ static void b44_chip_reset(struct b44 *bp)
 	ssb_device_enable(bp->sdev, 0);
 	b44_clear_stats(bp);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Buesch | 1 Jan 01:50
Picon
Favicon

Re: [PATCH 1/2] ssb: add 'ssb_pcihost_set_power_state' function

On Tuesday 01 January 2008 01:16:46 Miguel Botón wrote:
> This patch adds the 'ssb_pcihost_set_power_state' function.
> 
> This function allows us to set the power state of a PCI device
> (for example b44 ethernet device). 
> 
> Signed-off-by: Miguel Botón <mboton@...>

Acked-by: Michael Buesch <mb@...>

> 
> diff --git a/include/linux/ssb/ssb.h b/include/linux/ssb/ssb.h
> index a21ab29..aa70fd0 100644
> --- a/include/linux/ssb/ssb.h
> +++ b/include/linux/ssb/ssb.h
> @@ -349,6 +349,13 @@ static inline void ssb_pcihost_unregister(struct pci_driver *driver)
>  {
>  	pci_unregister_driver(driver);
>  }
> +
> +static inline
> +void ssb_pcihost_set_power_state(struct ssb_device *sdev, pci_power_t state)
> +{
> +	if (sdev->bus->bustype == SSB_BUSTYPE_PCI)
> +		pci_set_power_state(sdev->bus->host_pci, state);
> +}
>  #endif /* CONFIG_SSB_PCIHOST */
>  
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Clayton | 2 Jan 07:32

Re: Warning emited by 2.6.24-rc6-git5

On Monday 31 December 2007, Ivo Van Doorn wrote:
> On Dec 31, 2007 8:27 AM, Kalle Valo <kalle.valo@...> wrote:
> > Ivo van Doorn <ivdoorn@...> writes:
> > > +             /*
> > > +              * Move entire frame 2 bytes to the front.
> > > +              */
> > > +             skb_push(skb, 2);
> > > +             memmove(skb->data, skb->data + 2, skb->len - 2);
> >
> > No skb_trim()? Shoudn't there be skb_trim(skb, 2) after memmove()?
>
> Good point, I completely forgot about that. :S
> Thanks. :)
>
> Ivo

Ah, does the patch I have applied and am running need enhancement, please?

Thanks

--

-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
Permalink | Reply | 4 comments |
headers
Johannes Berg | 2 Jan 09:11
Favicon

Re: Warning emited by 2.6.24-rc6-git5

Hi,

Happy New Year! I was out since Saturday just before you sent your
message, sorry for the late reply.

> 	header_size = ieee80211_get_hdrlen_from_skb(entry->skb);
> 	if (header_size % 4 == 2) {
> 		/*
> 		 * Move entire frame 2 bytes to the front.
> 		 */
> 		skb_push(entry->skb, 2);
> 		memmove(entry->skb->data, entry->skb->data + 2,
> 			entry->skb->len - 2);
> 	}

That doesn't really look right, I'd think the skb will be two bytes too
long after this. It's probably more efficient to decide where to copy
the frame and do the realignment while you're copying it anyway rather
than doing a copy and then a memmove.

I guess you should also try talk to Ralink to get firmware to do it
(where possible), it's probably not too hard to insert padding before
the frame.

If you absolutely can't get the hardware to do it and would otherwise do
DMA right into the skb we should try to evaluate the performance hit on
platforms where unaligned access *is* possible to be able to balance it
against the performance hit caused by the memmove(). Ultimately, though,
I value correctness on all platforms over performance on some, hence the
warning when unaligned packets are handed up to mac80211.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Johannes Berg | 2 Jan 09:41
Favicon

Re: [PATCH] mac80211: better rate control algorithm selection


> Why don't we just build the rate control algorithms entirely separate
> useing obj-$(FOO) ?  If they're modular that lets them be their own
> module, and if they're built-in they'll still go into built-in.o.

Yeah. Except that they can't be built-in if mac80211 isn't, and we've
repeatedly had users f' up their installations and bitterly report to us
that mac80211 doesn't work because no rate control algorithm is
available so we wanted to force having one built into mac80211.ko unless
specifically turned off (only with EMBEDDED).

johannes
Permalink | Reply | 6 comments |
headers
Christoph Hellwig | 2 Jan 09:45
Favicon

Re: [PATCH] mac80211: better rate control algorithm selection

On Wed, Jan 02, 2008 at 09:41:15AM +0100, Johannes Berg wrote:
> 
> > Why don't we just build the rate control algorithms entirely separate
> > useing obj-$(FOO) ?  If they're modular that lets them be their own
> > module, and if they're built-in they'll still go into built-in.o.
> 
> Yeah. Except that they can't be built-in if mac80211 isn't, and we've
> repeatedly had users f' up their installations and bitterly report to us
> that mac80211 doesn't work because no rate control algorithm is
> available so we wanted to force having one built into mac80211.ko unless
> specifically turned off (only with EMBEDDED).

Building an algorithm optionally into mac80211 seems rather odd.  In
case mac80211 the algorithms should be their own modules and you should
use request_module to make sure at least one is loaded.  Or if you
really want to make sure one is alway avaiabable always build the
simplest one directly and unconditionally into mac80211.ko.

> 
> johannes

---end quoted text---
Permalink | Reply | 5 comments |
headers
Johannes Berg | 2 Jan 09:48
Favicon

Re: Strange mac80211 oops


On Sat, 2007-12-29 at 17:24 +0100, Michael Buesch wrote:
> This patch fixes RX packet alignment issues in the zd1211rw driver.
> This is based on a patch by Johannes Berg.
> 
> Signed-off-by: Michael Buesch <mb@...>

Looks good to me, I guess you tested it.

Acked-by: Johannes Berg <johannes@...>

> Index: wireless-2.6/drivers/net/wireless/zd1211rw/zd_mac.c
> ===================================================================
> --- wireless-2.6.orig/drivers/net/wireless/zd1211rw/zd_mac.c	2007-12-29 17:14:41.000000000 +0100
> +++ wireless-2.6/drivers/net/wireless/zd1211rw/zd_mac.c	2007-12-29 17:15:00.000000000 +0100
> @@ -623,6 +623,8 @@ int zd_mac_rx(struct ieee80211_hw *hw, c
>  	const struct rx_status *status;
>  	struct sk_buff *skb;
>  	int bad_frame = 0;
> +	u16 fc;
> +	bool is_qos, is_4addr, need_padding;
>  
>  	if (length < ZD_PLCP_HEADER_SIZE + 10 /* IEEE80211_1ADDR_LEN */ +
>  	             FCS_LEN + sizeof(struct rx_status))
> @@ -674,9 +676,22 @@ int zd_mac_rx(struct ieee80211_hw *hw, c
>  			&& !mac->pass_ctrl)
>  		return 0;
>  
> -	skb = dev_alloc_skb(length);
> +	fc = le16_to_cpu(*((__le16 *) buffer));
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johannes Berg | 2 Jan 09:52
Favicon

Re: [PATCH] mac80211: better rate control algorithm selection


> Building an algorithm optionally into mac80211 seems rather odd.  In
> case mac80211 the algorithms should be their own modules and you should
> use request_module to make sure at least one is loaded.

We actually do that but people still manage to mess it up because they
don't install the modules properly or whatever.

> Or if you
> really want to make sure one is alway avaiabable always build the
> simplest one directly and unconditionally into mac80211.ko.

That'd be an alternative too, I think we have something like that now. I
don't really like it that much though because for 99% of people it's
just dead code. Anyway, I'll look into Sam's mail and do a new patch
depending on that.

johannes
Permalink | Reply | 4 comments |
headers
Johannes Berg | 2 Jan 15:04
Favicon

Re: [PATCH] mac80211: better rate control algorithm selection

Hi Sam,

Thanks for your reply.

> MAC80211_RC_PID build-in =>
>     rc80211_pid_algo as build-in
>     rc80211_pid_debugfs as build-in if CONFIG_MAC80211_DEBUGFS equals y (is enabled)
> 
> MAC80211_RC_PID module =>
>    rc80211_pid.o as a module 
>    rc80211_pid_algo.o and rc80211_pid_debugfs.o are ignored

Well, 'ignored' may be too strong since rc80211_pid.o is built from the
latter two objects.

> # If RC algorithm in build-in
> rate-rc-y := rc80211_pid_algo.o
> rate-rc-$(CONFIG_MAC80211_DEBUGFS) += rc80211_pid_debugfs.o
> 
> # If RC algorithm is modular
> rate-rc-m := rc80211_pid.o

I don't think that will work since the system won't know how to build
rc80211_pid.o. I have another patch inspired by yours which is much
better than my first, just need to test it.

johannes
Permalink | Reply | 0 comments |

Gmane