Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY

[Ben Collins]

> On May 4, 2015, at 5:32 PM, Rabin Vincent  wrote:
> 
> On Sat, May 02, 2015 at 09:03:28PM +0200, Greg Kroah-Hartman wrote:
>> 3.14-stable review patch.  If anyone has any objections, please let me know.
>> 
>> ----------
>> 
>> From: Ben Collins 
>> 
>> commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.
> 
> The commit in question was recently merged to mainline and is now being
> sent to various stable kernels.  But I think the patch is wrong and the
> real problem lies in the Freescale CAAM driver which is described as
> having being tested with.

There may be something quirky with CAAM, yes, but the fact is, the code
in the dm-crypt module was very dissimilar to other drivers performing
the same loop/logic.

I don’t think that this patch, which was deemed correct, should be held
up based on lower level logic “possibly” being partially at fault. On the
contrary, I think errors you point out may just be showing the error in
dm-crypt more easily, rather than being the complete problem.

> commit 0618764cb25f6fa9fb31152995de42a8a0496475
> Author: Ben Collins 
> Date:   Fri Apr 3 16:09:46 2015 +
> 
> dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
> 
> I suspect this doesn't show up for most anyone because software
> algorithms typically don't have a sense of being too busy.  However,
> when working with the Freescale CAAM driver it will return -EBUSY on
> occasion under heavy -- which resulted in dm-crypt deadlock.
> 
> After checking the logic in some other drivers, the scheme for
> crypt_convert() and it's callback, kcryptd_async_done(), were not
> correctly laid out to properly handle -EBUSY or -EINPROGRESS.
> 
> Fix this by using the completion for both -EBUSY and -EINPROGRESS.  Now
> crypt_convert()'s use of completion is comparable to
> af_alg_wait_for_completion().  Similarly, kcryptd_async_done() follows
> the pattern used in af_alg_complete().
> 
> Before this fix dm-crypt would lockup within 1-2 minutes running with
> the CAAM driver.  Fix was regression tested against software algorithms
> on PPC32 and x86_64, and things seem perfectly happy there as well.
> 
> Signed-off-by: Ben Collins 
> Signed-off-by: Mike Snitzer 
> Cc: sta...@vger.kernel.org
> 
> dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG.  This means the the crypto
> driver should internally backlog requests which arrive when the queue is
> full and process them later.  Until the crypto hw's queue becomes full,
> the driver returns -EINPROGRESS.  When the crypto hw's queue if full,
> the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
> expected to backlog the request and process it when the hardware has
> queue space.  At the point when the driver takes the request from the
> backlog and starts processing it, it calls the completion function with
> a status of -EINPROGRESS.  The completion function is called (for a
> second time, in the case of backlogged requests) with a status/err of 0
> when a request is done.
> 
> Crypto drivers for hardware without hardware queueing use the helpers,
> crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
> and crypto_get_backlog() helpers to implement this behaviour correctly,
> while others implement this behaviour without these helpers (ccp, for
> example).
> 
> dm-crypt (before this patch) uses this API correctly.  It queues up as
> many requests as the hw queues will allow (i.e. as long as it gets back
> -EINPROGRESS from the request function).  Then, when it sees at least
> one backlogged request (gets -EBUSY), it waits till that backlogged
> request is handled (completion gets called with -EINPROGRESS), and then
> continues.  The references to af_alg_wait_for_completion() and
> af_alg_complete() in the commit message are irrelevant because those
> functions only handle one request at a time, unlink dm-crypt.
> 
> The problem is that the Freescale CAAM driver, which this problem is
> described as being seen on, fails to implement the backlogging behaviour
> correctly.  In cam_jr_enqueue(), if the hardware queue is full, it
> simply returns -EBUSY without backlogging the request.  What the
> observed deadlock was is not described in the commit message but it is
> obviously the wait_for_completion() in crypto_convert() where dm-crypto
> would wait for the completion being called with -EINPROGRESS in the case
> of backlogged requests.  This completion will never be completed due to
> the bug in the CAAM driver.
> 
> What this patch does is that it makes dm-crypt wait for every request,
> even when the driver/hardware queues are not full, which means that

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 12:16 PM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 12:14:44 -0400
> 
>> I'm sorry, I thought we were working on open source projects
>> here. If the code isn't encumbered by patents, legal issues or
>> technical problems, and is licensed compatible with the kernel, I
>> just thought it was fair game.
> 
> This is about being nice to people, rather than exercising your rights
> to the maximum possible extent regardless of how that effects other
> people.



Right, because a 3-line patch is such a ballsy move on my part. Better restrain 
myself next time.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 11:59 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 11:53:54 -0400
> 
>> Also, if there's a patch that makes my hardware work, but I can't
>> use it because (even though it's open source licensed) the author
>> doesn't want it in mainline, then that is effectively squatting.
> 
> This is called respecting the wishes of the author of the code, I'm
> sorry if this is a foreign concept for you.


I'm sorry, I thought we were working on open source projects here. If the code 
isn't encumbered by patents, legal issues or technical problems, and is 
licensed compatible with the kernel, I just thought it was fair game.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 11:41 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 11:39:20 -0400
> 
>> If your company had hardware going to production, you'd want it
>> supported in mainline too, I suspect.
> 
> But never against the wishes of the author of the code.
> 
> This has firm and strict precedence, for example one of the
> implementations block layer encryption was not wanted to be merged by
> the author, and Linus reverted it.
> 
> So if the person who wrote the code doesn't want it upstream, you can't
> bypass them against their wishes, ever.  It's their code not your's.

They never made such a statement. The commit (which is publicly available in 
Freescale's git repo) makes no mention of it being "good enough for our SDK, 
but don't send upstream". Freescale wants this upstream, but doesn't have the 
resources because they are embedded focused and gear more toward SDKs to 
support their SoCs (currently that means a 3.0.x kernel).

Don't accuse me of something I didn't do. Also, if there's a patch that makes 
my hardware work, but I can't use it because (even though it's open source 
licensed) the author doesn't want it in mainline, then that is effectively 
squatting.

We are a hardware company. We've been provided with a driver for the platform 
we designed by the SoC vendor. It's GPL licensed. We've attempted to get this 
done by them, but they haven't been able to, so we are exercising prudence and 
making sure our platform is supported in mainline. I don't see where that's any 
different than tons of other patches that go into the kernel.

If it makes everyone feel better, I'll limit attribution in the patches to just 
an Originally-By: line.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 11:17 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 10:43:44 -0400
> 
>> "For us" is a loose term, when it's more that we are attempting to
>> upstream code so our system is supported by a mainline kernel
>> instead of having one-off kernels.
> 
> If this other person doesn't want their code upstreams, it is absolutely
> inappropriate for you to try and force the matter and "do it for them."


If your company had hardware going to production, you'd want it supported in 
mainline too, I suspect.

Either way, I'll redact this patch because it isn't necessarily needed for the 
driver to work.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 10:23 AM, Eric Dumazet  wrote:

> On Wed, 2011-07-13 at 08:52 -0500, Andy Fleming wrote:
>> The QDisc code does a bunch of locking which is unnecessary if
>> you have hardware which handles all of the queueing. Add
>> support for this, and skip over all of the queueing code if
>> the feature is enabled on a given device, which breaks QDisc
>> support on dpaa_eth, and also coopts the FCOE feature bit.
>> 
>> Signed-off-by: Andy Fleming 
>> Signed-off-by: Ben Collins 
>> Cc: net...@vger.kernel.org
>> ---
>> include/linux/netdev_features.h | 2 ++
>> net/core/dev.c  | 6 ++
>> 2 files changed, 8 insertions(+)
>> 
>> diff --git a/include/linux/netdev_features.h 
>> b/include/linux/netdev_features.h
>> index 3dd3934..ffb4587 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -56,6 +56,7 @@ enum {
>>  NETIF_F_LOOPBACK_BIT,   /* Enable loopback */
>>  NETIF_F_RXFCS_BIT,  /* Append FCS to skb pkt data */
>>  NETIF_F_RXALL_BIT,  /* Receive errored frames too */
>> +NETIF_F_HW_QDISC_BIT,   /* Supports hardware Qdisc */
>> 
>>  /*
>>   * Add your fresh new feature above and remember to update
>> @@ -80,6 +81,7 @@ enum {
>> #define NETIF_F_GSO_ROBUST   __NETIF_F(GSO_ROBUST)
>> #define NETIF_F_HIGHDMA  __NETIF_F(HIGHDMA)
>> #define NETIF_F_HW_CSUM  __NETIF_F(HW_CSUM)
>> +#define NETIF_F_HW_QDISC__NETIF_F(HW_QDISC)
>> #define NETIF_F_HW_VLAN_FILTER   __NETIF_F(HW_VLAN_FILTER)
>> #define NETIF_F_HW_VLAN_RX   __NETIF_F(HW_VLAN_RX)
>> #define NETIF_F_HW_VLAN_TX   __NETIF_F(HW_VLAN_TX)
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index dffbef7..6818b18 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2743,6 +2743,12 @@ int dev_queue_xmit(struct sk_buff *skb)
>> 
>>  skb_update_prio(skb);
>> 
>> +if (dev->features & NETIF_F_HW_QDISC) {
>> +txq = netdev_pick_tx(dev, skb);
>> +rc = dev_hard_start_xmit(skb, dev, txq);
>> +goto out;
>> +}
>> +
>>  txq = netdev_pick_tx(dev, skb);
>>  q = rcu_dereference_bh(txq->qdisc);
>> 
> 
> Nobody forces you to use a qdisc.
> 
> And if your device really is lockless, it can use NETIF_F_LLTX feature.


NETIF_F_LLTX_BIT,   /* LockLess TX - deprecated. Please */
/* do not use LLTX in new drivers */

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: Add support for handling queueing in hardware

[Ben Collins]

On Mar 22, 2013, at 10:33 AM, David Miller  wrote:

> From: Fleming Andy-AFLEMING 
> Date: Fri, 22 Mar 2013 14:31:50 +
> 
>> It would appear one of our customers is attempting to upstream our
>> code for us. We are aware that this current solution is unacceptable
>> (which is why we have not submitted it), and we are currently trying
>> to develop a less hacky solution that integrates with qdisc.
> 
> Ben, can can you coordinate with people instead of doing crap like
> this?


"For us" is a loose term, when it's more that we are attempting to upstream 
code so our system is supported by a mainline kernel instead of having one-off 
kernels.

And we have been talking with Freescale about this for quite some time (couple 
years?). They have a roadmap that doesn't include getting this driver supported 
in mainline any time soon, so I'm taking time to get this done for our own 
system. I'm not meaning to step on any toes.

Believe me, I've attempted to make this as painless as possible. Only having 5 
patches (and each just a few lines) is significantly less than how this driver 
started out. I can toss out the QDisc patch and work on a better way. I'm not 
totally familiar with the queueing, so any pointers to a better way to handle 
this would be appreciated.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] phy: Add XGMII phy interface type

[Ben Collins]

On Mar 22, 2013, at 10:27 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 10:22:05 -0400
> 
>> It's code that I've manually stripped down as a subset of a larger
>> code base for Freescale's DPAA driver. I've only tested it on our
>> (Servergy's) platform, so until it gets more broad testing (and some
>> code review), I want to at least get it into staging so our hardware
>> is supported.
> 
> Then why don't you submit the PHY type addition with the staging
> driver, which will be the only user, and you can add my:
> 
> Acked-by: David S. Miller 


That I can do. Greg had asked I get all the rest of this signed off before he 
could take the driver into staging.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] phy: Add XGMII phy interface type

[Ben Collins]

On Mar 22, 2013, at 10:19 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Fri, 22 Mar 2013 10:17:35 -0400
> 
>> On Mar 22, 2013, at 10:12 AM, David Miller  wrote:
>> 
>>> From: Ben Collins 
>>> Date: Mon, 18 Mar 2013 19:53:42 -0400
>>> 
>>>> Used by systems based on certain Freescale SoCs (specifically the
>>>> Servergy CTS-1000 system).
>>>> 
>>>> Signed-off-by: Ben Collins 
>>> 
>>> You can resubmit this patch when you submit a driver upstream that
>>> uses it, so we can see what the use case looks like.
>> 
>> That patch is getting sent soon. It's starting out in staging. Should I Cc 
>> you on that?
> 
> Why don't you wait until the driver is good enough for drivers/net proper?


It's code that I've manually stripped down as a subset of a larger code base 
for Freescale's DPAA driver. I've only tested it on our (Servergy's) platform, 
so until it gets more broad testing (and some code review), I want to at least 
get it into staging so our hardware is supported.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] phy: Add XGMII phy interface type

[Ben Collins]

On Mar 22, 2013, at 10:12 AM, David Miller  wrote:

> From: Ben Collins 
> Date: Mon, 18 Mar 2013 19:53:42 -0400
> 
>> Used by systems based on certain Freescale SoCs (specifically the
>> Servergy CTS-1000 system).
>> 
>> Signed-off-by: Ben Collins 
> 
> You can resubmit this patch when you submit a driver upstream that
> uses it, so we can see what the use case looks like.

That patch is getting sent soon. It's starting out in staging. Should I Cc you 
on that?

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] phy: Add support for VSC8234

[Ben Collins]

On Mar 22, 2013, at 10:13 AM, David Miller  wrote:

> From: Andy Fleming 
> Date: Sun, 16 Oct 2011 01:49:49 -0500
> 
>> No functional changes other than to recognize this PHYID.
>> 
>> Signed-off-by: Andy Fleming 
>> Signed-off-by: Kumar Gala 
>> Signed-off-by: Ben Collins 
> 
> Please do not submit patches with the commit date integrated
> into your formal email headers.
> 
> This screws up archives and patch queue maintainence systems which
> order submissions by date.


For the record, this wasn't Andy, it was me. Noted.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] phy: Add XGMII phy interface type

[Ben Collins]

Used by systems based on certain Freescale SoCs (specifically the
Servergy CTS-1000 system).

Signed-off-by: Ben Collins 
Cc: net...@vger.kernel.org
---
 include/linux/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 33999ad..5a94ec7 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -64,6 +64,7 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
+   PHY_INTERFACE_MODE_XGMII,
 } phy_interface_t;
 
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sgy-cts-1000: New DTS file for Servergy CTS-1000 systems

[Ben Collins]

This isn't specifically needed in order to build the kernel. It's
stored in flash with firmware. However, keep it in the kernel for
reference (and to have an example for fsl_dpa device tree usage).

Signed-off-by: Ben Collins 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/boot/dts/sgy-cts-1000.dts | 1570 
 1 file changed, 1570 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/sgy-cts-1000.dts

diff --git a/arch/powerpc/boot/dts/sgy-cts-1000.dts 
b/arch/powerpc/boot/dts/sgy-cts-1000.dts
new file mode 100644
index 000..1efa01a
--- /dev/null
+++ b/arch/powerpc/boot/dts/sgy-cts-1000.dts
@@ -0,0 +1,1570 @@
+/*
+ * Servergy CTS-1000 Device Tree Source
+ *
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2013 Servergy, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/ {
+   model = "sgy,cts-1000";
+   compatible = "fsl,P4080DS";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   aliases {
+   ccsr = &soc;
+   dcsr = &dcsr;
+
+   ethernet4 = &enet4;
+   ethernet7 = &enet7;
+   ethernet8 = &enet8;
+   ethernet9 = &enet9;
+   serial0 = &serial0;
+   serial1 = &serial1;
+   pci0 = &pci0;
+   usb0 = &usb0;
+   usb1 = &usb1;
+   dma0 = &dma0;
+   dma1 = &dma1;
+   bman = &bman;
+   qman = &qman;
+   pme = &pme;
+   msi0 = &msi0;
+   msi1 = &msi1;
+   msi2 = &msi2;
+
+   crypto = &crypto;
+   sec_jr0 = &sec_jr0;
+   sec_jr1 = &sec_jr1;
+   sec_jr2 = &sec_jr2;
+   sec_jr3 = &sec_jr3;
+   rtic_a = &rtic_a;
+   rtic_b = &rtic_b;
+   rtic_c = &rtic_c;
+   rtic_d = &rtic_d;
+   sec_mon = &sec_mon;
+
+   fman0 = &fman0;
+   fman0_oh0 = &fman0_oh0;
+   fman0_oh1 = &fman0_oh1;
+   fman0_oh2 = &fman0_oh2;
+   fman0_oh3 = &fman0_oh3;
+   fman0_oh4 = &fman0_oh4;
+   fman0_oh5 = &fman0_oh5;
+   fman0_oh6 = &fman0_oh6;
+   fman0_rx0 = &fman0_rx0;
+   fman0_rx1 = &fman0_rx1;
+   fman0_rx2 = &fman0_rx2;
+   fman0_rx3 = &fman0_rx3;
+   fman0_rx4 = &fman0_rx4;
+
+   fman1 = &fman1;
+   fman1_oh0 = &fman1_oh0;
+   fman1_oh1 = &fman1_oh1;
+   fman1_oh2 = &fman1_oh2;
+   fman1_oh3 = &fman1_oh3;
+   fman1_oh4 = &fman1_oh4;
+   fman1_oh5 = &fman1_oh5;
+   fman1_oh6 = &fman1_oh6;
+   fman1_rx0 = &fman1_rx0;
+   fman1_rx1 = &fman1_rx1;
+   fman1_rx2 = &fman1_rx2;
+   f

[PATCH] of_mdio: Remove flags argument from of_phy_connect

[Ben Collins]

of_phy_connect() only required a flags argument in order to pass it down to
to phy_connect(). Since that argument was removed, it is of no use in this
function either (confirmed by checking all callers in kernel tree as well).

Signed-off-by: Ben Collins 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: devicetree-disc...@lists.ozlabs.org
---
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/octeon/octeon_mgmt.c | 2 +-
 drivers/net/ethernet/pasemi/pasemi_mac.c  | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 drivers/of/of_mdio.c  | 2 +-
 drivers/staging/octeon/ethernet-mdio.c| 2 +-
 include/linux/of_mdio.h   | 4 ++--
 13 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c 
b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 77943a6..ea01dcd 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -217,7 +217,7 @@ static int mpc52xx_fec_open(struct net_device *dev)
 
if (priv->phy_node) {
priv->phydev = of_phy_connect(priv->ndev, priv->phy_node,
- mpc52xx_fec_adjust_link, 0, 0);
+ mpc52xx_fec_adjust_link, 0);
if (!priv->phydev) {
dev_err(&dev->dev, "of_phy_connect failed\n");
return -ENODEV;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 46df288..5523fc0 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -799,7 +799,7 @@ static int fs_init_phy(struct net_device *dev)
iface = fep->fpi->use_rmii ?
PHY_INTERFACE_MODE_RMII : PHY_INTERFACE_MODE_MII;
 
-   phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link, 0,
+   phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link,
iface);
if (!phydev) {
phydev = of_phy_connect_fixed_link(dev, &fs_adjust_link,
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index d2c5441..383d302 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1467,7 +1467,7 @@ static int init_phy(struct net_device *dev)
 
interface = gfar_get_interface(dev);
 
-   priv->phydev = of_phy_connect(dev, priv->phy_node, &adjust_link, 0,
+   priv->phydev = of_phy_connect(dev, priv->phy_node, &adjust_link,
  interface);
if (!priv->phydev)
priv->phydev = of_phy_connect_fixed_link(dev, &adjust_link,
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index 0a70bb5..fb9a573 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1745,7 +1745,7 @@ static int init_phy(struct net_device *dev)
priv->oldspeed = 0;
priv->oldduplex = -1;
 
-   phydev = of_phy_connect(dev, ug_info->phy_node, &adjust_link, 0,
+   phydev = of_phy_connect(dev, ug_info->phy_node, &adjust_link,
priv->phy_interface);
if (!phydev)
phydev = of_phy_connect_fixed_link(dev, &adjust_link,
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index cd345b8..dcb865e8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2344,7 +2344,7 @@ static int mvneta_mdio_probe(struct mvneta_port *pp)
 {
struct phy_device *phy_dev;
 
-   phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link, 0,
+   phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link,
 pp->phy_interface);
if (!phy_dev) {
netdev_err(pp->dev, "could not find the PHY\n");
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c 
b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 921729f..c2d281e 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -970,7 +970,7 @@ static int octeon_mgmt_init_phy(struct 

[PATCH] sgy-cts1000: Remove __dev* attributes

[Ben Collins]

Somehow the driver snuck in with these still in it.

Signed-off-by: Ben Collins 
---
 arch/powerpc/platforms/85xx/sgy_cts1000.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/sgy_cts1000.c 
b/arch/powerpc/platforms/85xx/sgy_cts1000.c
index 611e92f..7179726 100644
--- a/arch/powerpc/platforms/85xx/sgy_cts1000.c
+++ b/arch/powerpc/platforms/85xx/sgy_cts1000.c
@@ -69,7 +69,7 @@ static irqreturn_t gpio_halt_irq(int irq, void *__data)
 return IRQ_HANDLED;
 };
 
-static int __devinit gpio_halt_probe(struct platform_device *pdev)
+static int gpio_halt_probe(struct platform_device *pdev)
 {
enum of_gpio_flags flags;
struct device_node *node = pdev->dev.of_node;
@@ -128,7 +128,7 @@ static int __devinit gpio_halt_probe(struct platform_device 
*pdev)
return 0;
 }
 
-static int __devexit gpio_halt_remove(struct platform_device *pdev)
+static int gpio_halt_remove(struct platform_device *pdev)
 {
if (halt_node) {
int gpio = of_get_gpio(halt_node, 0);
@@ -165,7 +165,7 @@ static struct platform_driver gpio_halt_driver = {
.of_match_table = gpio_halt_match,
},
.probe  = gpio_halt_probe,
-   .remove = __devexit_p(gpio_halt_remove),
+   .remove = gpio_halt_remove,
 };
 
 module_platform_driver(gpio_halt_driver);
-- 
1.8.1.2


--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: ehci-fsl: Return valid error in ehci_fsl_setup_phy

[Ben Collins]

ehci_fsl_setup_phy is supposed to return an int, but had a void return
value in the case of controller_ver being invalid.

Signed-off-by: Ben Collins 
Cc: Shengzhou Liu 
---
 drivers/usb/host/ehci-fsl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9bfde82..0d2f35c 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -222,7 +222,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
 
if (pdata->controller_ver < 0) {
dev_warn(hcd->self.controller, "Could not get controller 
version\n");
-   return;
+   return -ENODEV;
}
 
portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
-- 
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SPARC64] Export symbols for sunvnet and sunvdc to be built modular

[Ben Collins]

On Tue, 2007-12-04 at 00:23 -0800, David Miller wrote:
> From: Ben Collins <[EMAIL PROTECTED]>
> Date: Thu, 29 Nov 2007 17:02:10 -0500
> 
> > Fixes this build failure:
> > 
> > ERROR: "vio_driver_init" [drivers/net/sunvnet.ko] undefined!
> > ERROR: "vio_driver_init" [drivers/block/sunvdc.ko] undefined!
> > ERROR: "ldc_map_sg" [drivers/block/sunvdc.ko] undefined!
> > 
> > Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
> 
> Please check what you are patching against.
> 
> Every 2.6.x tree I have access to has these exports in
> the precise locations you are adding them.
> 
> I suspect you have some local change intergration issue
> in the tree where you encountered this build error.

I was pretty sure I diff'd the tree I have against linux-2.6/master, but
maybe not.

Thanks

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
SwissDisk: http://www.swissdisk.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[SPARC64] Export symbols for sunvnet and sunvdc to be built modular

[Ben Collins]

Fixes this build failure:

ERROR: "vio_driver_init" [drivers/net/sunvnet.ko] undefined!
ERROR: "vio_driver_init" [drivers/block/sunvdc.ko] undefined!
ERROR: "ldc_map_sg" [drivers/block/sunvdc.ko] undefined!
    
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/arch/sparc64/kernel/ldc.c b/arch/sparc64/kernel/ldc.c
index cbe6fa2..be80948 100644
--- a/arch/sparc64/kernel/ldc.c
+++ b/arch/sparc64/kernel/ldc.c
@@ -2105,6 +2105,7 @@ int ldc_map_sg(struct ldc_channel *lp,
 
return state.nc;
 }
+EXPORT_SYMBOL(ldc_map_sg);
 
 int ldc_map_single(struct ldc_channel *lp,
   void *buf, unsigned int len,
diff --git a/arch/sparc64/kernel/viohs.c b/arch/sparc64/kernel/viohs.c
index eeeb5ed..708fa17 100644
--- a/arch/sparc64/kernel/viohs.c
+++ b/arch/sparc64/kernel/viohs.c
@@ -819,3 +819,4 @@ int vio_driver_init(struct vio_driver_state *vio, struct 
vio_dev *vdev,
 
return 0;
 }
+EXPORT_SYMBOL(vio_driver_init);

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
SwissDisk: http://www.swissdisk.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression: fireware causes oops during system

[Ben Collins]

On Tue, 2007-09-11 at 21:00 +0200, Pavel Machek wrote:
> Hi!
> 
> I noticed empty suspend stopped working around 2.6.23-rc4, and it is
> still present in 2.6.23-rc6. To reproduce
> 
> swapoff -a 
> echo disk > /sys/power/state
> echo disk > /sys/power/state
> 
> Unsetting
> 
> CONFIG_IEEE1394=y
> 
> solves the problem.

Since this is easy to reproduce, can you bisect it down?

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
SwissDisk: http://www.swissdisk.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression in 2.6.22, clock problems on Turion with 32-bit kernel

[Ben Collins]

On Fri, 2007-08-03 at 11:50 -0400, Cal Peake wrote:
> On Fri, 3 Aug 2007, Ben Collins wrote:
> 
> > 
> > On Fri, 2007-08-03 at 08:30 -0700, Arjan van de Ven wrote:
> > > > I've tried every combination of boot param revolving around clocksource
> > > > and interrupts. The only thing that gets me booting is nolapic, but then
> > > > again, that knocks me down to a single cpu. 
> > > 
> > > hummm I wonder how nolapic knows you down to a single cpu...
> > > that is just an entirely strange relationship.
> > 
> > Sorry, s/cpu/core/, but not sure if that makes a difference.
> 
> Ben, Tim,
> 
> See thread <http://marc.info/?t=11857327166&r=1&w=2>. Short version: 
> nolapic_timer should fix things for the moment. Long term: some AMD kernel 
> code needs to be fixed up to deal with a broken local APIC.


nolapic_timer does not fix it for me. Only nolapic and acpi=off works. I
commented on that thread as well now, thanks.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI on Averatec 2370

[Ben Collins]

On Thu, 2007-08-02 at 14:07 -0700, Linus Torvalds wrote:
> 
> On Thu, 2 Aug 2007, Cal Peake wrote:
> > 
> > Figured I should have sent that right after I hit the send key...
> > 
> > processor   : 0
> > vendor_id   : AuthenticAMD
> > cpu family  : 15
> > model   : 72
> > model name  : AMD Turion(tm) 64 X2 Mobile Technology TL-52
> 
> Sadly, this doesn't show the "extended family" stuff from cpuid.
> 
> So it doesn't show any of the bits we actually care about. Sad.
> 
> That said, the "AMD Turion(tm) 64 X2 Mobile Technology TL-52" _should_ be 
> a REV-F CPU afaik, and it should have thus fallen through to the 
> "ENABLE_C1E_MASK" logic. Afaik that's broken.
> 
> Cal - can you
>  (a) test that forcing a "return 1" from that amd_apic_timer_broken() 
>  function fixes it for you.
>  (b) make that function print out the values it uses for debugging (ie the 
>  xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR 
>  values)?
> 
> Andi, can you check with your AMD contacts that those bits are correct.. 
> Maybe the "Mobile Technology" things *always* have the broken "Enhanced 
> Halt State", regardless of any MSR settings? That would perhaps be what 
> makes them "Mobile".

This is the same problem I'm seeing (See Subject: Regression in 2.6.22,
clock problems on Turion with 32-bit kernel).

This commit is what we bisected to:

commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date:   Fri Feb 16 01:28:04 2007 -0800

[PATCH] clockevents: i386 drivers

Add clockevent drivers for i386: lapic (local) and PIT/HPET (global).  
Update
the timer IRQ to call into the PIT/HPET driver's event handler and the
lapic-timer IRQ to call into the lapic clockevent driver.  The assignement 
of
timer functionality is delegated to the core framework code and replaces the
compile and runtime evalution in do_timer_interrupt_hook()

Use the clockevents broadcast support and implement the lapic_broadcast
function for ACPI.

No changes to existing functionality.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression in 2.6.22, clock problems on Turion with 32-bit kernel

[Ben Collins]

On Fri, 2007-08-03 at 08:30 -0700, Arjan van de Ven wrote:
> > I've tried every combination of boot param revolving around clocksource
> > and interrupts. The only thing that gets me booting is nolapic, but then
> > again, that knocks me down to a single cpu. 
> 
> hummm I wonder how nolapic knows you down to a single cpu...
> that is just an entirely strange relationship.

Sorry, s/cpu/core/, but not sure if that makes a difference.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Regression in 2.6.22, clock problems on Turion with 32-bit kernel

[Ben Collins]

Tim and I have both experienced this problem. With 2.6.20 things worked
perfectly fine on these systems. The two machines are a Dell 1501 Turion
X2 and Dell 1521 Turion X2.

With 2.6.22 the kernel hangs shortly after starting up, but after
several minutes, you can get activity by tapping keyboard (generating
interrupts). We have NO_HZ and HIGH_RES enabled, but even disabling this
doesn't help.

I've tried every combination of boot param revolving around clocksource
and interrupts. The only thing that gets me booting is nolapic, but then
again, that knocks me down to a single cpu. Setting maxcpus=1 or nosmp
doesn't fix it.

We both bisected (separately I might add) down to this commit:

commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date:   Fri Feb 16 01:28:04 2007 -0800

[PATCH] clockevents: i386 drivers

Add clockevent drivers for i386: lapic (local) and PIT/HPET (global).  
Update
the timer IRQ to call into the PIT/HPET driver's event handler and the
lapic-timer IRQ to call into the lapic clockevent driver.  The assignement 
of
timer functionality is delegated to the core framework code and replaces the
compile and runtime evalution in do_timer_interrupt_hook()

Use the clockevents broadcast support and implement the lapic_broadcast
function for ACPI.

No changes to existing functionality.

Note, the problem doesn't happen when using an x86_64 kernel with the
same basic config, on the same machine.

Hoping to get some tips to test something a bit more specific in this
patch.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ieee1394: forgotten dereference...

[Ben Collins]

On Sun, 2007-07-15 at 20:59 +0100, Al Viro wrote:
> Going through the string and waiting for _pointer_ to become '\0'
> is not what the authors meant...
> 
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
>  drivers/ieee1394/nodemgr.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c
> index c4d3d41..51a1206 100644
> --- a/drivers/ieee1394/nodemgr.c
> +++ b/drivers/ieee1394/nodemgr.c
> @@ -283,7 +283,7 @@ static ssize_t fw_show_##class##_##td_kv (struct device 
> *dev, struct device_attr
>   memcpy(buf, \
>  CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA(class->td_kv),  \
>  len);\
> - while ((buf + len - 1) == '\0') \
> + while (buf[len - 1] == '\0')\
>   len--;  \
>   buf[len++] = '\n';  \
>   buf[len] = '\0';\

ACK

Definitely looks right with your patch. Thanks.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2/3] 2.6.22-rc3: known regressions with patches

[Ben Collins]

On Tue, 2007-05-29 at 14:53 +0200, Michal Piotrowski wrote:

> Subject: OOPS triggered by ip(8) deconfiguring a network interface
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8491
> Submitter  : Ben Collins <[EMAIL PROTECTED]>
> Patch  : http://marc.info/?l=linux-netdev&m=117915849224816&w=2
>  commit 5632c5152aa621885d87ea0b8fdd5a6bb9f69c6f
> Status : bug probably fixed

Seems to be fixed, and just marked it resolved on bugzilla.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

On Fri, 2007-05-25 at 16:28 -0700, H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > 
> > But how often do you have to debug bootloader or compressed boot code?  In 
> > fact, most debug output like this isn't very useful after some initial 
> > debugging, so we usually take it out.  I'm not sure why this would be any 
> > different...
> > 
> 
> You're asking me this?
> 
> I get to hear all the time about some new platform -- sometimes exotic,
> sometimes not -- breaking early boot.

Truth be told, I'd much rather just remove the informational pustr's and
leave the error ones enabled. If it's acceptable, I can just remove
those lines, or make them only work with -DDEBUG.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
> 
> Why? 

Because there's no other way to make the kernel totally quiet. We've
been patching this out so that the boot sequence has that "clean look".

Other than that, it's useless :)

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Ben Collins]

On Thu, 2007-05-24 at 13:48 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 18:23:06 -0400
> Ben Collins <[EMAIL PROTECTED]> wrote:
> 
> > Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
> > ---
> >  drivers/char/rtc.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
> > index 20380a2..22cf7aa 100644
> > --- a/drivers/char/rtc.c
> > +++ b/drivers/char/rtc.c
> > @@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
> >  
> > spin_unlock_irq(&rtc_lock);
> >  
> > -   printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> > +   if (printk_ratelimit())
> > +   printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", 
> > freq);
> >  
> 
> Presumably someone is getting a lot of these messages.
> 
> Do we know why?  Is there something which needs fixing here?

I got it a lot when using any sort of virtualization on my Core2Duo
(kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
2.6.20, and haven't tested again with latest kernel.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] HCIUSB: Initialize the Broadcom USB Bluetooth device in Dell laptops.

[Ben Collins]

On Thu, 2007-05-24 at 19:02 +0200, Marcel Holtmann wrote:
> Hi Ben,
> 
> > CC: Marcel Holtmann <[EMAIL PROTECTED]>
> > CC: Maxim Krasnyansky <[EMAIL PROTECTED]>
> > Signed-off-by: Tim Gardner <[EMAIL PROTECTED]>
> > Signed-off-by: Phillip lougher <[EMAIL PROTECTED]>
> > Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
> > ---
> >  drivers/bluetooth/hci_usb.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
> > index b0238b4..d636142 100644
> > --- a/drivers/bluetooth/hci_usb.c
> > +++ b/drivers/bluetooth/hci_usb.c
> > @@ -131,7 +131,7 @@ static struct usb_device_id blacklist_ids[] = {
> > { USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
> >  
> > /* Dell laptop with Broadcom chip */
> > -   { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
> > +   { USB_DEVICE(0x413c, 0x8126), .driver_info = 
> > HCI_WRONG_SCO_MTU|HCI_RESET },
> >  
> > /* Microsoft Wireless Transceiver for Bluetooth 2.0 */
> > { USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
> 
> it is already in my tree.
> 
> Regards

Great, thanks Marcel.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Ben Collins]

On Wed, 2007-05-23 at 20:59 -0700, Phil Dibowitz wrote:
> Ben Collins wrote:
> > Various unusual dev entries accumulated from Ubuntu bug reports.
> > 
> > CC: Phil Dibowitz <[EMAIL PROTECTED]>
> 
> NACK. Two fixes I'd like to see fixed.
> 
> > +/* SanDisk that has a second LUN for a driver ISO, reported by
> > + * Ben Collins <[EMAIL PROTECTED]> */
> > +UNUSUAL_DEV( 0x0781, 0x5406, 0x, 0x,
> 
> Please use specific device IDs unless you have reason to believe the range
> as a whole is affected (or large portions at least)

Unfortunately, I don't have this device anymore. I based it on an
existing entry, so mislead myself there.

> > +/* Reported by Edward Chapman <[EMAIL PROTECTED]>
> > +   Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */
> > +UNUSUAL_DEV( 0x0dd8, 0xd202, 0x, 0x,
> 
> Same here.

This one I snatched off a mailing list archive somewhere. Was reported
to fix a bug reported to us. However, it is so old I can't find any
information on the bug submitters original USB ids.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] PM: Do not require dev spew to get PM_DEBUG

[Ben Collins]

In order to enable things like PM_TRACE, you're required to enable
PM_DEBUG, which sends a large spew of messages on boot, and often times
can overflow dmesg buffer.

Create new PM_VERBOSE and shift that to be the option that enables
drivers/base/power's messages.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/base/power/Makefile |2 +-
 kernel/power/Kconfig|   17 -
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 91f2309..704d326 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -5,6 +5,6 @@ obj-$(CONFIG_PM_TRACE)  += trace.o
 ifeq ($(CONFIG_DEBUG_DRIVER),y)
 EXTRA_CFLAGS += -DDEBUG
 endif
-ifeq ($(CONFIG_PM_DEBUG),y)
+ifeq ($(CONFIG_PM_VERBOSE),y)
 EXTRA_CFLAGS += -DDEBUG
 endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 495b7d4..1f8cdbd 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -33,13 +33,20 @@ config PM_DEBUG
bool "Power Management Debug Support"
depends on PM
---help---
-   This option enables verbose debugging support in the Power Management
-   code. This is helpful when debugging and reporting various PM bugs, 
-   like suspend support.
+   This option enables various debugging support in the Power Management
+   code. This is helpful when debugging and reporting PM bugs, like
+   suspend support.
+
+config PM_VERBOSE
+   bool "Verbose Power Management debugging"
+   depends on PM_DEBUG
+   default n
+   ---help---
+   This option enables verbose messages from the Power Management code.
 
 config DISABLE_CONSOLE_SUSPEND
bool "Keep console(s) enabled during suspend/resume (DANGEROUS)"
-   depends on PM && PM_DEBUG
+   depends on PM_DEBUG
default n
---help---
This option turns off the console suspend mechanism that prevents
@@ -50,7 +57,7 @@ config DISABLE_CONSOLE_SUSPEND
 
 config PM_TRACE
bool "Suspend/resume event tracing"
-   depends on PM && PM_DEBUG && X86_32 && EXPERIMENTAL
+   depends on PM_DEBUG && X86_32 && EXPERIMENTAL
default n
---help---
This enables some cheesy code to save the last PM event point in the
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[Ben Collins]

This work around has been in use by almost any distribution trying to
support sparc64 since at least 2002. Without it, sunhme hangs fairly
quickly on UltraSPARC 1's.

Dave, I know it's not in the kernel because it isn't a "fix", but given
that we haven't seen a fix in more than 5 years, can we get this out of my
tree please? :)

CC: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/net/sunhme.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
index 51c3fe2..5753298 100644
--- a/drivers/net/sunhme.c
+++ b/drivers/net/sunhme.c
@@ -1969,6 +1969,7 @@ static void happy_meal_tx(struct happy_meal *hp)
}
hp->tx_old = elem;
TXD((">"));
+   udelay(1);
 
if (netif_queue_stopped(dev) &&
TX_BUFFS_AVAIL(hp) > (MAX_SKB_FRAGS + 1))
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[Ben Collins]

On Wed, 2007-05-23 at 17:17 -0700, David Miller wrote:
> From: Ben Collins <[EMAIL PROTECTED]>
> Date: Wed, 23 May 2007 18:30:46 -0400
> 
> > This work around has been in use by almost any distribution trying to
> > support sparc64 since at least 2002. Without it, sunhme hangs fairly
> > quickly on UltraSPARC 1's.
> > 
> > Dave, I know it's not in the kernel because it isn't a "fix", but given
> > that we haven't seen a fix in more than 5 years, can we get this out of my
> > tree please? :)
> 
> It isn't needed any more, the hang no longer occurs.
> 
> Nobody should be applying that patch, my guess is that it was
> a GCC bug that has been fixed over time that reordered the
> writes to RX/TX descriptors which hung the chip.

Ah, thanks. I'll revert it out. Seemed like every time I yanked it out
of the our tree (Debian/Ubuntu) some one would complain, and I had to
put it back in.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] HCIUSB: Initialize the Broadcom USB Bluetooth device in Dell laptops.

[Ben Collins]

CC: Marcel Holtmann <[EMAIL PROTECTED]>
CC: Maxim Krasnyansky <[EMAIL PROTECTED]>
Signed-off-by: Tim Gardner <[EMAIL PROTECTED]>
Signed-off-by: Phillip lougher <[EMAIL PROTECTED]>
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/bluetooth/hci_usb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index b0238b4..d636142 100644
--- a/drivers/bluetooth/hci_usb.c
+++ b/drivers/bluetooth/hci_usb.c
@@ -131,7 +131,7 @@ static struct usb_device_id blacklist_ids[] = {
{ USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
 
/* Dell laptop with Broadcom chip */
-   { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
+   { USB_DEVICE(0x413c, 0x8126), .driver_info = 
HCI_WRONG_SCO_MTU|HCI_RESET },
 
/* Microsoft Wireless Transceiver for Bluetooth 2.0 */
{ USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Ben Collins]

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/char/rtc.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
index 20380a2..22cf7aa 100644
--- a/drivers/char/rtc.c
+++ b/drivers/char/rtc.c
@@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
 
spin_unlock_irq(&rtc_lock);
 
-   printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
+   if (printk_ratelimit())
+   printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", 
freq);
 
/* Now we have new data */
wake_up_interruptible(&rtc_wait);
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 arch/i386/Kconfig.debug|6 ++
 arch/i386/boot/compressed/misc.c   |8 +---
 arch/x86_64/Kconfig.debug  |6 ++
 arch/x86_64/boot/compressed/misc.c |8 +---
 4 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/i386/Kconfig.debug b/arch/i386/Kconfig.debug
index b31c080..eb26441 100644
--- a/arch/i386/Kconfig.debug
+++ b/arch/i386/Kconfig.debug
@@ -19,6 +19,12 @@ config EARLY_PRINTK
  with klogd/syslogd or the X server. You should normally N here,
  unless you want to debug such a crash.
 
+config WRAPPER_PRINT
+   bool "Boot wrapper print" if EMBEDDED
+   default y
+   help
+ Enable informational output from the bootwrapper (bzImage and zImage).
+
 config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
diff --git a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
index b28505c..cc630d5 100644
--- a/arch/i386/boot/compressed/misc.c
+++ b/arch/i386/boot/compressed/misc.c
@@ -184,8 +184,6 @@ static void free(void *where);
 static void *memset(void *s, int c, unsigned n);
 static void *memcpy(void *dest, const void *src, unsigned n);
 
-static void putstr(const char *);
-
 static unsigned long free_mem_ptr;
 static unsigned long free_mem_end_ptr;
 
@@ -232,7 +230,8 @@ static void gzip_release(void **ptr)
 {
free_mem_ptr = (unsigned long) *ptr;
 }
- 
+
+#ifdef CONFIG_WRAPPER_PRINT 
 static void scroll(void)
 {
int i;
@@ -278,6 +277,9 @@ static void putstr(const char *s)
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
 }
+#else
+#define putstr(__x) do{}while(0)
+#endif /* CONFIG_WRAPPER_PRINT */
 
 static void* memset(void* s, int c, unsigned n)
 {
diff --git a/arch/x86_64/Kconfig.debug b/arch/x86_64/Kconfig.debug
index 775d211..a1b87b8 100644
--- a/arch/x86_64/Kconfig.debug
+++ b/arch/x86_64/Kconfig.debug
@@ -6,6 +6,12 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+config WRAPPER_PRINT
+   bool "Boot wrapper print" if EMBEDDED
+   default y
+   help
+ Enable informational output from the bootwrapper (bzImage and zImage).
+
 config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
diff --git a/arch/x86_64/boot/compressed/misc.c 
b/arch/x86_64/boot/compressed/misc.c
index f932b0e..43bb44c 100644
--- a/arch/x86_64/boot/compressed/misc.c
+++ b/arch/x86_64/boot/compressed/misc.c
@@ -184,8 +184,6 @@ static void free(void *where);
 static void *memset(void *s, int c, unsigned n);
 static void *memcpy(void *dest, const void *src, unsigned n);
 
-static void putstr(const char *);
-
 static long free_mem_ptr;
 static long free_mem_end_ptr;
 
@@ -228,7 +226,8 @@ static void gzip_release(void **ptr)
 {
free_mem_ptr = (long) *ptr;
 }
- 
+
+#ifdef CONFIG_WRAPPER_PRINT 
 static void scroll(void)
 {
int i;
@@ -274,6 +273,9 @@ static void putstr(const char *s)
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
 }
+#else
+#define putstr(__x) do{}while(0)
+#endif /* CONFIG_WRAPPER_PRINT */
 
 static void* memset(void* s, int c, unsigned n)
 {
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Ben Collins]

Various unusual dev entries accumulated from Ubuntu bug reports.

CC: Phil Dibowitz <[EMAIL PROTECTED]>
CC: Alan Stern <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/usb/storage/unusual_devs.h |   21 +++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index d230ee7..8a24f1c 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1179,8 +1179,8 @@ UNUSUAL_DEV( 0x0a17, 0x006, 0x, 0x,
 US_SC_DEVICE, US_PR_DEVICE, NULL,
 US_FL_FIX_INQUIRY ),
 
-/* These are virtual windows driver CDs, which the zd1211rw driver 
automatically
- * converts into a WLAN devices. */
+/* These are virtual windows driver CDs, which the zd1211rw driver
+ * automatically converts into WLAN devices. */
 UNUSUAL_DEV( 0x0ace, 0x2011, 0x0101, 0x0101,
 "ZyXEL",
 "G-220F USB-WLAN Install",
@@ -1193,6 +1193,14 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_IGNORE_DEVICE ),
 
+/* SanDisk that has a second LUN for a driver ISO, reported by
+ * Ben Collins <[EMAIL PROTECTED]> */
+UNUSUAL_DEV( 0x0781, 0x5406, 0x, 0x,
+   "SanDisk",
+   "U3 Cruzer Micro driver ISO",
+   US_SC_DEVICE, US_PR_DEVICE, NULL,
+   US_FL_SINGLE_LUN ),
+
 #ifdef CONFIG_USB_STORAGE_ISD200
 UNUSUAL_DEV(  0x0bf6, 0xa001, 0x0100, 0x0110,
"ATI",
@@ -1271,6 +1279,15 @@ UNUSUAL_DEV( 0x0dd8, 0x1060, 0x, 0x,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
 
+/* Reported by Edward Chapman <[EMAIL PROTECTED]>
+   Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */
+UNUSUAL_DEV( 0x0dd8, 0xd202, 0x, 0x,
+   "Netac",
+   "USB Flash Disk",
+   US_SC_DEVICE, US_PR_DEVICE, NULL,
+   US_FL_IGNORE_RESIDUE ),
+
+
 /* Patch by Stephan Walter <[EMAIL PROTECTED]>
  * I don't know why, but it works... */
 UNUSUAL_DEV( 0x0dda, 0x0001, 0x0012, 0x0012,
-- 
1.5.1.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] Patch sync from Ubuntu tree

[Ben Collins]

Patch set to sync up some Ubuntu patches.

Git tree: git://kernel.ubuntu.com/bcollins/ubuntu-for-upstream
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/REDIFF] Cleanup libata HPA support

[Ben Collins]

On Fri, 2007-05-18 at 11:06 -0400, Ben Collins wrote:
> (Rediffed against latest git)

Added error check for ata_dev_read_id (Thanks tj)

Also, since hpa is disabled by default, print the native size, even when
HPA isn't asked for (so users and developers can know that it may need
to be used).

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d3ea7f5..3c8eb77 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -814,16 +814,19 @@ void ata_id_c_string(const u16 *id, unsigned char *s,
 
 static u64 ata_tf_to_lba48(struct ata_taskfile *tf)
 {
-   u64 sectors = 0;
+   u64 sectors;
+   u32 high, low;
 
-   sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
-   sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
-   sectors |= (tf->hob_lbal & 0xff) << 24;
-   sectors |= (tf->lbah & 0xff) << 16;
-   sectors |= (tf->lbam & 0xff) << 8;
-   sectors |= (tf->lbal & 0xff);
+   high = (tf->hob_lbah << 16) |
+  (tf->hob_lbam <<  8) |
+   tf->hob_lbal;
+   low  = (tf->lbah << 16) |
+  (tf->lbam <<  8) |
+   tf->lbal;
 
-   return ++sectors;
+   sectors = ((u64)high << 24) | low;
+
+   return sectors + 1;
 }
 
 static u64 ata_tf_to_lba(struct ata_taskfile *tf)
@@ -965,52 +968,107 @@ static u64 ata_set_native_max_address(struct ata_device 
*dev, u64 new_sectors)
 }
 
 /**
+ * ata_hpa_get_native_size -   Get the native size of a disk
+ * @dev: Device to get the size for
+ *
+ * Read the size of an LBA28 or LBA48 disk with HPA features and
+ * return the native size. Caller must check that the drive has HPA
+ * feature set enabled.
+ */
+static u64 ata_hpa_get_native_size(struct ata_device *dev)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_read_native_max_address_ext(dev);
+   else
+   return ata_read_native_max_address(dev);
+}
+
+
+static u64 ata_hpa_set_native_size(struct ata_device *dev, u64 new_sectors)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_set_native_max_address_ext(dev, new_sectors);
+   else
+   return ata_set_native_max_address(dev, new_sectors);
+}
+
+static unsigned long long sectors_to_MB(unsigned long long n)
+{
+   n <<= 9;/* make it bytes */
+   do_div(n, 100); /* make it MB */
+   return n;
+}
+
+static u64 ata_id_n_sectors(const u16 *id);
+
+/**
  * ata_hpa_resize  -   Resize a device with an HPA set
  * @dev: Device to resize
  *
  * Read the size of an LBA28 or LBA48 disk with HPA features and resize
- * it if required to the full size of the media. The caller must check
- * the drive has the HPA feature set enabled.
+ * it if required to the full size of the media.
  */
 
-static u64 ata_hpa_resize(struct ata_device *dev)
+static int ata_hpa_resize(struct ata_device *dev)
 {
-   u64 sectors = dev->n_sectors;
u64 hpa_sectors;
+
+   if (!ata_id_hpa_enabled(dev->id))
+   return 0;
+
+   hpa_sectors = ata_hpa_get_native_size(dev);

-   if (ata_id_has_lba48(dev->id))
-   hpa_sectors = ata_read_native_max_address_ext(dev);
-   else
-   hpa_sectors = ata_read_native_max_address(dev);
+   ata_dev_printk(dev, KERN_INFO, "%s: sectors = %lld, hpa_sectors = 
%lld\n",
+   __FUNCTION__, dev->n_sectors, hpa_sectors);
 
-   /* if no hpa, both should be equal */
-   ata_dev_printk(dev, KERN_INFO, "%s 1: sectors = %lld, "
-   "hpa_sectors = %lld\n",
-   __FUNCTION__, (long long)sectors, (long long)hpa_sectors);
+   if (ata_ignore_hpa && hpa_sectors > dev->n_sectors) {
+   u64 ret_sectors;
 
-   if (hpa_sectors > sectors) {
ata_dev_printk(dev, KERN_INFO,
-   "Host Protected Area detected:\n"
-   "\tcurrent size: %lld sectors\n"
-   "\tnative size: %lld sectors\n",
-   (long long)sectors, (long long)hpa_sectors);
-
-   if (ata_ignore_hpa) {
-   if (ata_id_has_lba48(dev->id))
-   hpa_sectors = 
ata_set_native_max_address_ext(dev, hpa_sectors);
-   else
-   hpa_sectors = ata_set_native_max_address(dev,
-   hpa_sectors);
-
-   if (hpa_sectors) {
-   ata_dev_printk(dev, KERN_INFO, "native size "
-   "increased to %lld sectors\n",
-   

[PATCH/REDIFF] Cleanup libata HPA support

[Ben Collins]

(Rediffed against latest git)

The original HPA patch that Kyle worked on has gone into current git
without some fixes that we worked through late in the Ubuntu feisty
release. Here's the main copy of the notes I sent to Alan a few weeks
ago in regards to the original patch, and a repatch against current git
to fix things up. Note we have released feisty with the patch attached
(albeit we have HPA enabled by default), and we have not had any reports
directly attributed to it. However, in gutsy (devel for next release,
based on current stock linux-2.6.git), we are already seeing reports of
the same issues we already fixed. 

The issues we saw were mainly that some controllers didn't return the
correct size from the SET_MAX command (sata_nv is a good example). So I
added a re IDENTIFY after the SET_MAX, and compared all the numbers. If
re-id was correct, but return value from SET_MAX wasn't we print a
warning and use the IDENTIFY value regardless (since that's what the
device is going to use).

ata_hpa_resize() was changed to handle everything in a single call (checks
for HPA support of the device, and whether ignore_hpa is set or not), and
it also sets dev->n_sectors before returning.

So far with this patch, we were able to fix all the problems we were
seeing with it (except the sata_nv issue where we had to revert to not
using adma for NO_DATA transactions, already reported to libata-dev).
We've not had any reports of further problems.

CC: Kyle McMartin <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

 libata-core.c |  134 --
 1 file changed, 93 insertions(+), 41 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d3ea7f5..9a6962b 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -814,16 +814,19 @@ void ata_id_c_string(const u16 *id, unsigned char *s,
 
 static u64 ata_tf_to_lba48(struct ata_taskfile *tf)
 {
-   u64 sectors = 0;
+   u64 sectors;
+   u32 high, low;
 
-   sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
-   sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
-   sectors |= (tf->hob_lbal & 0xff) << 24;
-   sectors |= (tf->lbah & 0xff) << 16;
-   sectors |= (tf->lbam & 0xff) << 8;
-   sectors |= (tf->lbal & 0xff);
+   high = (tf->hob_lbah << 16) |
+  (tf->hob_lbam <<  8) |
+   tf->hob_lbal;
+   low  = (tf->lbah << 16) |
+  (tf->lbam <<  8) |
+   tf->lbal;
 
-   return ++sectors;
+   sectors = ((u64)high << 24) | low;
+
+   return sectors + 1;
 }
 
 static u64 ata_tf_to_lba(struct ata_taskfile *tf)
@@ -965,52 +968,101 @@ static u64 ata_set_native_max_address(struct ata_device 
*dev, u64 new_sectors)
 }
 
 /**
+ * ata_hpa_get_native_size -   Get the native size of a disk
+ * @dev: Device to get the size for
+ *
+ * Read the size of an LBA28 or LBA48 disk with HPA features and
+ * return the native size. Caller must check that the drive has HPA
+ * feature set enabled.
+ */
+static u64 ata_hpa_get_native_size(struct ata_device *dev)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_read_native_max_address_ext(dev);
+   else
+   return ata_read_native_max_address(dev);
+}
+
+
+static u64 ata_hpa_set_native_size(struct ata_device *dev, u64 new_sectors)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_set_native_max_address_ext(dev, new_sectors);
+   else
+   return ata_set_native_max_address(dev, new_sectors);
+}
+
+static unsigned long long sectors_to_MB(unsigned long long n)
+{
+   n <<= 9;/* make it bytes */
+   do_div(n, 100); /* make it MB */
+   return n;
+}
+
+static u64 ata_id_n_sectors(const u16 *id);
+
+/**
  * ata_hpa_resize  -   Resize a device with an HPA set
  * @dev: Device to resize
  *
  * Read the size of an LBA28 or LBA48 disk with HPA features and resize
- * it if required to the full size of the media. The caller must check
- * the drive has the HPA feature set enabled.
+ * it if required to the full size of the media.
  */
 
-static u64 ata_hpa_resize(struct ata_device *dev)
+static void ata_hpa_resize(struct ata_device *dev)
 {
-   u64 sectors = dev->n_sectors;
u64 hpa_sectors;
-   
-   if (ata_id_has_lba48(dev->id))
-   hpa_sectors = ata_read_native_max_address_ext(dev);
-   else
-   hpa_sectors = ata_read_native_max_address(dev);
 
+   if (!ata_id_hpa_enabled(dev->id) || !ata_ignore_hpa)
+   return;
+
+   hpa_sectors = ata_hpa_get_nat

Re: [linux-usb-devel] [PATCH] Remove duplicate ID in ipaq driver

[Ben Collins]

On Thu, 2007-05-17 at 05:43 -0700, Greg KH wrote:
> On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
> > On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
> > > > /* The first entry is a placeholder for the insmod-specified 
> > > > device */
> > >  > -  { USB_DEVICE(0x049F, 0x0003) },
> > > 
> > > Is it obvious why this patch is correct?  Especially given the
> > > comment just before the line you delete, and the code
> > > 
> > >   if (vendor) {
> > >   ipaq_id_table[0].idVendor = vendor;
> > >   ipaq_id_table[0].idProduct = product;
> > >   }
> > > 
> > > in ipaq_init()?
> > 
> > My mistake, quick on the patching going through this dupe list.
> > 
> > Might I add that this is terrible use of the device table, though.
> > Clutters userspace, and adds processing to module-init-tools programs.
> 
> It's a hold-over from the times when we didn't have the sysfs "add a new
> id" interface for usb-serial drivers, which only recently was created.
> 
> So we just have to live with it, and the infinitesimal speed hit it
> creates :)

Any objection to adding it to planned-for-removal and spitting out a
printk when someone uses the "feature"?

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove duplicate ID in ipaq driver

[Ben Collins]

On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
> > /* The first entry is a placeholder for the insmod-specified device */
>  > -  { USB_DEVICE(0x049F, 0x0003) },
> 
> Is it obvious why this patch is correct?  Especially given the
> comment just before the line you delete, and the code
> 
>   if (vendor) {
>   ipaq_id_table[0].idVendor = vendor;
>   ipaq_id_table[0].idProduct = product;
>   }
> 
> in ipaq_init()?

My mistake, quick on the patching going through this dupe list.

Might I add that this is terrible use of the device table, though.
Clutters userspace, and adds processing to module-init-tools programs.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Remove duplicate ID in ipaq driver

[Ben Collins]

Cc: Ganesh Varadarajan <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index 4df0ec7..7c85be4 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -92,7 +92,6 @@ static void ipaq_destroy_lists(struct usb_serial_port *port);
 
 static struct usb_device_id ipaq_id_table [] = {
/* The first entry is a placeholder for the insmod-specified device */
-   { USB_DEVICE(0x049F, 0x0003) },
{ USB_DEVICE(0x0104, 0x00BE) }, /* Socket USB Sync */
{ USB_DEVICE(0x03F0, 0x1016) }, /* HP USB Sync */
{ USB_DEVICE(0x03F0, 0x1116) }, /* HP USB Sync 1611 */

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Remove duplicate IDs from option card driver

[Ben Collins]

Cc: Matthias Urlichs <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8c3f55b..89f067d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -165,7 +165,6 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1410) }, /* Novatel U740 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1420) }, /* Novatel EU870 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1430) }, /* Novatel Merlin 
XU870 HSDPA/3G */
-   { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1430) }, /* Novatel XU870 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2100) }, /* Novatel EV620 
CDMA/EV-DO */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2110) }, /* Novatel Merlin 
ES620 / Merlin ES720 / Ovation U720 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2130) }, /* Novatel Merlin 
ES620 SM Bus */


-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Avoid zero size allocation in cache_k8_northbridges()

[Ben Collins]

kmalloc for flush_words resulted in zero size allocation when no
k8_northbridges existed. Short circuit the code path for this case.

Also remove uneeded zeroing of num_k8_northbridges just after checking
if it is zero.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/arch/x86_64/kernel/k8.c b/arch/x86_64/kernel/k8.c
index bc11b32..7377ccb 100644
--- a/arch/x86_64/kernel/k8.c
+++ b/arch/x86_64/kernel/k8.c
@@ -39,10 +39,10 @@ int cache_k8_northbridges(void)
 {
int i;
struct pci_dev *dev;
+
if (num_k8_northbridges)
return 0;
 
-   num_k8_northbridges = 0;
dev = NULL;
while ((dev = next_k8_northbridge(dev)) != NULL)
num_k8_northbridges++;
@@ -52,6 +52,11 @@ int cache_k8_northbridges(void)
if (!k8_northbridges)
return -ENOMEM;
 
+   if (!num_k8_northbridges) {
+   k8_northbridges[0] = NULL;
+   return 0;
+   }
+
flush_words = kmalloc(num_k8_northbridges * sizeof(u32), GFP_KERNEL);
if (!flush_words) {
kfree(k8_northbridges);


-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cleanup libata HPA support

[Ben Collins]

On Wed, 2007-05-09 at 17:27 -0600, Robert Hancock wrote:
> Ben Collins wrote:
> > On Tue, 2007-05-08 at 08:46 -0600, Robert Hancock wrote:
> >> Ben Collins wrote:
> >>> The original HPA patch that Kyle worked on has gone into current git
> >>> without some fixes that we worked through late in the Ubuntu feisty
> >>> release. Here's the main copy of the notes I sent to Alan a few weeks
> >>> ago in regards to the original patch, and a repatch against current git
> >>> to fix things up. Note we have released feisty with the patch attached
> >>> (albeit we have HPA enabled by default), and we have not had any reports
> >>> directly attributed to it. However, in gutsy (devel for next release,
> >>> based on current stock linux-2.6.git), we are already seeing reports of
> >>> the same issues we already fixed. 
> >>>
> >>> The issues we saw were mainly that some controllers didn't return the
> >>> correct size from the SET_MAX command (sata_nv is a good example). So I
> >>> added a re IDENTIFY after the SET_MAX, and compared all the numbers. If
> >>> re-id was correct, but return value from SET_MAX wasn't we print a
> >>> warning and use the IDENTIFY value regardless (since that's what the
> >>> device is going to use).
> >>>
> >>> Because we re IDENTIFY, there was also no need to keep n_sectors_boot
> >>> around, so that was removed. The ata_hpa_resize() was changed to handle
> >>> everything in a single call (checks for HPA support of the device, and
> >>> whether ignore_hpa is set or not), and it also sets dev->n_sectors
> >>> before returning.
> >>>
> >>> So far with this patch, we were able to fix all the problems we were
> >>> seeing with it (except the sata_nv issue where we had to revert to not
> >>> using adma for NO_DATA transactions, already reported to libata-dev).
> >>> We've not had any reports of further problems.
> >> That sata_nv issue should not be present anymore in the current 
> >> libata-dev tree.
> > 
> > That's correct, it is not, at least the machine exception problem isn't.
> > However, the incorrect returns from SET_MAX are still an issue with that
> > hw. No idea what is causing it.
> 
> Curious.. Do you have some output or other details from what was 
> actually returned? Also was this on more than one drive model?

I no longer have these outputs handy, although a bug report on
launchpad.net might have it (linux-source-2.6.20 package).

It was an abnormally huge value (hence the exposed signed extension
problems I fixed). The incorrect value was always the same for the same
controller/drive pair. It was not specific to a drive model, only
sata_nv (and I think pata_amd) was common to these cases.

Due to the extreme proximity of this bug being exposed to our release
deadline, we did not investigate the absolute cause of the issue, just
implemented a safer HPA detection to avoid them. If you have a sata_nv,
it is easy to get these values even with my patch since it outputs a
warning with the incorrect read back from SET_MAX. So the problems wont
go unnoticed.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cleanup libata HPA support

[Ben Collins]

On Tue, 2007-05-08 at 08:46 -0600, Robert Hancock wrote:
> Ben Collins wrote:
> > The original HPA patch that Kyle worked on has gone into current git
> > without some fixes that we worked through late in the Ubuntu feisty
> > release. Here's the main copy of the notes I sent to Alan a few weeks
> > ago in regards to the original patch, and a repatch against current git
> > to fix things up. Note we have released feisty with the patch attached
> > (albeit we have HPA enabled by default), and we have not had any reports
> > directly attributed to it. However, in gutsy (devel for next release,
> > based on current stock linux-2.6.git), we are already seeing reports of
> > the same issues we already fixed. 
> > 
> > The issues we saw were mainly that some controllers didn't return the
> > correct size from the SET_MAX command (sata_nv is a good example). So I
> > added a re IDENTIFY after the SET_MAX, and compared all the numbers. If
> > re-id was correct, but return value from SET_MAX wasn't we print a
> > warning and use the IDENTIFY value regardless (since that's what the
> > device is going to use).
> > 
> > Because we re IDENTIFY, there was also no need to keep n_sectors_boot
> > around, so that was removed. The ata_hpa_resize() was changed to handle
> > everything in a single call (checks for HPA support of the device, and
> > whether ignore_hpa is set or not), and it also sets dev->n_sectors
> > before returning.
> > 
> > So far with this patch, we were able to fix all the problems we were
> > seeing with it (except the sata_nv issue where we had to revert to not
> > using adma for NO_DATA transactions, already reported to libata-dev).
> > We've not had any reports of further problems.
> 
> That sata_nv issue should not be present anymore in the current 
> libata-dev tree.

That's correct, it is not, at least the machine exception problem isn't.
However, the incorrect returns from SET_MAX are still an issue with that
hw. No idea what is causing it.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cleanup libata HPA support

[Ben Collins]

On Tue, 2007-05-08 at 09:44 -0400, Mark Lord wrote:
> Ben Collins wrote:
> ..
> >  static u64 ata_tf_to_lba48(struct ata_taskfile *tf)
> >  {
> > -   u64 sectors = 0;
> > +   u64 sectors;
> > +   u32 high, low;
> >  
> > -   sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
> > -   sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
> > -   sectors |= (tf->hob_lbal & 0xff) << 24;
> > -   sectors |= (tf->lbah & 0xff) << 16;
> > -   sectors |= (tf->lbam & 0xff) << 8;
> > -   sectors |= (tf->lbal & 0xff);
> > +   high = (tf->hob_lbah << 16) |
> > +  (tf->hob_lbam <<  8) |
> > +   tf->hob_lbal;
> > +   low  = (tf->lbah << 16) |
> > +  (tf->lbam <<  8) |
> > +   tf->lbal;
> >  
> > -   return ++sectors;
> > +   sectors = ((u64)high << 24) | low;
> > +
> > +   return sectors + 1;
> >  }
> 
> Ben, I very much prefer the fixed version of this function
> as implemented by the patch above.
> 
> But.. is the original code actually broken, or just messy?

Due to the bugs we were seeing, we actually noticed that this function
was having signed extension issues as originally implemented. I didn't
look for the actual bug, but reimplemented it based on code in
ide_disk.c, which resolved the issue.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Cleanup libata HPA support

[Ben Collins]

The original HPA patch that Kyle worked on has gone into current git
without some fixes that we worked through late in the Ubuntu feisty
release. Here's the main copy of the notes I sent to Alan a few weeks
ago in regards to the original patch, and a repatch against current git
to fix things up. Note we have released feisty with the patch attached
(albeit we have HPA enabled by default), and we have not had any reports
directly attributed to it. However, in gutsy (devel for next release,
based on current stock linux-2.6.git), we are already seeing reports of
the same issues we already fixed. 

The issues we saw were mainly that some controllers didn't return the
correct size from the SET_MAX command (sata_nv is a good example). So I
added a re IDENTIFY after the SET_MAX, and compared all the numbers. If
re-id was correct, but return value from SET_MAX wasn't we print a
warning and use the IDENTIFY value regardless (since that's what the
device is going to use).

Because we re IDENTIFY, there was also no need to keep n_sectors_boot
around, so that was removed. The ata_hpa_resize() was changed to handle
everything in a single call (checks for HPA support of the device, and
whether ignore_hpa is set or not), and it also sets dev->n_sectors
before returning.

So far with this patch, we were able to fix all the problems we were
seeing with it (except the sata_nv issue where we had to revert to not
using adma for NO_DATA transactions, already reported to libata-dev).
We've not had any reports of further problems.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
CC: Kyle McMartin <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index ca67484..253b969 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -814,16 +814,19 @@ void ata_id_c_string(const u16 *id, unsigned char *s,
 
 static u64 ata_tf_to_lba48(struct ata_taskfile *tf)
 {
-   u64 sectors = 0;
+   u64 sectors;
+   u32 high, low;
 
-   sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
-   sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
-   sectors |= (tf->hob_lbal & 0xff) << 24;
-   sectors |= (tf->lbah & 0xff) << 16;
-   sectors |= (tf->lbam & 0xff) << 8;
-   sectors |= (tf->lbal & 0xff);
+   high = (tf->hob_lbah << 16) |
+  (tf->hob_lbam <<  8) |
+   tf->hob_lbal;
+   low  = (tf->lbah << 16) |
+  (tf->lbam <<  8) |
+   tf->lbal;
 
-   return ++sectors;
+   sectors = ((u64)high << 24) | low;
+
+   return sectors + 1;
 }
 
 static u64 ata_tf_to_lba(struct ata_taskfile *tf)
@@ -963,52 +966,101 @@ static u64 ata_set_native_max_address(struct ata_device 
*dev, u64 new_sectors)
 }
 
 /**
+ * ata_hpa_get_native_size -   Get the native size of a disk
+ * @dev: Device to get the size for
+ *
+ * Read the size of an LBA28 or LBA48 disk with HPA features and
+ * return the native size. Caller must check that the drive has HPA
+ * feature set enabled.
+ */
+static u64 ata_hpa_get_native_size(struct ata_device *dev)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_read_native_max_address_ext(dev);
+   else
+   return ata_read_native_max_address(dev);
+}
+
+
+static u64 ata_hpa_set_native_size(struct ata_device *dev, u64 new_sectors)
+{
+   if (ata_id_has_lba48(dev->id))
+   return ata_set_native_max_address_ext(dev, new_sectors);
+   else
+   return ata_set_native_max_address(dev, new_sectors);
+}
+
+static unsigned long long sectors_to_MB(unsigned long long n)
+{
+   n <<= 9;/* make it bytes */
+   do_div(n, 100); /* make it MB */
+   return n;
+}
+
+static u64 ata_id_n_sectors(const u16 *id);
+
+/**
  * ata_hpa_resize  -   Resize a device with an HPA set
  * @dev: Device to resize
  *
  * Read the size of an LBA28 or LBA48 disk with HPA features and resize
- * it if required to the full size of the media. The caller must check
- * the drive has the HPA feature set enabled.
+ * it if required to the full size of the media.
  */
 
-static u64 ata_hpa_resize(struct ata_device *dev)
+static void ata_hpa_resize(struct ata_device *dev)
 {
-   u64 sectors = dev->n_sectors;
u64 hpa_sectors;
-   
-   if (ata_id_has_lba48(dev->id))
-   hpa_sectors = ata_read_native_max_address_ext(dev);
-   else
-   hpa_sectors = ata_read_native_max_address(dev);
 
+   if (!ata_id_hpa_enabled(dev->id) || !ata_ignore_hpa)
+   return;
+
+   hpa_sectors = ata_hpa_get_native_size(dev);
+   
/* if no hpa, both should be equal */
-   ata_dev_printk(dev, KERN_INFO, "%s 1: 

Re: Kernel 2.6.20+ and rt2500/rt2570 problem

[Ben Collins]

On Sat, 2007-04-21 at 16:18 +0200, Wiktor Wandachowicz wrote:
> Recently I tried newer releases of Linux distributions, specifically
> Sabayon Linux 3.3 and Ubuntu 7.04. Both suffer from problems with
> rt2500/rt2570 modules not being able to associate with access points.
> There are numerous problems reported Ubuntu Launchpad, Gentoo Forums
> and Sabayon Forums.
> 
> Please, Linux kernel developers, try to help out the guys at:
> http://rt2x00.serialmonkey.com/
> 
> They look pretty clueless and don't know exactly what to do.
> It seems that advances in kernel to Wireless Extensions 19 broke
> their efforts somewhat.
> 
> If possible, speed up the inclusion process of the driver into mainline
> kernel, so users won't have to be forced to do a hardware upgrade.
> Additionally, this problem prevents my machines from being upgraded from
> Ubuntu 6.10 (kernel 2.6.17) to Ubuntu 7.04 (kernel 2.6.20 I believe).


There are two modules in Ubuntu for this chipset, the rt2500 (default)
and rt2500{pci,usb}. You could try blacklisting rt2500 and use
rt2500pci. See if that helps.

-- 
Ubuntu:http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ieee1394: update MAINTAINERS database

[Ben Collins]

On Fri, 2007-04-20 at 23:21 +0200, Stefan Richter wrote:
> - update Ben's address
>   - replace Ben's contact by mine as raw1394's 2nd contact
>   - eth1394's and pcilynx's maintenance doesn't really differ from that
> of other parts of the stack like video1394
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> 
> Ben, is this correct?

Looks good to me.

-- 
Ubuntu:http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line

[Ben Collins]

On Wed, 2007-04-18 at 11:55 -0400, Kyle McMartin wrote:
> With the move to initramfs and heavily modular configs, which include
> loading storage drivers from early userspace, it's becoming harder
> to provide users with a way of overriding module parameters at boot.
> 
> Currently, users would have to break into the initramfs, edit the
> modprobe options, and then let boot continue. They have a much easier time
> dealing with adding options on the command line from Grub or what have you.
> 
> I hacked out this patch quickly to re-parse saved_command_line[] when we
> load a module in an attempt to rectify this.
> 
> (The specific use-case I was looking at here was HPA commands failing on
>  sata_nv controllers, and needing to pass the adma=0 option to the module...
>  Users had a hard time testing without an easy way of overriding the module.)
> 
> Clearly this is not entirely optimal, because we're parsing command_line
> after the module params are parsed. This ends of being a policy decision,
> whether the /sbin/modprobe commandline should override the kernel
> command_line, or vice versa.
> 
> Anyway, please comment...

Just pasting my comments to kyle on IRC for benefit of discussion:

"I'm of the opinion that cmdline args from the kernel should override
modprobe args...mainly because adding those args to the kernel cmdline
is clearly an attempt to override userspace"

"maybe have some sysfs attr to disable this feature, so userspace can go
back to normal after whatever needed fixing"

The use case for us is that we've had to add a couple of initramfs
scripts to parse common module params (all_generic_ide for example).

We'd like to move away from this and have a clear way of passing any
module param on the kernel command line. Workarounds for users are much
easier than having to roll new CDs for every little quirk. Plus it's
easier for testing (if the quirk is a bug that keeps them from
installing at all, then we can't just hand them new kernels very
easily).


-- 
Ubuntu:http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Resume from S2R fails after dpm_resume()

[Ben Collins]

On Fri, 2007-03-02 at 15:39 +0100, Pavel Machek wrote:
> On Fri 2007-03-02 07:25:49, Tim Gardner wrote:
> > Pavel Machek wrote:
> > > Hi!
> > > 
> > >> I instrumented 2.6.21-rc1 base/power/resume.c device_resume() with
> > >> TRACE_RESUME(0) as the last statement in the function. Sure enough it
> > >> was the last hash value in the RTC after a hard reboot when resume 
> > >> failed:
> > >>
> > >> [   12.028820]   hash matches drivers/base/power/resume.c:104
> > >>
> > >> The machine appears to be absolutely wedged after initiating resume by
> > >> pressing the power button. The disk flashes for a half second or so,
> > >> then thats it.
> > >>
> > >> It is a Dell XPS, BIOS rev A04. I'm using 'echo 1 > /sys/power/pm_trace;
> > >> echo mem > /sys/power/state' to initiate the S2R sequence.
> > >>
> > >> Any suggestions on where to go from here?
> > > 
> > > Did it work ok in 2.6.20? Can you try to get video working/get serial
> > > console/something?
> > >   Pavel
> > 
> > Pavel,
> > 
> > The last version that worked well was Ubuntu Edgy (2.6.17). It was
> > broken by 2.6.18. I have not started the 'git bisect' process, instead
> > I've been trying to figure out why it doesn't work in 2.6.21-rc2. Using
> > the TRACE_RESUME macro I've drilled down to
> > kernel/printk.c:__call_console_drivers. So far the last trace info that
> > I have is just before the call to con->write(). I'm trying to figure out
> > what driver has registered as the console (intel_agp or agpgart?).
> > 
> > Am I banging my head on a known problem?
> 
> 2.6.21-rc* is known broken (in more than 1 way). I'd suggest playing
> with 2.6.20.

It's broken for him in 2.6.20 too, which led him to test 2.6.21-rc, and
some vanilla kernels back to 2.6.18. Everything past 2.6.17 is broken
for him.

-- 
Ubuntu:http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: p4-clockmod N60 errata workaround.

[Ben Collins]

On Thu, 2007-02-15 at 10:37 -0600, Oscar Pearce wrote:
> On 10/28/06, Dave Jones <[EMAIL PROTECTED]> wrote:
> Ben,
> For the best part of a year since that N60 errata workaround
> went in, I've had floods of complaints from users of that
> driver
> about this driver becoming even more useless than it was
> before
> "I had 8 frequencies, now I have 2" being the common
> complaint. 
> which was to be expected given that the intention of the
> errata
> workaround was to cripple frequencies <2GHz.

We've since removed that patch from our current tree. It might remain in
some older kernels. I'll definitely check into getting it pulled from
there next update we do for them.

Thanks.

> 
-- 
Ubuntu:http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [FYI] Vendor interest in Unionfs

[Ben Collins]

On Tue, 2007-01-09 at 13:33 +0200, Indrek Kruusa wrote:
>  >> Is there vendor interest in unionfs?
> 
>  > MANY live cds seem to use it
> 
> 
> I'd like to add that also in embedded area (flash storage) the UnionFS 
> helps in some cases.

I'll chime in as well. Ubuntu uses unionfs extensively for our live
CD's. I'd very much like to stop adding this to our kernels myself.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc2: known unfixed regressions

[Ben Collins]

On Thu, 2006-12-28 at 23:39 +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.

> Subject: i386: Oops in __find_get_block()
> References : http://lkml.org/lkml/2006/12/16/138
> Submitter  : Ben Collins <[EMAIL PROTECTED]>
>  Daniel Holbach <[EMAIL PROTECTED]>
> Status : unknown

I believe this is the same bug as I've seen reported about gdb. I'd have
to find the thread/information regarding it. Not sure if it was fixed
already.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-git] sata_svw: Check for errors from ata_device_add()

[Ben Collins]

On Tue, 2006-12-19 at 17:59 -0500, Ben Collins wrote:
> Without this patch, G5 oopses on boot. I've had this in Ubuntu since
> 2.6.17, but I forgot it was in there. Still required with 2.6.20.
> 
> Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

Ignore this patch for now, BenH and I are discussing the issue further.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.20-git] sata_svw: Check for errors from ata_device_add()

[Ben Collins]

Without this patch, G5 oopses on boot. I've had this in Ubuntu since
2.6.17, but I forgot it was in there. Still required with 2.6.20.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
index d89c959..85911b4 100644
--- a/drivers/ata/sata_svw.c
+++ b/drivers/ata/sata_svw.c
@@ -473,11 +473,11 @@ static int k2_sata_init_one (struct pci_
 
pci_set_master(pdev);
 
-   /* FIXME: check ata_device_add return value */
-   ata_device_add(probe_ent);
-   kfree(probe_ent);
+   if (ata_device_add(probe_ent))
+   return 0;
 
-   return 0;
+   /* Failed to add, no device present */
+   rc = -ENODEV;
 
 err_out_free_ent:
kfree(probe_ent);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OOPS: 2.6.20-rc1 in __find_get_block()

[Ben Collins]

This occurred on a X40 (amd64 running x86 kernel) after a few minutes of
uptime. Cc'd Daniel, since he originally reported the bug.

Kernel is SMP, voluntary-preempt.

[  287.328000] invalid opcode:  [#1]
[  287.328000] SMP 
[  287.328000] CPU:0
[  287.328000] EIP:0060:[__find_get_block+376/400]Not tainted VLI
[  287.328000] EFLAGS: 00010046   (2.6.20-1-generic #3)
[  287.328000] EIP is at __find_get_block+0x178/0x190
[  287.328000] eax: 0096   ebx: 1000   ecx: 1000   edx: 00520050
[  287.328000] esi: 00a4   edi: 00520050   ebp: df8c6900   esp: f1f15c78
[  287.328000] ds: 007b   es: 007b   ss: 0068
[  287.328000] Process gcalctool (pid: 5411, ti=f1f14000 task=f2127560 
task.ti=f1f14000)
[  287.328000] Stack: 00520050  0001 0001  0002 
 000280d2 
[  287.328000]c03e2c2c 0246 0040 1000 00a4 00520050 
dfdc0a00 c01957b3 
[  287.328000]1000  c015ae7f 0044 0010 00520050 
 df8c6900 
[  287.328000] Call Trace:
[  287.328000]  [__getblk+35/688] __getblk+0x23/0x2b0
[  287.328000]  [pg0+944672526/1068770304] __ext3_get_inode_loc+0x11e/0x340 
[ext3]
[  287.328000]  [pg0+944673143/1068770304] ext3_reserve_inode_write+0x27/0x80 
[ext3]
[  287.328000]  [pg0+944673267/1068770304] ext3_mark_inode_dirty+0x23/0x50 
[ext3]
[  287.328000]  [pg0+944685961/1068770304] ext3_dirty_inode+0x79/0x90 [ext3]
[  287.328000]  [__mark_inode_dirty+52/400] __mark_inode_dirty+0x34/0x190
[  287.328000]  [__link_path_walk+3074/3696] __link_path_walk+0xc02/0xe70
[  287.328000]  [link_path_walk+69/192] link_path_walk+0x45/0xc0
[  287.328000]  [do_path_lookup+131/448] do_path_lookup+0x83/0x1c0
[  287.328000]  [__path_lookup_intent_open+81/160] 
__path_lookup_intent_open+0x51/0xa0
[  287.328000]  [path_lookup_open+32/48] path_lookup_open+0x20/0x30
[  287.328000]  [open_namei+90/1536] open_namei+0x5a/0x600
[  287.328000]  [do_filp_open+51/96] do_filp_open+0x33/0x60
[  287.328000]  [do_sys_open+78/240] do_sys_open+0x4e/0xf0
[  287.328000]  [sys_open+28/32] sys_open+0x1c/0x20
[  287.328000]  [syscall_call+7/11] syscall_call+0x7/0xb
[  287.328000]  [phys_startup_32+-120961/-1073741824] 0xb7f6bf94
[  287.328000]  ===
[  287.328000] Code: 24 08 e8 ac f4 ff ff e9 20 ff ff ff 89 d8 e8 a0 f4 ff ff 
eb 8b 89 d6 8d 56 ff 8b 04 97 85 d2 89 04 b7 75 f1 89 1f e9 f0 fe ff ff <0f> 0b 
eb fe 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 
[  287.328000] EIP: [__find_get_block+376/400] __find_get_block+0x178/0x190 
SS:ESP 0068:f1f15c78

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 20:29 +0100, Michael Buesch wrote:
> On Thursday 14 December 2006 15:12, Ben Collins wrote:
> > You can't talk about drivers that don't exist for Linux. Things like
> > bcm43xx aren't effected by this new restriction for GPL-only drivers.
> > There's no binary-only driver for it (ndiswrapper doesn't count). If the
> > hardware vendor doesn't want to write a driver for linux, you can't make
> > them. You can buy other hardware, but that's about it.
> 
> Not that is matters in this discussion, but there are binary Broadcom
> 43xx drivers for linux available.
> 
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> > 
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
> 
> Well, that's not just one, right?
> That's like, 10 or so for the different AVM cards.
> I'm just estimating. Correct me, if I'm wrong.

One driver, many variations of the chipset. That's true of most drivers.

> (And if I didn't mention it yet; AVM binary drivers are
> complete crap.)

Wont disagree with you there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 18:21 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 08:46, Ben Collins wrote:
> >I have to agree with your your whole statement. The gradual changes to
> >lock down kernel modules to a particular license(s) tends to mirror the
> >slow lock down of content (music/movies) that people complain about so
> >loudly. It's basically becoming DRM for code.
> >
> >I don't think anyone ever expected technical mechanisms to be developed
> >to enforce the GPL. It's sort of counter intuitive to why the GPL
> >exists, which is to free the code.
> 
> """To protect your rights, we need to make restrictions that forbid
> anyone to deny you these rights"""
> 
> >Let the licenses and lawyers fight to protect the code. The code doesn't
> >need to do that itself. It's got better things to do.

And these restrictions are in the letter of the GPL, not the function
prototypes of my code. Anyone willing to write libgpl-enforcement?

I don't care if someone wants to take my code and blatantly make use of
it in their own projects. I encourage it. I wrote it so people could do
whatever the hell they wanted to with it. It's when that project is made
available to others where I expect the GPL to enforce my copyrights and
licenses. I don't expect my code to be self checking for it, and then
add conditions that this portion of the code cannot be removed, because
then it isn't really GPL anymore, because then it isn't really free
either.

Maybe people will be happy if it ends up like this:

Booting Linux...
Please insert your original GNU/Linux source CD...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 15:10 +, James Courtier-Dutton wrote:
> Ben Collins wrote:
> > 
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> > 
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
> > ati
> > nvidia
> > ltmodem (does that even still work?)
> > ipw3945d (not a kernel module, but just the daemon)
> > 
> 
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/

I haven't even caught wind of this not being supported yet. No demand ==
no reason to include it when it does become available.

> > In over a year that list has only grown by ipw3945d. None of our users
> > are asking for new proprietary drivers. Believe me, if they needed them,
> > I'd hear about it. We have more cases of new unsupported hardware than
> > we do of new hardware with binary-only drivers. This proposed
> > restriction doesn't fix that.
> 
> Is there a list of "new unsupported hardware" ?
> Reverse engineering or datasheets is the only way out of that.
> As Linux becomes more and more popular on the desktop, manufacturers 
> will start feeling the pain of Linux "unsupported hardware" and have to 
> back down and release datasheets. Ubuntu is helping a lot in that direction.

I've not kept a list. Would be non-trivial to go through the bug tracker
to find this info. Mostly it's things like webcams, and wacky little
hardware that starts cropping up in laptops.

> > 
> > You know what I think hurts us more than anything? You know what
> > probably keeps companies from writing drivers or releasing specs? It's
> > because they know some non-paid kernel hackers out there will eventually
> > reverse engineer it and write the drivers for them. Free development,
> > and they didn't even have to release their precious specs.
> 
> Well, once a device has been reverse engineered and GPLed, the specs are 
> then in public domain and the IP does not exist any more. It actually 
> helps the company release the specs once the information is already out 
> there. The company then sees less reason to hold onto their specs in the 
> first place, and tends to release them earlier next time.

Right, I think reverse engineering does help in that aspect. The other
aspect is that they now have a driver that sort of works for their
hardware. Most of the work is done, and they decide to help things along
to make it stable. So laying ground work like this can have advantages.

I think hardware vendors are a lot like users. Once they see the
advantages to opening up their drivers, they wonder why they didn't do
it a long time ago. Sort of like how users need that one push to use
Linux, and they start to wonder why they should go back to Windows.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1] ib_verbs: Use explicit if-else statements to avoid errors with do-while macros

[Ben Collins]

On Wed, 2006-12-13 at 23:45 -0800, Roland Dreier wrote:
>  > IOW, do ; while(0) / do { } while (0)  is not a proper way to do a macro
>  > that imitates a function returning void.
>  > 
>  > Objections?
> 
> None from me, although the ternary ? : is a pretty odd way to write
> 
>   if (blah)
>   do_this_void_function();
>   else
>   do_that_void_function();
> 
> so I'm in favor of that half of the patch anyway.  It's my fault for
> not noticing that part of the patch in the first place.
> 
> Changing the non-void ? : constructions is just churn, but there's no
> sense changing it again now that the patch is merged.

The rest of it was just for consistency sake.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Wed, 2006-12-13 at 21:39 -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary drivers become pervasive. I don't want to see Linux destroyed
> like that.

Yes, people have been worried about this for years, and to my knowledge,
it seems like things have been getting better with drivers, not worse
(look at Intel). And yet, people want to enforce more and more
restrictions against binary-only drivers, when it appears that we are
already winning.

You can't talk about drivers that don't exist for Linux. Things like
bcm43xx aren't effected by this new restriction for GPL-only drivers.
There's no binary-only driver for it (ndiswrapper doesn't count). If the
hardware vendor doesn't want to write a driver for linux, you can't make
them. You can buy other hardware, but that's about it.

Here's the list of proprietary drivers that are in Ubuntu's restricted
modules package:

madwifi (closed hal implementation, being replaced in openhal)
fritz
ati
nvidia
ltmodem (does that even still work?)
ipw3945d (not a kernel module, but just the daemon)

In over a year that list has only grown by ipw3945d. None of our users
are asking for new proprietary drivers. Believe me, if they needed them,
I'd hear about it. We have more cases of new unsupported hardware than
we do of new hardware with binary-only drivers. This proposed
restriction doesn't fix that.

You know what I think hurts us more than anything? You know what
probably keeps companies from writing drivers or releasing specs? It's
because they know some non-paid kernel hackers out there will eventually
reverse engineer it and write the drivers for them. Free development,
and they didn't even have to release their precious specs.

Don't get me wrong, I'm not bashing reverse engineering, or writing our
own drivers. It's how Linux got started. But the problem isn't as narrow
as people would like to think. And proprietary code isn't a growing
problem. At best, it's just a distraction that will eventually go away
on it's own.

The whole hardware vendor landscape is showing this, and it's not
because we locked down the kernel, it's because we've shown how well we
play with others, and how easy it is to get along with the whole
community. Do we want to destroy this good will?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
> first. This is not something where we use my tree as a way to get it to 
> other trees. This is something where the push had better come from the 
> other direction.

I can probably speak for Ubuntu in saying we wont include any sort of
patch like this unless it's forced on us.

I have to agree with your your whole statement. The gradual changes to
lock down kernel modules to a particular license(s) tends to mirror the
slow lock down of content (music/movies) that people complain about so
loudly. It's basically becoming DRM for code.

I don't think anyone ever expected technical mechanisms to be developed
to enforce the GPL. It's sort of counter intuitive to why the GPL
exists, which is to free the code.

Let the licenses and lawyers fight to protect the code. The code doesn't
need to do that itself. It's got better things to do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.20-rc1] ib_verbs: Use explicit if-else statements to avoid errors with do-while macros

[Ben Collins]

At least on PPC, the "op ? op : dma" construct causes a compile failure
because the dma_* is a do{}while(0) macro.

This turns all of them into proper if/else to avoid this problem.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index fd2353f..3c2e105 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1456,9 +1456,9 @@ struct ib_mr *ib_get_dma_mr(struct ib_pd
  */
 static inline int ib_dma_mapping_error(struct ib_device *dev, u64 dma_addr)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->mapping_error(dev, dma_addr) :
-   dma_mapping_error(dma_addr);
+   if (dev->dma_ops)
+   return dev->dma_ops->mapping_error(dev, dma_addr);
+   return dma_mapping_error(dma_addr);
 }
 
 /**
@@ -1472,9 +1472,9 @@ static inline u64 ib_dma_map_single(stru
void *cpu_addr, size_t size,
enum dma_data_direction direction)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->map_single(dev, cpu_addr, size, direction) :
-   dma_map_single(dev->dma_device, cpu_addr, size, direction);
+   if (dev->dma_ops)
+   return dev->dma_ops->map_single(dev, cpu_addr, size, direction);
+   return dma_map_single(dev->dma_device, cpu_addr, size, direction);
 }
 
 /**
@@ -1488,8 +1488,9 @@ static inline void ib_dma_unmap_single(s
   u64 addr, size_t size,
   enum dma_data_direction direction)
 {
-   dev->dma_ops ?
-   dev->dma_ops->unmap_single(dev, addr, size, direction) :
+   if (dev->dma_ops)
+   dev->dma_ops->unmap_single(dev, addr, size, direction);
+   else
dma_unmap_single(dev->dma_device, addr, size, direction);
 }
 
@@ -1507,9 +1508,9 @@ static inline u64 ib_dma_map_page(struct
  size_t size,
 enum dma_data_direction direction)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->map_page(dev, page, offset, size, direction) :
-   dma_map_page(dev->dma_device, page, offset, size, direction);
+   if (dev->dma_ops)
+   return dev->dma_ops->map_page(dev, page, offset, size, 
direction);
+   return dma_map_page(dev->dma_device, page, offset, size, direction);
 }
 
 /**
@@ -1523,8 +1524,9 @@ static inline void ib_dma_unmap_page(str
 u64 addr, size_t size,
 enum dma_data_direction direction)
 {
-   dev->dma_ops ?
-   dev->dma_ops->unmap_page(dev, addr, size, direction) :
+   if (dev->dma_ops)
+   dev->dma_ops->unmap_page(dev, addr, size, direction);
+   else
dma_unmap_page(dev->dma_device, addr, size, direction);
 }
 
@@ -1539,9 +1541,9 @@ static inline int ib_dma_map_sg(struct i
struct scatterlist *sg, int nents,
enum dma_data_direction direction)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->map_sg(dev, sg, nents, direction) :
-   dma_map_sg(dev->dma_device, sg, nents, direction);
+   if (dev->dma_ops)
+   return dev->dma_ops->map_sg(dev, sg, nents, direction);
+   return dma_map_sg(dev->dma_device, sg, nents, direction);
 }
 
 /**
@@ -1555,8 +1557,9 @@ static inline void ib_dma_unmap_sg(struc
   struct scatterlist *sg, int nents,
   enum dma_data_direction direction)
 {
-   dev->dma_ops ?
-   dev->dma_ops->unmap_sg(dev, sg, nents, direction) :
+   if (dev->dma_ops)
+   dev->dma_ops->unmap_sg(dev, sg, nents, direction);
+   else
dma_unmap_sg(dev->dma_device, sg, nents, direction);
 }
 
@@ -1568,8 +1571,9 @@ static inline void ib_dma_unmap_sg(struc
 static inline u64 ib_sg_dma_address(struct ib_device *dev,
struct scatterlist *sg)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->dma_address(dev, sg) : sg_dma_address(sg);
+   if (dev->dma_ops)
+   return dev->dma_ops->dma_address(dev, sg);
+   return sg_dma_address(sg);
 }
 
 /**
@@ -1580,8 +1584,9 @@ static inline u64 ib_sg_dma_address(stru
 static inline unsigned int ib_sg_dma_len(struct ib_device *dev,
 struct scatterlist *sg)
 {
-   return dev->dma_ops ?
-   dev->dma_ops->dma_len(dev, sg) : sg_dma_len(sg);
+   if (dev->dma_ops)
+   return dev->dma_ops->dma_len(dev, sg);
+   return sg_dma_len(sg);
 }
 
 /**
@@ -1596,8 +160

Re: [PATCH] PCI legacy resource fix

[Ben Collins]

On Sat, 2006-12-09 at 13:14 +, Alan wrote:
> On Sat, 09 Dec 2006 03:12:11 -0500
> Ben Collins <[EMAIL PROTECTED]> wrote:
> > My controller is in legacy mode, however, it never gets to here because
> > of this call, just before this block of code:
> > 
> > rc = pci_request_regions(pdev, DRV_NAME);
> > if (rc) {
> > disable_dev_on_err = 0;
> > goto err_out;
> > }
> 
> Then you don't have the fix applied that was posted. That code is not
> present in the form you pasted in the fixed version of the libata code.
> It is within an if (!legacy_mode)

I didn't see that patch until you mentioned it. Even still, there seems
to be one thing missing. I suspect you still want to take the bmdma
resource since both native and legacy use it. With the patch you
mentioned, that resource wont be requested in legacy mode.

Also, I did my patch as detailed as it is because of this line:

/* TODO: What if one channel is in native mode ... */

If that's never going to be the case then the comment should go. If it
is possible, then my patch makes this work. The way things are now, it
will ignore a native mode port if it is sitting on the same controller
as a legacy mode one.

Want to re-evaluate the patch based on this info?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI legacy resource fix

[Ben Collins]

On Sat, 2006-12-09 at 02:46 +, Alan wrote:
> > Checking the patch, my problem is that the old way, all BAR's were being
> > set at start = end = flags = 0. The patch makes it set all the BAR's to
> 
> Yes the old quirk used to blank the resources as the values on the chip
> are undefined and random. This gives you corrupt resource trees and needs
> hacks in the drivers as well
> 
> > the normal values. This is what it looks like in lspci, pre this patch:
> > 
> > Region 0: I/O ports at 
> > Region 1: I/O ports at 
> > Region 2: I/O ports at 
> > Region 3: I/O ports at 
> 
> Then your device is in legacy mode, or was disabled
>  
> > So my device is not running in compatibility mode, and should not have
> 
> The paste you have their shows that it almost certainly is in legacy mode.
> 
> > the BAR's set, as Alan's patch does.
> 
> Dump the class code and other bits during boot check how your device is
> seen (native v legacy/compatibility) and whether the fixup logic
> triggers. It should only trigger for legacy devices.

You're right, I was reading this backwards.

Thing is, if I disable the quirk, ata_piix works correctly.

So I think maybe the problem is the logic here. Having the PIIX quirk
pre-reserve SATA ports that are on legacy BAR's just doesn't seem to
make sense unless libata is going to recognize that. I think it's just
an accident that it worked before.

Looking at ata_pci_init_one(), it does check for this:

if (legacy_mode) {
if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
struct resource *conflict, res;
res.start = ATA_PRIMARY_CMD;
res.end = ATA_PRIMARY_CMD + 8 - 1;
conflict = request_resource(&ioport_resource, &res);
while (conflict->child)
conflict = request_resource(conflict, &res);
if (!strcmp(conflict->name, "libata"))
legacy_mode |= ATA_PORT_PRIMARY;

My controller is in legacy mode, however, it never gets to here because
of this call, just before this block of code:

rc = pci_request_regions(pdev, DRV_NAME);
if (rc) {
disable_dev_on_err = 0;
goto err_out;
}

So, I wrote up this patch that made things work for me. It also should
make ata_pci_init_one() work with mixed legacy/native ports on the same
controller (if there are such things). My controller is port0=SATA,
port1=PATA.

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 10ee22a..8897eba 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -852,11 +852,14 @@ #ifdef CONFIG_PCI
 struct ata_probe_ent *
 ata_pci_init_native_mode(struct pci_dev *pdev, struct ata_port_info **port, 
int ports)
 {
-   struct ata_probe_ent *probe_ent =
-   ata_probe_ent_alloc(pci_dev_to_dev(pdev), port[0]);
+   struct ata_probe_ent *probe_ent;
int p = 0;
unsigned long bmdma;
 
+   if (!(ports & (ATA_PORT_PRIMARY|ATA_PORT_SECONDARY)))
+   return NULL;
+
+   probe_ent = ata_probe_ent_alloc(pci_dev_to_dev(pdev), port[0]);
if (!probe_ent)
return NULL;
 
@@ -906,6 +909,9 @@ static struct ata_probe_ent *ata_pci_ini
struct ata_probe_ent *probe_ent;
unsigned long bmdma = pci_resource_start(pdev, 4);
 
+   if (!(port_mask & (ATA_PORT_PRIMARY|ATA_PORT_SECONDARY)))
+   return NULL;
+
probe_ent = ata_probe_ent_alloc(pci_dev_to_dev(pdev), port[0]);
if (!probe_ent)
return NULL;
@@ -979,10 +985,10 @@ static struct ata_probe_ent *ata_pci_ini
 int ata_pci_init_one (struct pci_dev *pdev, struct ata_port_info **port_info,
  unsigned int n_ports)
 {
-   struct ata_probe_ent *probe_ent = NULL;
+   struct ata_probe_ent *probe_ent_legacy = NULL;
+   struct ata_probe_ent *probe_ent_native = NULL;
struct ata_port_info *port[2];
-   u8 mask;
-   unsigned int legacy_mode = 0;
+   unsigned int legacy_mode = 0, legacy_probe = 0, native_probe = 0;
int disable_dev_on_err = 1;
int rc;
 
@@ -1011,29 +1017,32 @@ int ata_pci_init_one (struct pci_dev *pd
if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
u8 tmp8;
 
-   /* TODO: What if one channel is in native mode ... */
pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8);
-   mask = (1 << 2) | (1 << 0);
-   if ((tmp8 & mask) != mask)
-   legacy_mode = (1 << 3);
+
+   if ((tmp8 & ATA_PORT_PRIMARY_LEGACY) == 0)
+   legacy_mode |= ATA_PORT_PRIMARY;
+   if ((tmp8 & ATA_PORT_SECONDARY_LEGACY) == 0)
+   legacy_mode |= ATA_PORT_SECONDARY;
+
 #if defined(CONFIG_NO_ATA_LEGACY)
/* Some platforms with

Re: [PATCH] PCI legacy resource fix

[Ben Collins]

On Sat, 2006-12-09 at 01:25 +, Ralf Baechle wrote:
> On Fri, Dec 08, 2006 at 07:46:18PM -0500, Ben Collins wrote:
> 
> > On Wed, 2006-12-06 at 13:41 +, Ralf Baechle wrote:
> > > Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try
> > > to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
> > > pci_assign_unassigned_resources() is used to do full resource assignment
> > > of the bus.  This fails because in the PIIX4 these BAR registers have
> > > implicitly assumed values and read back as zero; it used to work because
> > > the kernel used to just write zero to that register the read back value
> > > did match what was written.
> > > 
> > > The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a
> > > resource as non-movable.  This will also be useful to keep other import
> > > system resources from being moved around - for example system consoles
> > > on PCI busses.
> > 
> > I have a problem where an ich6 (SATA+PATA) is getting its port0 reserved
> > by the pci quirk for libata so that it gets picked up by ata_piix. In
> > current git, ata_piix complains:
> > 
> > [  124.507570] PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for 
> > device :00:1f.2
> > 
> > I bisected to the same commit, 368c73d4f689dae0807d0a2aa74c61fd2b9b075f,
> > however, your patch doesn't fix my problem.
> 
> Looks like a double reservation.  My patch doesn't deal with reservations
> at all.  I thought about resource reservations but decieded that should
> be dealt with elsewhere.

Checking the patch, my problem is that the old way, all BAR's were being
set at start = end = flags = 0. The patch makes it set all the BAR's to
the normal values. This is what it looks like in lspci, pre this patch:

Region 0: I/O ports at 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 

So my device is not running in compatibility mode, and should not have
the BAR's set, as Alan's patch does.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI legacy resource fix

[Ben Collins]

On Wed, 2006-12-06 at 13:41 +, Ralf Baechle wrote:
> Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try
> to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
> pci_assign_unassigned_resources() is used to do full resource assignment
> of the bus.  This fails because in the PIIX4 these BAR registers have
> implicitly assumed values and read back as zero; it used to work because
> the kernel used to just write zero to that register the read back value
> did match what was written.
> 
> The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a
> resource as non-movable.  This will also be useful to keep other import
> system resources from being moved around - for example system consoles
> on PCI busses.

I have a problem where an ich6 (SATA+PATA) is getting its port0 reserved
by the pci quirk for libata so that it gets picked up by ata_piix. In
current git, ata_piix complains:

[  124.507570] PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for 
device :00:1f.2

I bisected to the same commit, 368c73d4f689dae0807d0a2aa74c61fd2b9b075f,
however, your patch doesn't fix my problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] New firewire stack

[Ben Collins]

On Wed, 2006-12-06 at 09:56 +0100, Stefan Richter wrote:
> (Adding Cc: linux1394-devel)
> 
> Ben Collins wrote at linux-kernel:
> > On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> >> Alexey Dobriyan wrote:
> >>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> >>>> I'm announcing an alternative firewire stack that I've been working on 
> >>>> the last few weeks.
> >>> Is mainline firewire so hopeless, that you've decided to rewrite it? Could
> >>> you show some ugly places in it?
> >> Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
> >> introduce regressions and instability for a little while.
> >>
> >> My main point about ohci1394 (the old stacks PCI driver) is, that if you
> >> really want to fix the issues with this driver, you have to shuffle the 
> >> code
> >> around so much that you'll introduce as many regressions as a clean 
> >> rewrite.
> >> The big problems in the ohci1394 drivers is the irq_handler, bus reset
> >> handling and config rom handling.  These are some of the strong points of
> >> fw-ohci.c:
> > 
> > My main concern is that when I picked up ieee1394 maint myself, it was
> > because it was not big-endian or 64-bit friendly.
> 
> I would like to see new development efforts take cleanliness WRT host
> byte order and 64bit architectures into account from the ground up. (I
> understand though why Kristian made the announcement in this early
> phase, and I agree with him that this kind of development has to go into
> the open early.)

And yet endianness is not the focus from the ground up in Kristian's
work. That was my point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] New firewire stack

[Ben Collins]

On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> Alexey Dobriyan wrote:
> > On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> >> I'm announcing an alternative firewire stack that I've been working on 
> >> the last few weeks.
> > 
> > Is mainline firewire so hopeless, that you've decided to rewrite it? Could
> > you show some ugly places in it?
> 
> Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
> introduce regressions and instability for a little while.
> 
> My main point about ohci1394 (the old stacks PCI driver) is, that if you
> really want to fix the issues with this driver, you have to shuffle the code
> around so much that you'll introduce as many regressions as a clean rewrite.
> The big problems in the ohci1394 drivers is the irq_handler, bus reset
> handling and config rom handling.  These are some of the strong points of
> fw-ohci.c:

My main concern is that when I picked up ieee1394 maint myself, it was
because it was not big-endian or 64-bit friendly. I spent the better
part of 3 months getting this right on PPC and UltraSPARC. Not because
it's hard to fix these issues, but because the hardware is not well
defined for a lot of these cases (I know you've seen the ohci1394 code
to handle endianness).

So while I can understand that ieee1394 doesn't have much man power
right now, and that there are some hard to find bugs in the current
tree, I can't see how starting from scratch alleviates this.

The tree is years old, and a lot of work has been put into it (lots of
my work, I'll admit I'm being a little protective). I'm not sure that
"replacing" it is wise, or even needed. Fork it, clean it up, but
rewriting just doesn't make sense.

Granted, this is your time, and you can spend it how you want, I just
don't want to see the ieee1394 stack take a step backwards in the hopes
that it will be better a year down the road.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Export current_is_keventd() for libphy

[Ben Collins]

Fixes this problem when libphy is compiled as module:

WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 17c2f03..1cf226b 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -608,6 +608,7 @@ int current_is_keventd(void)
return ret;
 
 }
+EXPORT_SYMBOL_GPL(current_is_keventd);
 
 #ifdef CONFIG_HOTPLUG_CPU
 /* Take the work from this (downed) CPU. */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 22:49 +0100, Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 16:01 -0500, Ben Collins wrote:
> > On Fri, 2006-12-01 at 20:45 +0100, Arjan van de Ven wrote:
> > > On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> > > > What about the point that userspace (udev, and such) is not available
> > > > when DSDT loading needs to occur? Init hasn't even started at that
> > > > point.
> > > 
> > > that's a moot point; you need to load firmware from the initramfs ANYWAY
> > > for things like qlogic and others...
> > 
> > I don't see how that relates. The DSDT needs to be loaded even before
> > driver initialization begins. 
> 
> in fact it needs to be loaded even before the ACPI engine starts
> executing, otherwise you're hot-replacing code underneath a live
> system...  at which point you can do this same feature in another way :)
> there already is a feature that builds a dsdt into the kernel image, all
> a distro would need is a bit of objcopy magic to build the right one
> into the vmlinuz...

Providing object files for on-demand relinking of the kernel just adds a
shit load of overhead. If you're suggesting modifying vmlinuz in place
instead, that just seems really undesirable. Last thing I want is
something mucking with the kernel binary.

It's easier for me to keep this patch in my tree, especially since most
users have come to expect this as the "standard" method for inserting
their DSDT replacement.

The only other thing I can think of is grub providing the DSDT just like
it does for the initrd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 20:45 +0100, Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> > What about the point that userspace (udev, and such) is not available
> > when DSDT loading needs to occur? Init hasn't even started at that
> > point.
> 
> that's a moot point; you need to load firmware from the initramfs ANYWAY
> for things like qlogic and others...

I don't see how that relates. The DSDT needs to be loaded even before
driver initialization begins. Things like qlogic can over come this by
being compiled as modules, and letting initramfs-tools take care of
things.

That's not the case for DSDT loading. I'm not saying this patch is the
epitome of good coding, just that it's a needed feature.

If there's a better way to do it, I'm volunteering to do the grunt work,
but I haven't heard of any alternatives to this solution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 19:53 +, Alan wrote:
> > > The whole approach of using filp_open() not the firmware interface
> > > is horribly ugly and does not belong mainstream. 
> > 
> > What about the point that userspace (udev, and such) is not available
> > when DSDT loading needs to occur? Init hasn't even started at that
> > point.
> 
> Does that change the fact it is ugly ?

No, but it does beg the question "how else can it be done"?

Distros need a way for users to add a fixed DSDT without recompiling
their own kernels.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] [APIC] Allow disabling of UP APIC/IO-APIC by default, with command line option to turn it on.

[Ben Collins]

On Fri, 2006-12-01 at 09:39 +0100, Ingo Molnar wrote:
> * Ben Collins <[EMAIL PROTECTED]> wrote:

> that should be "ioapic", not "apic". The CPU has a piece of silicon 
> called the "local APIC" - enabled via the 'lapic' option, and disabled 
> via noapic. What the option above wants to enable is the IO-APIC in the 
> chipset (a different piece of silicon) and the interrupt routing 
> capabilities attached to it. That piece is what is causing the installer 
> problems.

I know the difference between APIC and IO-APIC :)

Thing is, the function right above the one I added was this:

static int __init parse_noapic(char *arg)
{
/* disable IO-APIC */
disable_ioapic_setup();
return 0;
}
early_param("noapic", parse_noapic);

So while "ioapic" might make more sense, it's doesn't match the opposing
command line option of "noapic".

I could include this in the diff:

+/* "noapic" is for backward compatibility */
 early_param("noapic", parse_noapic);
+early_param("noioapic", parse_noapic);

And then add the "ioapic" option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 18:56 +, Alan wrote:
> On Fri, 01 Dec 2006 13:36:19 -0500
> Ben Collins <[EMAIL PROTECTED]> wrote:
> 
> > I'd be willing to bet that most distros have this patch in their kernel.
> > One of those things we can't really live without.
> 
> This has been suggested various times before. 
> 
> | +Before you run away from customising your DSDT, you should note that
> | already +corrected tables are available for a fair amount of computers
> | on this web-page: +http://acpi.sf.net/dsdt
> 
> Generally without copyright permission from the owner of the copyrighted
> work in question to have it modified and redistributed.
> 
> The whole approach of using filp_open() not the firmware interface
> is horribly ugly and does not belong mainstream. 

What about the point that userspace (udev, and such) is not available
when DSDT loading needs to occur? Init hasn't even started at that
point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

I'd be willing to bet that most distros have this patch in their kernel.
One of those things we can't really live without.

What I haven't understood is why it isn't included in the mainline
kernel yet. There's enough kernel hackers out there using this that I
doubt it will get stale or broken for very long.

I'm willing to do the grunt work to get it suitable.

Patch attached for convenience.

diff -urpN -X linux-2.6.18/Documentation/dontdiff 
linux-2.6.18.bak/Documentation/dsdt-initrd.txt 
linux-2.6.18/Documentation/dsdt-initrd.txt
--- linux-2.6.18.bak/Documentation/dsdt-initrd.txt  1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.18/Documentation/dsdt-initrd.txt  2006-08-12 11:15:13.0 
+0200
@@ -0,0 +1,98 @@
+ACPI Custom DSDT read from initramfs
+
+2003 by Markuss Gaugusch < dsdt at gaugusch dot org >
+Special thanks go to Thomas Renninger from SuSE, who updated the patch for
+2.6.0 and later modified it to read inside initramfs
+2004 - 2006 maintained by Eric Piel < eric dot piel at tremplin-utc dot net >
+
+This option is intended for people who would like to hack their DSDT and don't 
want
+to recompile their kernel after every change. It can also be useful to distros
+which offers pre-compiled kernels and want to allow their users to use a
+modified DSDT. In the Kernel config, enable the initial RAM filesystem support
+(in Device Drivers|Block Devices) and enable ACPI_CUSTOM_DSDT_INITRD at the 
ACPI
+options (General Setup|ACPI Support|Read custom DSDT from initrd).
+
+A custom DSDT (Differentiated System Description Table) is useful when your
+computer uses ACPI but problems occur due to broken implementation. Typically,
+your computer works but there are some troubles with the hardware detection or
+the power management. You can check that troubles come from errors in the DSDT 
by
+activating the ACPI debug option and reading the logs. This table is provided
+by the BIOS, therefore it might be a good idea to check for BIOS update on your
+vendor website before going any further. Errors are often caused by vendors
+testing their hardware only with Windows or because there is code which is
+executed only on a specific OS with a specific version and Linux hasn't been
+considered during the development.
+
+Before you run away from customising your DSDT, you should note that already
+corrected tables are available for a fair amount of computers on this web-page:
+http://acpi.sf.net/dsdt . If you are part of the unluckies who cannot find
+their hardware in this database, you can modify your DSDT by yourself. This
+process is less painful than it sounds. Download the Intel ASL 
+compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm 
.
+As root, you then have to dump your DSDT and decompile it. By using the
+compiler messages as well as the kernel ACPI debug messages and the reference 
book
+(available at the Intel website and also at http://www.acpi.info), it is quite
+easy to obtain a fully working table.
+
+Once your new DSDT is ready you'll have to add it to an initrd so that the
+kernel can read the table at the very beginning of the boot. As the file has
+to be accessed very early during the boot process the initrd has to be an
+initramfs. The file is contained into the initramfs under the name /DSDT.aml .
+To obtain such an initrd, you might have to modify your mkinitrd script or you
+can add it later to the initrd with the script appended to this document. The
+command will look like:
+initrd-add-dsdt initrd.img my-dsdt.aml
+
+In case you don't use any initrd, the possibilities you have are to either 
start
+using one (try mkinitrd or yaird), or use the "Include Custom DSDT" configure
+option to directly include your DSDT inside the kernel.
+
+The message "Looking for DSDT in initramfs..." will tell you if the DSDT was
+found or not. If you need to update your DSDT, generate a new initrd and
+perform the steps above. Don't forget that with Lilo, you'll have to re-run it.
+
+
+=== Here starts initrd-add-dsdt 
===
+#!/bin/bash
+# Adds a DSDT file to the initrd (if it's an initramfs)
+# first argument is the name of archive
+# second argurment is the name of the file to add
+# The file will be copied as /DSDT.aml
+
+# 20060126: fix "Premature end of file" with some old cpio (Roland Robic)
+# 20060205: this time it should really work
+
+# check the arguments
+if [ $# -ne 2 ]; then
+   program_name=$(basename $0)
+   echo "\
+$program_name: too few arguments
+Usage: $program_name initrd-name.img DSDT-to-add.aml
+Adds a DSDT file to an initrd (in initramfs format)
+
+  initrd-name.img: filename of the initrd in initramfs format
+  DSDT-to-add.aml: filename of the DSDT file to add
+  " 1>&2
+exit 1
+fi
+
+# we should check it's an initramfs
+
+tempcpio=$(mktemp -d)
+# cleanup on exit, hangup, interrupt, quit, termination
+trap 'rm -rf $tempcpio' 0 1 2 3 15
+
+# extract the archive
+gunzip -c "$1" > "$tempcp

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 17:10 +0100, Arjan van de Ven wrote:
> > I'm just basing this on the history of the patch, which preceeds me, so
> > if this is incorrect, please don't blame me for misinformation :)
> > 
> > The original patch claims that hyper-threading opens the user up to some
> > sort of security risk involving hardware limitations in protecting
> > memory across the threads. I can't recall all the details.
> > 
> > If this is wrong, I'm more than happy to just drop the whole damn patch.
> 
> that is not correct.
> I suspect what is meant is the "attack" on older openssl versions where
> you could in theory get SOME information about a key in use by snooping
> cache patterns in a shared cache situation. By no means is it a "direct"
> leak of any kind, and openssl has since then been fixed to not have as
> many key-dependent execution streams anymore.
> 
> I would suggest you drop the patch; openssl has been long fixed, and it
> was only a theoretical attack in the first place...
> I'm not saying the attack isn't something that should be addressed.. but
> it is, and disabling hyperthreading is not the right fix.

Thanks for clearing that up. Patch withdrawn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 15:32 +0100, Arjan van de Ven wrote:
> > 
> > The idea is that we want our users to be able to use hyper-threading,
> > but we don't want it on by default.
> 
> Hi,
> 
> can I ask why not?

I'm just basing this on the history of the patch, which preceeds me, so
if this is incorrect, please don't blame me for misinformation :)

The original patch claims that hyper-threading opens the user up to some
sort of security risk involving hardware limitations in protecting
memory across the threads. I can't recall all the details.

If this is wrong, I'm more than happy to just drop the whole damn patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 13:29 +, Pavel Machek wrote:
> Hi!
> 
> > This patch adds a config option to allow disabling hyper-threading by
> > default, and a kernel command line option to changes this default at
> > boot time.
> 
> > +config X86_HT_DISABLE
> > +   bool "Disable Hyper-Threading by default"
> > +   depends on X86_HT
> > +   default n
> > +
> 
> Command line options are fine, but additional config options mirroring
> command line functionality look ugly to me...

There's actually two parts to the patch. One is the kernel command line
option to allow HT to be enabled/disabled. The second is this config
option that allows the default to be off instead of the current
always-on.

The idea is that we want our users to be able to use hyper-threading,
but we don't want it on by default.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] [HVCS] Select HVC_CONSOLE if HVCS is enabled.

[Ben Collins]

On Thu, 2006-11-30 at 13:32 +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 29 Nov 2006, Ben Collins wrote:
> 
> > If HVC_CONSOLE provides symbols that HVCS requires.
> > 
> > Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
> > ---
> >  drivers/char/Kconfig |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index 2af12fc..c94ecdc 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -598,6 +598,7 @@ config HVC_RTAS
> >  config HVCS
> > tristate "IBM Hypervisor Virtual Console Server support"
> > depends on PPC_PSERIES
> > +   select HVC_CONSOLE
> > help
> >   Partitionable IBM Power5 ppc64 machines allow hosting of
> >   firmware virtual consoles from one Linux partition by
> 
> 
> Why not a normal dependency?

Most of the HVC options are doing select on other HVC things (like
select HVC_DRIVER). So if this one needs to be a dependency, then it
would make more sense to clean up the HVC option group to do the same. I
just did the one-liner to make it work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] [ATM] Add CPPFLAGS to byteorder.h check.

[Ben Collins]

O= builds produced errors in the shell command because of unfound headers.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/atm/Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/atm/Makefile b/drivers/atm/Makefile
index b5077ce..1b16f81 100644
--- a/drivers/atm/Makefile
+++ b/drivers/atm/Makefile
@@ -41,7 +41,7 @@ ifeq ($(CONFIG_ATM_FORE200E_PCA),y)
   # guess the target endianess to choose the right PCA-200E firmware image
   ifeq ($(CONFIG_ATM_FORE200E_PCA_DEFAULT_FW),y)
 byteorder.h:= include$(if $(patsubst 
$(srctree),,$(objtree)),2)/asm/byteorder.h
-CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) -E -dM 
$(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
+CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) $(CPPFLAGS) 
-E -dM $(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
   endif
 endif
 
-- 
1.4.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] [APIC] Allow disabling of UP APIC/IO-APIC by default, with command line option to turn it on.

[Ben Collins]

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 arch/i386/Kconfig  |   13 +
 arch/i386/kernel/apic.c|   13 +++--
 arch/i386/kernel/io_apic.c |   10 +-
 include/asm-i386/apic.h|6 ++
 include/asm-i386/io_apic.h |5 +
 5 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index b4a2461..ef2f2db 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -285,6 +285,19 @@ config X86_UP_IOAPIC
  to use it. If you say Y here even though your machine doesn't have
  an IO-APIC, then the kernel will still run with no slowdown at all.
 
+config X86_UP_APIC_DEFAULT_OFF
+   bool "APIC support on uniprocessors defaults to off"
+   depends on X86_UP_APIC
+   default n
+   help
+ Some older systems have flaky APICs.  Say Y to turn off APIC
+ support by default, while still allowing it to be enabled by the
+ "lapic" and "apic" command line options.
+
+ Usually this is only necessary for distro installer kernels that
+ must work with everything.  Everyone else can safely say N here
+ and configure APIC support in or out as needed.
+
 config X86_LOCAL_APIC
bool
depends on X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER) || 
X86_GENERICARCH
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 2fd4b7d..2f2eb83 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -51,8 +51,9 @@ static cpumask_t timer_bcast_ipi;
 
 /*
  * Knob to control our willingness to enable the local APIC.
+ * -2=default-disable, -1=force-disable, 1=force-enable, 0=automatic
  */
-static int enable_local_apic __initdata = 0; /* -1=force-disable, 
+1=force-enable */
+static int enable_local_apic __initdata = (X86_APIC_DEFAULT_OFF ? -2 : 0);
 
 static inline void lapic_disable(void)
 {
@@ -801,7 +802,7 @@ static int __init detect_init_APIC (void
 * APIC only if "lapic" specified.
 */
if (enable_local_apic <= 0) {
-   printk("Local APIC disabled by BIOS -- "
+   printk("Local APIC disabled by BIOS (or by default) -- "
   "you can enable it with \"lapic\"\n");
return -1;
}
@@ -1350,6 +1351,14 @@ int __init APIC_init_uniprocessor (void)
if (!smp_found_config && !cpu_has_apic)
return -1;
 
+   /* If local apic is off due to config_x86_apic_off option, jump
+* out here. */
+   if (enable_local_apic < -1) {
+   printk(KERN_INFO "Local APIC disabled by default -- "
+  "use 'lapic' to enable it.\n");
+   return -1;
+   }
+
/*
 * Complain if the BIOS pretends there is one.
 */
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 3b7a63e..0122dba 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -767,7 +767,7 @@ #endif /* !CONFIG_SMP */
 #define MAX_PIRQS 8
 static int pirq_entries [MAX_PIRQS];
 static int pirqs_enabled;
-int skip_ioapic_setup;
+int skip_ioapic_setup = X86_APIC_DEFAULT_OFF;
 
 static int __init ioapic_setup(char *str)
 {
@@ -2887,3 +2887,11 @@ static int __init parse_noapic(char *arg
return 0;
 }
 early_param("noapic", parse_noapic);
+
+static int __init parse_apic(char *arg)
+{
+   /* enable IO-APIC */
+   enable_ioapic_setup();
+   return 0;
+}
+early_param("apic", parse_apic);
diff --git a/include/asm-i386/apic.h b/include/asm-i386/apic.h
index b952957..a06ca3f 100644
--- a/include/asm-i386/apic.h
+++ b/include/asm-i386/apic.h
@@ -71,6 +71,12 @@ # define apic_read_around(x) apic_read(x
 # define apic_write_around(x,y) apic_write_atomic((x),(y))
 #endif
 
+#ifdef CONFIG_X86_UP_APIC_DEFAULT_OFF
+# define X86_APIC_DEFAULT_OFF 1
+#else
+# define X86_APIC_DEFAULT_OFF 0
+#endif
+
 static inline void ack_APIC_irq(void)
 {
/*
diff --git a/include/asm-i386/io_apic.h b/include/asm-i386/io_apic.h
index 059a9ff..ddedeec 100644
--- a/include/asm-i386/io_apic.h
+++ b/include/asm-i386/io_apic.h
@@ -126,6 +126,11 @@ static inline void disable_ioapic_setup(
skip_ioapic_setup = 1;
 }
 
+static inline void enable_ioapic_setup(void)
+{
+   skip_ioapic_setup = 0;
+}
+
 static inline int ioapic_setup_disabled(void)
 {
return skip_ioapic_setup;
-- 
1.4.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] [HVCS] Select HVC_CONSOLE if HVCS is enabled.

[Ben Collins]

If HVC_CONSOLE provides symbols that HVCS requires.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 drivers/char/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 2af12fc..c94ecdc 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -598,6 +598,7 @@ config HVC_RTAS
 config HVCS
tristate "IBM Hypervisor Virtual Console Server support"
depends on PPC_PSERIES
+   select HVC_CONSOLE
help
  Partitionable IBM Power5 ppc64 machines allow hosting of
  firmware virtual consoles from one Linux partition by
-- 
1.4.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ubuntu patch sync for 2.6.20

[Ben Collins]

This is a set of patches from the Ubuntu tree that seemed suitable for
upstream sync.

[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[PATCH 2/4] [APIC] Allow disabling of UP APIC/IO-APIC by default, with command 
line option to turn it on.

[PATCH 3/4] [ATM] Add CPPFLAGS to byteorder.h check.

[PATCH 4/4] [HVCS] Select HVC_CONSOLE if HVCS is enabled.


 arch/i386/Kconfig   |   13 +
 Documentation/kernel-parameters.txt |3 +++
 arch/i386/Kconfig   |5 +
 arch/i386/kernel/apic.c |   13 +++--
 arch/i386/kernel/cpu/common.c   |   30 +-
 arch/i386/kernel/io_apic.c  |   10 +-
 drivers/atm/Makefile|3 +--
 drivers/char/Kconfig|2 +-
 include/asm-i386/apic.h |6 ++
 include/asm-i386/io_apic.h  |6 +-
 10 files changed, 83 insertions(+), 8 deletions(-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ubuntu patch sync for 2.6.20

[Ben Collins]

This is a set of patches from the Ubuntu tree that seemed suitable for
upstream sync.

[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[PATCH 2/4] [APIC] Allow disabling of UP APIC/IO-APIC by default, with command 
line option to turn it on.

[PATCH 3/4] [ATM] Add CPPFLAGS to byteorder.h check.

[PATCH 4/4] [HVCS] Select HVC_CONSOLE if HVCS is enabled.


 arch/i386/Kconfig   |   13 +
 Documentation/kernel-parameters.txt |3 +++
 arch/i386/Kconfig   |5 +
 arch/i386/kernel/apic.c |   13 +++--
 arch/i386/kernel/cpu/common.c   |   30 +-
 arch/i386/kernel/io_apic.c  |   10 +-
 drivers/atm/Makefile|3 +--
 drivers/char/Kconfig|2 +-
 include/asm-i386/apic.h |6 ++
 include/asm-i386/io_apic.h  |6 +-
 10 files changed, 83 insertions(+), 8 deletions(-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

This patch adds a config option to allow disabling hyper-threading by
default, and a kernel command line option to changes this default at
boot time.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
---
 Documentation/kernel-parameters.txt |3 +++
 arch/i386/Kconfig   |5 +
 arch/i386/kernel/cpu/common.c   |   29 +
 3 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 6747384..2b68d6e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -600,6 +600,9 @@ and is between 256 and 4096 characters. 
hisax=  [HW,ISDN]
See Documentation/isdn/README.HiSax.
 
+   ht= [HW,IA-32,SMP] Enable or disable hyper-threading.
+   Format: 
+
hugepages=  [HW,IA-32,IA-64] Maximal number of HugeTLB pages.
 
noirqbalance[IA-32,SMP,KNL] Disable kernel irq balancing
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 8ff1c6f..b4a2461 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -1185,6 +1185,11 @@ config X86_HT
depends on SMP && !(X86_VISWS || X86_VOYAGER)
default y
 
+config X86_HT_DISABLE
+   bool "Disable Hyper-Threading by default"
+   depends on X86_HT
+   default n
+
 config X86_BIOS_REBOOT
bool
depends on !(X86_VISWS || X86_VOYAGER)
diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c
index d9f3e3c..42d2361 100644
--- a/arch/i386/kernel/cpu/common.c
+++ b/arch/i386/kernel/cpu/common.c
@@ -482,6 +482,29 @@ void __cpuinit identify_cpu(struct cpuin
 }
 
 #ifdef CONFIG_X86_HT
+
+#ifdef CONFIG_X86_HT_DISABLE
+static int disable_ht __cpuinitdata = 1;
+#else
+static int disable_ht __cpuinitdata;
+#endif
+
+static int __init parse_ht(char *arg)
+{
+   if (!arg)
+   return -EINVAL;
+
+   if (!memcmp(arg, "on", 2))
+   disable_ht = 0;
+   else if (!memcmp(arg, "off", 3))
+   disable_ht = 1;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+early_param("ht", parse_ht);
+
 void __cpuinit detect_ht(struct cpuinfo_x86 *c)
 {
u32 eax, ebx, ecx, edx;
@@ -492,6 +515,12 @@ void __cpuinit detect_ht(struct cpuinfo_
if (!cpu_has(c, X86_FEATURE_HT) || cpu_has(c, X86_FEATURE_CMP_LEGACY))
return;
 
+   if (disable_ht) {
+   printk(KERN_INFO  "CPU: Hyper-Threading disabled by default. 
Enable with ht=on\n");
+   smp_num_siblings = 1;
+   return;
+   }
+
smp_num_siblings = (ebx & 0xff) >> 16;
 
if (smp_num_siblings == 1) {
-- 
1.4.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ubuntu patch sync for 2.6.20

[Ben Collins]

This is a set of patches from the Ubuntu tree that seemed suitable for
upstream sync.

[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[PATCH 2/4] [APIC] Allow disabling of UP APIC/IO-APIC by default, with command 
line option to turn it on.

[PATCH 3/4] [ATM] Add CPPFLAGS to byteorder.h check.

[PATCH 4/4] [HVCS] Select HVC_CONSOLE if HVCS is enabled.


 arch/i386/Kconfig   |   13 +
 Documentation/kernel-parameters.txt |3 +++
 arch/i386/Kconfig   |5 +
 arch/i386/kernel/apic.c |   13 +++--
 arch/i386/kernel/cpu/common.c   |   30 +-
 arch/i386/kernel/io_apic.c  |   10 +-
 drivers/atm/Makefile|3 +--
 drivers/char/Kconfig|2 +-
 include/asm-i386/apic.h |6 ++
 include/asm-i386/io_apic.h  |6 +-
 10 files changed, 83 insertions(+), 8 deletions(-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] late spinlock initialization in ieee1394/ohci

[Ben Collins]

Thanks Al. I'll commit this to our tree. Linus, feel free to apply this to
your tree.

Signed-off-by: Ben Collins <[EMAIL PROTECTED]>

On Thu, Aug 25, 2005 at 11:13:14PM +0100, Al Viro wrote:
> spinlock used in irq handler should be initialized before registering
> irq, even if we know that our device has interrupts disabled; handler
> is registered shared and taking spinlock is done unconditionally.  As
> it is, we can and do get oopsen on boot for some configuration, depending
> on irq routing - I've got a reproducer.
> 
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> 
> diff -urN RC13-rc7-base/drivers/ieee1394/ohci1394.c 
> current/drivers/ieee1394/ohci1394.c
> --- RC13-rc7-base/drivers/ieee1394/ohci1394.c 2005-08-24 01:56:37.0 
> -0400
> +++ current/drivers/ieee1394/ohci1394.c   2005-08-25 18:02:49.0 
> -0400
> @@ -478,7 +478,6 @@
>   int num_ports, i;
>  
>   spin_lock_init(&ohci->phy_reg_lock);
> - spin_lock_init(&ohci->event_lock);
>  
>   /* Put some defaults to these undefined bus options */
>   buf = reg_read(ohci, OHCI1394_BusOptions);
> @@ -3402,7 +3401,14 @@
>   /* We hopefully don't have to pre-allocate IT DMA like we did
>* for IR DMA above. Allocate it on-demand and mark inactive. */
>   ohci->it_legacy_context.ohci = NULL;
> + spin_lock_init(&ohci->event_lock);
>  
> + /*
> +  * interrupts are disabled, all right, but... due to SA_SHIRQ we
> +  * might get called anyway.  We'll see no event, of course, but
> +  * we need to get to that "no event", so enough should be initialized
> +  * by that point.
> +  */
>   if (request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ,
>OHCI1394_DRIVER_NAME, ohci))
>   FAIL(-ENOMEM, "Failed to allocate shared interrupt %d", 
> dev->irq);

-- 
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alternative [PATCH] 1/2) drivers/ieee1394/: schedule unused EXPORT_SYMBOL's for removal

[Ben Collins]

Applied, but I set the default to "N". No reason to prolong doing it,
since it doesn't break anything in the kernel or in our tree. It's an easy
pointer to the option for anyone inquiring about the change.

On Sat, Jul 09, 2005 at 12:32:33PM +0200, Stefan Richter wrote:
> Ben Collins wrote:
> > Can we, instead of removing these, wrap then in a "Export full API" config
> > option? I've already got several reports from external projects that are
> > using most of these exported symbols, and I'd hate to make it harder on
> > them to use our drivers (for internal projects or otherwise).
> 
> OK, why not. Here is an alternative patch, split in two parts. The first
> part is independent of the second, although the 2nd motivates the 1st.
> 2nd part follows in a separate posting.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/ieee1394/: schedule unused EXPORT_SYMBOL's for removal

[Ben Collins]

On Sat, Jul 09, 2005 at 08:55:57PM +0200, Adrian Bunk wrote:
> On Sat, Jul 09, 2005 at 03:50:35AM -0400, Ben Collins wrote:
> 
> > Can we, instead of removing these, wrap then in a "Export full API" config
> > option? I've already got several reports from external projects that are
> 
> This will end in all distributions having this option enabled resulting 
> in no change compared to todays status quo.

Yeah, I've heard this over and over, but as someone who works with
distributing Linux, I can say it is utterly incorrect. Distributors are
looking to support as little as possible and make things as tight and
stable as possible. THe API is only there for people doing development
work of some sort, and those people are going to be building kernels from
scratch anyway. That's the people that will enable this option.

And if it's as you suggest, that there is so much demand on the
distributions by users to enable this option, then by all means that
should show that it needs to be there anyway, don't you think? Not only
that, the distributions could just as easily add patches to put them back,
in order to support it, so taking it out completely doesn't help anything.


> > using most of these exported symbols, and I'd hate to make it harder on
> > them to use our drivers (for internal projects or otherwise).
> 
> What are these external projects?
> 
> Is they are internal projects, re-adding the EXPORT_SYMBOL's should be 
> trivial for them.
> 
> If they aren't only internal internal project, why can't they simply be 
> merged (making all discussions about removal of the EXPORT_SYMBOL's they 
> use obsolete)?

These projects all fall in a lot of categories, from hobbyist, to
acedemics, to companies doing embedded systems (I've gotten feedback from
someone using linux1394 in next generation US fighter planes, and they
have some custom modules).

Allowing them to do as little changing to the kernel as possible makes
their life easier, and ensures that changes we get back are cleaner and
more useful. Plus for two of those three examples, they may be
distributing their work to classmates or other hobbyists. THis might be in
the way of a single driver file that can be compiled with a stock kernel,
and no one wants to say "oh, and you need to patch the ieee1394 drivers
before you can use my driver".

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alternative [PATCH] 1/2) drivers/ieee1394/: schedule unused EXPORT_SYMBOL's for removal

[Ben Collins]

Now that I can live with. If everyone else is ok with it, I'll apply it to
our tree for when I sync to Linus.

On Sat, Jul 09, 2005 at 12:32:33PM +0200, Stefan Richter wrote:
> Ben Collins wrote:
> > Can we, instead of removing these, wrap then in a "Export full API" config
> > option? I've already got several reports from external projects that are
> > using most of these exported symbols, and I'd hate to make it harder on
> > them to use our drivers (for internal projects or otherwise).
> 
> OK, why not. Here is an alternative patch, split in two parts. The first
> part is independent of the second, although the 2nd motivates the 1st.
> 2nd part follows in a separate posting.
> 
> - - - - - - - - - - - - 8< - - - - - - - - - - - -
> 
> IEEE 1394 subsystem: Wrap symbols that are neither used by the 1394 drivers in
> the mainline kernel (a.k.a. Linux1394) nor by dfg1394 (a.k.a the video-2-1394
> project) into a new configuration option. Switch this option on by default.
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> 
> 
> diff -ru linux-2.6.13-rc2.old/drivers/ieee1394/Kconfig 
> linux-2.6.13-rc2/drivers/ieee1394/Kconfig
> --- linux-2.6.13-rc2.old/drivers/ieee1394/Kconfig 2005-07-06 
> 05:46:33.0 +0200
> +++ linux-2.6.13-rc2/drivers/ieee1394/Kconfig 2005-07-09 12:01:32.0 
> +0200
> @@ -66,6 +66,18 @@
> with MacOSX and WinXP IP-over-1394), enable this option and the
> eth1394 option below.
>  
> +config IEEE1394_EXPORT_FULL_API
> + bool "Export all symbols of ieee1394's API"
> + depends on IEEE1394
> + default y
> + help
> +   Export all symbols of ieee1394's driver programming interface, even
> +   those that are not currently used by the standard IEEE 1394 drivers.
> +
> +   This option does not affect the interface to userspace applications.
> +   Say Y here if you want to compile externally developed drivers that
> +   make extended use of ieee1394's API. It is otherwise safe to say N.
> +
>  comment "Device Drivers"
>   depends on IEEE1394
>  
> diff -ru linux-2.6.13-rc2.old/drivers/ieee1394/ieee1394_core.c 
> linux-2.6.13-rc2/drivers/ieee1394/ieee1394_core.c
> --- linux-2.6.13-rc2.old/drivers/ieee1394/ieee1394_core.c 2005-07-06 
> 05:46:33.0 +0200
> +++ linux-2.6.13-rc2/drivers/ieee1394/ieee1394_core.c 2005-07-09 
> 11:53:25.0 +0200
> @@ -1223,9 +1223,7 @@
>  EXPORT_SYMBOL(hpsb_set_packet_complete_task);
>  EXPORT_SYMBOL(hpsb_alloc_packet);
>  EXPORT_SYMBOL(hpsb_free_packet);
> -EXPORT_SYMBOL(hpsb_send_phy_config);
>  EXPORT_SYMBOL(hpsb_send_packet);
> -EXPORT_SYMBOL(hpsb_send_packet_and_wait);
>  EXPORT_SYMBOL(hpsb_reset_bus);
>  EXPORT_SYMBOL(hpsb_bus_reset);
>  EXPORT_SYMBOL(hpsb_selfid_received);
> @@ -1233,6 +1231,10 @@
>  EXPORT_SYMBOL(hpsb_packet_sent);
>  EXPORT_SYMBOL(hpsb_packet_received);
>  EXPORT_SYMBOL_GPL(hpsb_disable_irm);
> +#ifdef CONFIG_IEEE1394_EXPORT_FULL_API
> +EXPORT_SYMBOL(hpsb_send_phy_config);
> +EXPORT_SYMBOL(hpsb_send_packet_and_wait);
> +#endif
>  
>  /** ieee1394_transactions.c **/
>  EXPORT_SYMBOL(hpsb_get_tlabel);
> @@ -1262,9 +1264,11 @@
>  EXPORT_SYMBOL(hpsb_set_hostinfo_key);
>  EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
>  EXPORT_SYMBOL(hpsb_set_hostinfo);
> +EXPORT_SYMBOL(highlevel_host_reset);
> +#ifdef CONFIG_IEEE1394_EXPORT_FULL_API
>  EXPORT_SYMBOL(highlevel_add_host);
>  EXPORT_SYMBOL(highlevel_remove_host);
> -EXPORT_SYMBOL(highlevel_host_reset);
> +#endif
>  
>  /** nodemgr.c **/
>  EXPORT_SYMBOL(hpsb_node_fill_packet);
> @@ -1272,7 +1276,9 @@
>  EXPORT_SYMBOL(hpsb_register_protocol);
>  EXPORT_SYMBOL(hpsb_unregister_protocol);
>  EXPORT_SYMBOL(ieee1394_bus_type);
> +#ifdef CONFIG_IEEE1394_EXPORT_FULL_API
>  EXPORT_SYMBOL(nodemgr_for_each_host);
> +#endif
>  
>  /** csr.c **/
>  EXPORT_SYMBOL(hpsb_update_config_rom);
> @@ -1309,19 +1315,21 @@
>  EXPORT_SYMBOL(hpsb_iso_recv_flush);
>  
>  /** csr1212.c **/
> -EXPORT_SYMBOL(csr1212_create_csr);
> -EXPORT_SYMBOL(csr1212_init_local_csr);
> -EXPORT_SYMBOL(csr1212_new_immediate);
>  EXPORT_SYMBOL(csr1212_new_directory);
> -EXPORT_SYMBOL(csr1212_associate_keyval);
>  EXPORT_SYMBOL(csr1212_attach_keyval_to_directory);
> -EXPORT_SYMBOL(csr1212_new_string_descriptor_leaf);
>  EXPORT_SYMBOL(csr1212_detach_keyval_from_directory);
>  EXPORT_SYMBOL(csr1212_release_keyval);
> -EXPORT_SYMBOL(csr1212_destroy_csr);
>  EXPORT_SYMBOL(csr1212_read);
> -EXPORT_SYMBOL(csr1212_generate_csr_image);
>  EXPORT_SYMBOL(csr1212_parse_keyval);
> -EXPORT_SYMBOL(csr1212_parse_csr);
>  EXPORT_SYMBOL(_csr1212_read_keyval);
>

Re: [2.6 patch] drivers/ieee1394/: schedule unused EXPORT_SYMBOL's for removal

[Ben Collins]

Can we, instead of removing these, wrap then in a "Export full API" config
option? I've already got several reports from external projects that are
using most of these exported symbols, and I'd hate to make it harder on
them to use our drivers (for internal projects or otherwise).

On Sat, Jul 09, 2005 at 09:22:38AM +0200, Stefan Richter wrote:
> On  9 Jul, Adrian Bunk wrote:
> > On Thu, Jul 07, 2005 at 09:30:21PM +0200, Stefan Richter wrote:
> >> Now that we are at it, the following EXPORT_SYMBOLs should be removed 
> >> too...
> >>_csr1212_read_keyval
> > used in sbp2.c
> >>_csr1212_destroy_keyval
> > used in raw1394.c
> 
> You are right.
> 
> 
> <--  snip  -->
> 
> 
> 
> This patch schedules unused EXPORT_SYMBOL's for removal.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> 
> ---
> 
>  Documentation/feature-removal-schedule.txt |   21 ++
>  drivers/ieee1394/ieee1394_core.c   |   31 +
>  2 files changed, 52 insertions(+)
> 
> --- linux-2.6.12-rc4-mm1-full/Documentation/feature-removal-schedule.txt.old  
> 2005-05-13 15:19:54.0 +0200
> +++ linux-2.6.12-rc4-mm1-full/Documentation/feature-removal-schedule.txt  
> 2005-05-13 15:29:24.0 +0200
> @@ -93,0 +94,21 @@
> +
> +---
> +
> +What:remove the following ieee1394 EXPORT_SYMBOL's:
> + - hpsb_send_phy_config
> + - hpsb_send_packet_and_wait
> + - highlevel_add_host
> + - highlevel_remove_host
> + - nodemgr_for_each_host
> + - csr1212_create_csr
> + - csr1212_init_local_csr
> + - csr1212_new_immediate
> + - csr1212_associate_keyval
> + - csr1212_new_string_descriptor_leaf
> + - csr1212_destroy_csr
> + - csr1212_generate_csr_image
> + - csr1212_parse_csr
> +When:August 2005
> +Files:   drivers/ieee1394/ieee1394_core.c
> +Why: No modular usage in the kernel.
> +Who: Adrian Bunk <[EMAIL PROTECTED]>
> --- linux-2.6.12-rc4-mm1-full/drivers/ieee1394/ieee1394_core.c.old
> 2005-05-13 15:19:34.0 +0200
> +++ linux-2.6.12-rc4-mm1-full/drivers/ieee1394/ieee1394_core.c
> 2005-05-13 15:28:17.0 +0200
> @@ -1226,7 +1226,13 @@
>  EXPORT_SYMBOL(hpsb_alloc_packet);
>  EXPORT_SYMBOL(hpsb_free_packet);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(hpsb_send_phy_config);
> +
>  EXPORT_SYMBOL(hpsb_send_packet);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(hpsb_send_packet_and_wait);
> +
>  EXPORT_SYMBOL(hpsb_reset_bus);
>  EXPORT_SYMBOL(hpsb_bus_reset);
> @@ -1265,6 +1271,11 @@
>  EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
>  EXPORT_SYMBOL(hpsb_set_hostinfo);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(highlevel_add_host);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(highlevel_remove_host);
> +
>  EXPORT_SYMBOL(highlevel_host_reset);
>  
> @@ -1275,4 +1286,6 @@
>  EXPORT_SYMBOL(hpsb_unregister_protocol);
>  EXPORT_SYMBOL(ieee1394_bus_type);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(nodemgr_for_each_host);
>  
> @@ -1312,18 +1325,36 @@
>  
>  /** csr1212.c **/
> +
> +/* EXPORT_SYMBOLs scheduled for removal */
>  EXPORT_SYMBOL(csr1212_create_csr);
>  EXPORT_SYMBOL(csr1212_init_local_csr);
>  EXPORT_SYMBOL(csr1212_new_immediate);
> +
>  EXPORT_SYMBOL(csr1212_new_directory);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(csr1212_associate_keyval);
> +
>  EXPORT_SYMBOL(csr1212_attach_keyval_to_directory);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(csr1212_new_string_descriptor_leaf);
> +
>  EXPORT_SYMBOL(csr1212_detach_keyval_from_directory);
>  EXPORT_SYMBOL(csr1212_release_keyval);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(csr1212_destroy_csr);
> +
>  EXPORT_SYMBOL(csr1212_read);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(csr1212_generate_csr_image);
> +
>  EXPORT_SYMBOL(csr1212_parse_keyval);
> +
> +/* EXPORT_SYMBOL scheduled for removal */
>  EXPORT_SYMBOL(csr1212_parse_csr);
> +
>  EXPORT_SYMBOL(_csr1212_read_keyval);
>  EXPORT_SYMBOL(_csr1212_destroy_keyval);
> 
> 
> 
> 
> ---
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> ___
> mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M

Re: OHCI driver dies on Mac Mini at boot

[Ben Collins]

generic driver version 2.4.2
> [   70.692139] PPP Deflate Compression module registered
> [   70.692337] MacIO PCI driver attached to Intrepid chipset
> [   70.692956] input: Macintosh mouse button emulation
> [   70.693211] apm_emu: APM Emulation 0.5 initialized.
> [   70.693421] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> [   70.693620] ide: Assuming 33MHz system bus speed for PIO modes; override 
> with idebus=xx
> [   70.693882] adb: starting probe task...
> [   70.694008] adb: finished probe task...
> [   70.694322] PCI: Enabling device 0002:20:0d.0 (0004 -> 0006)
> [   71.706181] ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
> [   71.706404] Probing IDE interface ide0...
> [   71.970334] hda: TOSHIBA MK8025GAS, ATA DISK drive
> [   72.378303] hdb: MATSHITACD-RW CW-8123, ATAPI CD/DVD-ROM drive
> [   72.429131] hda: Enabling Ultra DMA 5
> [   72.430274] hdb: Enabling Ultra DMA 2
> [   72.431454] ide0 at 0xa101a000-0xa101a007,0xa101a160 on irq 39
> [   73.090239] eth0: Link is up at 100 Mbps, full-duplex.
> [   73.443069] ide1: Found Apple KeyLargo ATA-3 controller, bus ID 0, irq 24
> [   73.443287] Probing IDE interface ide1...
> [   73.962026] ide1: Bus empty, interface released.
> [   73.962215] hda: max request size: 1024KiB
> [   74.216212] hda: 156301488 sectors (80026 MB), CHS=16383/255/63, UDMA(100)
> [   74.216523] hda: cache flushes supported
> [   74.216723]  hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8
> [   74.282414] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
> [   74.282712] Uniform CD-ROM driver Revision: 3.20
> [   74.284641] ide-floppy driver 0.99.newide
> [   74.284893] mesh: configured for synchronous 5 MB/s
> [   74.285105] st: Version 20041025, fixed bufsize 32768, s/g segs 256
> [   74.285418] usbmon: debugs is not available
> [   74.285553] ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) 
> Driver (PCI)
> [   74.285592] Apple USB OHCI 0001:10:18.0 disabled by firmware
> [   74.285773] Apple USB OHCI 0001:10:19.0 disabled by firmware
> [   74.285954] PCI: Enabling device 0001:10:1a.0 ( -> 0002)
> [   74.295306] ohci_hcd 0001:10:1a.0: Apple Computer Inc. KeyLargo/Intrepid 
> USB (#3)
> [   74.304588] ohci_hcd 0001:10:1a.0: new USB bus registered, assigned bus 
> number 1
> [   74.313747] ohci_hcd 0001:10:1a.0: irq 29, io mem 0x80083000
> [   74.353116] hub 1-0:1.0: USB hub found
> [   74.362232] hub 1-0:1.0: 2 ports detected
> [   74.392029] PCI: Enabling device 0001:10:1b.0 ( -> 0002)
> [   74.401126] ohci_hcd 0001:10:1b.0: NEC Corporation USB
> [   74.410400] ohci_hcd 0001:10:1b.0: new USB bus registered, assigned bus 
> number 2
> [   74.419646] ohci_hcd 0001:10:1b.0: irq 63, io mem 0x80082000
> [   74.459072] hub 2-0:1.0: USB hub found
> [   74.468330] hub 2-0:1.0: 3 ports detected
> [   74.498025] PCI: Enabling device 0001:10:1b.1 ( -> 0002)
> [   74.507405] ohci_hcd 0001:10:1b.1: NEC Corporation USB (#2)
> [   74.516803] ohci_hcd 0001:10:1b.1: new USB bus registered, assigned bus 
> number 3
> [   74.526190] ohci_hcd 0001:10:1b.1: irq 63, io mem 0x80081000
> [   74.566061] hub 3-0:1.0: USB hub found
> [   74.575288] hub 3-0:1.0: 2 ports detected
> [   74.662013] usbcore: registered new driver usbhid
> [   74.671081] drivers/usb/input/hid-core.c: v2.01:USB HID core driver
> [   74.680311] mice: PS/2 mouse device common for all mice
> [   74.689528] oprofile: using timer interrupt.
> [   74.698770] NET: Registered protocol family 2
> [   74.718042] IP: routing cache hash table of 4096 buckets, 32Kbytes
> [   74.727650] TCP established hash table entries: 131072 (order: 8, 1048576 
> bytes)
> [   74.739914] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> [   74.749784] TCP: Hash tables configured (established 131072 bind 65536)
> [   74.759471] NET: Registered protocol family 1
> [   74.768982] NET: Registered protocol family 17
> [   74.788984] usb 2-1: new low speed USB device using ohci_hcd and address 2
> [   74.798912] EXT3-fs: INFO: recovery required on readonly filesystem.
> [   74.808580] EXT3-fs: write access will be enabled during recovery.
> [   74.935605] input: USB HID v1.10 Mouse [Microsoft Basic Optical Mouse] on 
> usb-0001:10:1b.0-1
> [   74.977829] kjournald starting.  Commit interval 5 seconds
> [   74.987617] EXT3-fs: recovery complete.
> [   74.998266] EXT3-fs: mounted filesystem with ordered data mode.
> [   75.007984] VFS: Mounted root (ext3 filesystem) readonly.
> [   75.017680] Freeing unused kernel memory: 176k init 4k chrp 8k prep
> [   75.229947] usb 3-1: new low speed USB device using ohci_hcd and address 2
> [   75.401614] input: USB HID v1.10 Keyboard [Logitech USB Receiver] on 
> usb-0001:10:1b.1-1

Re: asm/unistd.h

[Ben Collins]

On Thu, Apr 05, 2001 at 09:58:43AM -0300, Sarda?ons, Eliel wrote:
> I'm taking a look at the linux code and I don't understand how do you
> programm...mmm (?) may be i'm a stupid why in include/asm/unistd.h in some
> macros you use this:
> 
> do {
> ...
> } while (0)

Imagine a macro of several lines of code like:

#define FOO(x) \
printf("arg is %s\n", x); \
do_something_useful(x);

Now imagine using it like:

if (blah == 2)
FOO(blah);

This interprets to

if (blah == 2)
printf("arg is %s\n", blah);
do_something_useful(blah);;

As you can see, the "if" then only encompasses the printf, and the
do_something_useful() call is unconditional (not within the scope of the
if), like you wanted it.

So, by using a block like do{...}while(0), you would get this:

if (blah == 2)
do {
printf("arg is %s\n", blah);
do_something_useful(blah);
} while (0);

Which is exactly what you want.

-- 
 -------===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)

[Ben Collins]

On Fri, Mar 02, 2001 at 04:31:07PM +, Russell King wrote:
> [EMAIL PROTECTED] writes:
> > Russel, you are warned that kernels<2.2.17 and rsync is an incompatible
> > combination.
> 
> So, what you're saying is that because these kernels have known problems
> with rsync, the fact that my symptoms on 2.4.0 are 100% _precisely_ the
> same means its not the same bug?

Well, I can tell you that going from a 2.4.2pre2 sparc64 box via rsync
over ssh to a 2.4.2 or 2.4.1-pre8 i686 gives me the same problems.

However with slight differences. With the 2.4.1-pre8 kernel on the i686
I see "protocol error, different version of rsync?", and with the 2.4.2
kernel I get segv's in the remote rsync (I'm running the rsync -e ssh
from the sparc64).

Both systems are running IDE, ext2 only on both, no special config
options (pretty bare to be honest).

So no, this is not a 2.2.x interaction bug.

-- 
 ---===-=-======-=====---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in large files ext2 in 2.4.0-test11 ?

[Ben Collins]

> 
>   Just for comparison, RedHat delivers glibc compiled with
>   2.3.nn/2.4.0 headers -> newer interfaces are supported.
> 

Let's not even get started on what RH did or did not do. If everyone did
what RH did, then everyone else can just roll over and die, since there
will be no difference between dists.

On top of that, let's take this off the l-k list, since it has no bearing
here.

-- 
 ---===-=-==-=---=--------=-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Bug in large files ext2 in 2.4.0-test11 ?

[Ben Collins]

On Mon, Nov 20, 2000 at 07:32:39PM +, Petr Vandrovec wrote:
> On 20 Nov 00 at 13:19, Ben Collins wrote:
> > 
> > Does kernel 2.4.x compile and run well for all of our supported archs?
> 
> AFAIK yes. At least on all Debian archs.

So, sparc, ultrasparc, i386 (with pcmcia support), alpha, arm, m68k,
powerpc? I know that mips, s390 and hppa almost require a 2.4.0 kernel,
even if they aren't stable yet. But the other ports are more important,
because we released them already, so we have a certain status quo to keep
them working well.

Anyway, this isn't a major point.

> > Do programs compiled against a glibc with LFS (2.4.x kernel) support, and
> > using that LFS support, work on kernel 2.2.x machines?
> 
> Yes. Even glibc (2.2) compiled against kernel without LFS support has LFS
> interface. Of course limited to 2GB files only.

On some platforms...

E.g. I can already access > 2gig files on my ultrasparc :)

> > Secondly, anyone who thinks they know what they are doing, can simply
> > download the Debian glibc sources files, and build against kernel-2.4.0
> > headers with this simple command:
> > 
> > LINUX_SOURCE=/usr/src/linux-2.4.0-test11 apt-get -b source glibc
> > 
> > Simple, eh? :)
> 
> But time consuming... If you already invested CPU power to compile
> that large beast...

Well, patience is a virtue. Right now we don't have it in Debian for some
very good reasons. We just transitioned to a new glibc (2.2 is there, and
it works almost flawlessly, thanks to the glibc folks). Next step is gcc3
and kernel 2.4. Both of those combined promise to introduce some new and
exciting bugs and conflicts. We can't just "dump them in there". We'de
rather make a sane migration, test upgrades from previous versions, and
work in our transition mechanisms. IOW, we don't have to just worry about
1 architecture and 1 distribution, we have to make sure upgrades work,
make sure things don't break, and ensure backward compatibility is retained
for 5 architectures that have released already (new archs don't need a
transisition obviously).

That's a large undertaking, but the good thing is, in the end, the wait
will be worth it to our users. People wont be stuck with Debian 2.2,
simply because they can't do a decent upgrade to 2.3, when that releases.

The issue is already known, and yes it will get done in time. Getting all
strung out about a kernel that isn't even released stable yet, is not
going to help :)

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/