Re: [RFC][PATCH] uli526x: Add suspend and resume routines (updated)
Rafael J. Wysocki wrote:
On Wednesday, 8 August 2007 00:26, Jeff Garzik wrote:
Rafael J. Wysocki wrote:
On Tuesday, 7 August 2007 23:40, Jeff Garzik wrote:
I'll let our new tulip maintainer see what he thinks about the
implementation. Seems fairly sane to me, but should at least get an "it
works" test.
It has been tested, as stated in the changelog, and works (on my test system).
Apologies, I missed this. I'll look to our new tulip maintainer to
queue your resent patch, or at least ACK it...
OK
Below is the updated version. It's functionally equivalent to the previous one.
Greetings,
Rafael
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Add suspend/resume support to the uli526x network driver (tested on x86_64,
with 'Ethernet controller: ALi Corporation M5263 Ethernet Controller, rev 40').
This patch is based on the suspend/resume code in the tg3 driver.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/net/tulip/uli526x.c | 109 +---
1 file changed, 103 insertions(+), 6 deletions(-)
Index: linux-2.6.23-rc2/drivers/net/tulip/uli526x.c
===
--- linux-2.6.23-rc2.orig/drivers/net/tulip/uli526x.c
+++ linux-2.6.23-rc2/drivers/net/tulip/uli526x.c
@@ -1110,19 +1110,15 @@ static void uli526x_timer(unsigned long
/*
- * Dynamic reset the ULI526X board
* Stop ULI526X board
* Free Tx/Rx allocated memory
- * Reset ULI526X board
- * Re-initialize ULI526X board
+ * Init system variable
*/
-static void uli526x_dynamic_reset(struct net_device *dev)
+static void uli526x_reset_prepare(struct net_device *dev)
{
struct uli526x_board_info *db = netdev_priv(dev);
- ULI526X_DBUG(0, "uli526x_dynamic_reset()", 0);
-
/* Sopt MAC controller */
db->cr6_data &= ~(CR6_RXSC | CR6_TXSC); /* Disable Tx/Rx */
update_cr6(db->cr6_data, dev->base_addr);
@@ -1141,6 +1137,22 @@ static void uli526x_dynamic_reset(struct
db->link_failed = 1;
db->init=1;
db->wait_reset = 0;
+}
+
+
+/*
+ * Dynamic reset the ULI526X board
+ * Stop ULI526X board
+ * Free Tx/Rx allocated memory
+ * Reset ULI526X board
+ * Re-initialize ULI526X board
+ */
+
+static void uli526x_dynamic_reset(struct net_device *dev)
+{
+ ULI526X_DBUG(0, "uli526x_dynamic_reset()", 0);
+
+ uli526x_reset_prepare(dev);
/* Re-initialize ULI526X board */
uli526x_init(dev);
@@ -1150,6 +1162,89 @@ static void uli526x_dynamic_reset(struct
}
+#ifdef CONFIG_PM_SLEEP
+
+/*
+ * Suspend the interface.
+ */
+
+static int uli526x_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+ pci_power_t power_state;
+ int err;
+
+ ULI526X_DBUG(0, "uli526x_suspend", 0);
+
+ if (!(dev && netdev_priv(dev)))
+ return 0;
+static int uli526x_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+ struct uli526x_board_info *db = netdev_priv(dev);
+ int err;
+
+ ULI526X_DBUG(0, "uli526x_resume", 0);
+
+ if (!(dev && db))
+ return 0;
Two comments:
1) Like akpm, the CONFIG_PM_SLEEP is out of place. All other drivers
use CONFIG_PM
2) just remove the !dev checks, that is an impossible condition
-
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] xen-netfront: remove dead code
Jeremy Fitzhardinge wrote: This patch removes some residual dead code left over from removing the "flip" receive mode. This patch doesn't change the generated output at all, since gcc already realized it was dead. This resolves the "regression" reported by Adrian. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Adrian Bunk <[EMAIL PROTECTED]> Cc: Michal Piotrowski <[EMAIL PROTECTED]> applied - 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: thermal: create "thermal.off=1" to disable ACPI thermal support
On Sunday 12 August 2007 14:49, Randy Dunlap wrote: > On Sun, 12 Aug 2007 10:59:11 GMT Linux Kernel Mailing List wrote: > > > Gitweb: > > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=72b33ef8bb1ac7f6c5a16d23304ab25ddc73d93d > > Commit: 72b33ef8bb1ac7f6c5a16d23304ab25ddc73d93d > > Parent: 3864e8ccbba1dcdea87398ab80fdc8ae0fab7c45 > > Author: Len Brown <[EMAIL PROTECTED]> > > AuthorDate: Sun Aug 12 00:12:17 2007 -0400 > > Committer: Len Brown <[EMAIL PROTECTED]> > > CommitDate: Sun Aug 12 00:12:17 2007 -0400 > > > > ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support > > > > "thermal.off=1" disables all ACPI thermal support at boot time. > > > > CONFIG_ACPI_THERMAL=n can do this at build time. > > "# rmmod thermal" can do this at run time, > > as long as thermal is built as a module. > > > > WARNING: On some systems, disabling ACPI thermal support > > will cause the system to run hotter and reduce the > > lifetime of the hardware. > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > --- > > Documentation/kernel-parameters.txt |3 +++ > > drivers/acpi/thermal.c |9 - > > 2 files changed, 11 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c > > index 5a62de1..61337d9 100644 > > --- a/drivers/acpi/thermal.c > > +++ b/drivers/acpi/thermal.c > > @@ -78,6 +78,10 @@ static int tzp; > > module_param(tzp, int, 0); > > MODULE_PARM_DESC(tzp, "Thermal zone polling frequency, in 1/10 > > seconds.\n"); > > > > +static int off; > > +module_param(off, int, 0); > > +MODULE_PARM_DESC(off, "Set to disable ACPI thermal support.\n"); > > + > > static int acpi_thermal_add(struct acpi_device *device); > > static int acpi_thermal_remove(struct acpi_device *device, int type); > > static int acpi_thermal_resume(struct acpi_device *device); > > Hi, > > What's the purpose of the "\n" in the MODULE_PARM_DESC() string? > > modinfo already terminates module parameter listings with a newline > after each parameter description. Some people insert newlines inside > these strings for pretty printing (which I don't find necessary), > but using a newline at the end of the string only makes the > parameter type (that is added by modinfo) appear on a separate line, > which IMO is worse that having it appear at the end of the parameter > line. E.g., > > $ modinfo -p asus_acpi.ko > asus_uid:UID for entries in /proc/acpi/asus. > > asus_gid:GID for entries in /proc/acpi/asus. > > $ > > but when the newline is omitted, it would be printed as > > $ modinfo -p asus_acpi.ko > asus_uid:UID for entries in /proc/acpi/asus. > asus_gid:GID for entries in /proc/acpi/asus. > $ > > > or when -p is not used (but only showing the parm lines here): > > $ modinfo asus_acpi.ko > parm: asus_gid:GID for entries in /proc/acpi/asus. > (uint) > parm: asus_uid:UID for entries in /proc/acpi/asus. > (uint) > $ > > or if the newline is not used in the string: > > $ modinfo asus_acpi.ko > parm: asus_gid:GID for entries in /proc/acpi/asus. (uint) > parm: asus_uid:UID for entries in /proc/acpi/asus. (uint) > $ > > where I posit that the latter is better than the former... Thanks for pointing this out, Randy. I agree, and have deleted the trailing newlines. -Len - 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] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
Jeremy Fitzhardinge wrote: xennet_tx_bug_gc can free the skb before we use it, so make sure we don't. Jeff, this is -rc material. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> applied - 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] drivers/net/3c505: Convert to generic boolean
Richard Knutsson wrote: Convert to generic boolean Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64) Diffed against Linus' git-tree. Sent 2007-05-01, no replys applied - 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] drivers/net/tokenring: Convert to generic boolean
Richard Knutsson wrote: Convert to generic boolean Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64) Diffed against Linus' git-tree. Sent 2007-05-01, no replys applied - 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: drivers/net/tokenring/3c359.c
Surya Prabhakar N wrote: Hi, Replacing kmalloc with kzalloc and cleaning up memset in drivers/net/tokenring/3c359.c Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]> applied - 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 12/13] cxgb3 - log and clear PEX errors
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Clear pciE PEX errors late at module load time. Log details when PEX errors occur. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/t3_hw.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) ACK 10-12 - 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 13/13] cxgb3 - test MSI capabilities
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Check that the HW in really in MSI/MSI-X mode when it was succesfully enabled. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/cxgb3_main.c | 42 drivers/net/cxgb3/regs.h |4 2 files changed, 46 insertions(+), 0 deletions(-) we really don't need to be adding this to each driver - 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 9/13] cxgb3 - Update internal memory management
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Set PM1 internal memory to round robin mode Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> why? - 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 8/13] cxgb3 - log adapter derial number
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Log HW serial number when cxgb3 module is loaded. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/common.h |2 ++ drivers/net/cxgb3/cxgb3_main.c |6 -- drivers/net/cxgb3/t3_hw.c |3 ++- 3 files changed, 8 insertions(+), 3 deletions(-) ACK patches 6-8 - 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/13] cxgb3 - Expose HW memory page info
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Let the RDMA driver get HW page info to work around HW issues. Assign explicit enum values. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> "HW issues" -- you need to go into far more detail, when adding a new interface. what hw issues? why was this the best/only 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: [PATCH 4/13] cxgb3 - use immediate data for offload Tx
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Send small TX_DATA work requests as immediate data even when there are fragments. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/sge.c | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) needs additional explanation. don't just describe the new post-change behavior, describe why this change is needed. - 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/24] make atomic_read() behave consistently on frv
Chris Snook wrote: David Howells wrote: Chris Snook <[EMAIL PROTECTED]> wrote: cpu_relax() contains a barrier, so it should do the right thing. For non-smp architectures, I'm concerned about interacting with interrupt handlers. Some drivers do use atomic_* operations. I'm not sure that actually answers my question. Why not smp_rmb()? David I would assume because we want to waste time efficiently even on non-smp architectures, rather than frying the CPU or draining the battery. Certain looping execution patterns can cause the CPU to operate above thermal design power. I have fans on my workstation that only ever come on when running LINPACK, and that's generally memory bandwidth-bound. Just imagine what happens when you're executing the same few non-serializing instructions in a tight loop without ever stalling on memory fetches, or being scheduled out. If there's another reason, I'd like to hear it too, because I'm just guessing here. Well if there is only one memory location involved, then smp_rmb() isn't going to really do anything anyway, so it would be incorrect to use it. Consider that smp_rmb basically will do anything from flushing the pipeline to invalidating loads speculatively executed out of order. AFAIK it will not control the visibility of stores coming from other CPUs (that is up to the cache coherency). -- SUSE Labs, Novell Inc. - 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/13] cxgb3 - SGE doorbell overflow warning
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Log doorbell Fifo overflow Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/regs.h |8 drivers/net/cxgb3/sge.c |4 2 files changed, 12 insertions(+), 0 deletions(-) ACK, but not applied since patch #2 was not applied - 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/13] cxgb3 - Update rx coalescing length
Divy Le Ray wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Set max Rx coalescing length to 12288
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index c46c249..55922ed 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -104,7 +104,7 @@ enum {
PROTO_SRAM_LINES = 128, /* size of TP sram */
};
-#define MAX_RX_COALESCING_LEN 16224U
+#define MAX_RX_COALESCING_LEN 12288U
neither the patch nor description explains -why-
-
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/13] cxgb3 - MAC workaround update
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Update the MAC workaround to deal with switches that do not honor pause frames. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/common.h |1 + drivers/net/cxgb3/xgmac.c | 22 +++--- 2 files changed, 12 insertions(+), 11 deletions(-) applied - 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] hres_timers_resume must block interrupts
On Mon, 2007-08-13 at 19:26 -0400, Joe Korty wrote:
> Retrigger_next_event() must be called with interrupts disabled.
>
> All internal (to hrtimer.c) uses of retrigger_next_event() are correct.
> But the version exported to other files, hres_timers_resume(), does not
> do the IRQ blocking, nor does the (single) external caller of it.
>
> Rather than require that users of hres_timers_resume() do the IRQ blocking,
> this patch makes the blocking part of the hres_timers_resume() functionality.
Ack.
> (Also remove the meaningless WARN_ON_ONCE() call in hres_timers_resume)
It's not that meaningless. It catched a resume order problem some time
ago.
tglx
> Signed-off-by: Joe Korty ([EMAIL PROTECTED])
>
> Index: 2.6.23-rc3/kernel/hrtimer.c
> ===
> --- 2.6.23-rc3.orig/kernel/hrtimer.c 2007-08-13 18:30:09.0 -0400
> +++ 2.6.23-rc3/kernel/hrtimer.c 2007-08-13 18:38:48.0 -0400
> @@ -463,10 +463,11 @@
> */
> void hres_timers_resume(void)
> {
> - WARN_ON_ONCE(num_online_cpus() > 1);
> + unsigned long flags;
>
> - /* Retrigger the CPU local events: */
> + local_irq_save(flags);
> retrigger_next_event(NULL);
> + local_irq_restore(flags);
> }
>
> /*
>
-
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/24] make atomic_read() behave consistently on frv
Paul E. McKenney wrote:
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney <[EMAIL PROTECTED]> wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
handlers. Some drivers do use atomic_* operations.
What problems with interrupt handlers? Access to int/long must
be atomic or we're in big trouble anyway.
Reordering due to compiler optimizations. CPU reordering does not
affect interactions with interrupt handlers on a given CPU, but
reordering due to compiler code-movement optimization does. Since
volatile can in some cases suppress code-movement optimizations,
it can affect interactions with interrupt handlers.
If such reordering matters, then you should use one of the
*mb macros or barrier() rather than relying on possibly
hidden volatile cast.
If communicating among CPUs, sure. However, when communicating between
mainline and interrupt/NMI handlers on the same CPU, the barrier() and
most expecially the *mb() macros are gross overkill. So there really
truly is a place for volatile -- not a large place, to be sure, but a
place nonetheless.
I really would like all volatile users to go away and be replaced
by explicit barriers. It makes things nicer and more explicit... for
atomic_t type there probably aren't many optimisations that can be
made which volatile would disallow (in actual kernel code), but for
others (eg. bitops, maybe atomic ops in UP kernels), there would be.
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
Many atomic operations are allowed to be reordered between CPUs, so
I don't have a good idea for the rationale to order them within the
CPU (also loads and stores to long and ptr types are not ordered like
this, although we do consider those to be atomic operations too).
barrier() in a way is like enforcing sequential memory ordering
between process and interrupt context, wheras volatile is just
enforcing coherency of a single memory location (and as such is
cheaper).
What do you think of this crazy idea?
/* Enforce a compiler barrier for only operations to location X.
* Call multiple times to provide an ordering between multiple
* memory locations. Other memory operations can be assumed by
* the compiler to remain unchanged and may be reordered
*/
#define order(x) asm volatile("" : "+m" (x))
--
SUSE Labs, Novell Inc.
-
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] [28/2many] MAINTAINERS - ACPI VIDEO DRIVER
On Tue, 2007-08-14 at 13:21 +0800, Zhang, Rui wrote: > I can take charge of the ACPI video driver. Glad to hear it. ACPI VIDEO DRIVER P: Rui Zhang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://acpi.sourceforge.net/ S: Supported F: drivers/acpi/video.c - 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] [28/2many] MAINTAINERS - ACPI VIDEO DRIVER
On Tue, 2007-08-14 at 01:16 -0400, Len Brown wrote: > as Luming has moved onto other things, and Rui is shy > about being in MAINTAINERS as yet... Please update to > P:Len Brown > M:[EMAIL PROTECTED] ACPI VIDEO DRIVER P: Len Brown M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://acpi.sourceforge.net/ S: Supported F: drivers/acpi/video.c - 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/
[Fwd: Re: [PATCH] PSS(proportional set size) accounting in smaps]
I keep forgetting to check that you are on the cc. My email client
loves dropping you from the to/cc list.
Original Message
Subject: Re: [PATCH] PSS(proportional set size) accounting in smaps
Date: Tue, 14 Aug 2007 10:56:12 +0530
From: Balbir Singh <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: IBM
To: Andrew Morton <[EMAIL PROTECTED]>, Matt Mackall <[EMAIL PROTECTED]>, John
Berthels <[EMAIL PROTECTED]>, linux-kernel
References: <[EMAIL PROTECTED]>
Fengguang Wu wrote:
> The "proportional set size" (PSS) of a process is the count of pages it has in
> memory, where each page is divided by the number of processes sharing it. So
> if
> a process has 1000 pages all to itself, and 1000 shared with one other
> process,
> its PSS will be 1500.
>- lwn.net: "ELC: How much memory are applications really
> using?"
>
> The PSS proposed by Matt Mackall is a very nice metic for measuring an
> process's
> memory footprint. So collect and export it via /proc//smaps.
>
> Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the job,
> providing pretty much details. But for PSS, let's do it in a simple way.
>
> Cc: Matt Mackall <[EMAIL PROTECTED]>
> Cc: John Berthels <[EMAIL PROTECTED]>
> Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
I like the idea of moving towards PSS. I had sent some patches back in December
last year
http://marc.info/?l=linux-mm=116738715329816=4
> ---
> fs/proc/task_mmu.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> --- linux-2.6.23-rc2-mm2.orig/fs/proc/task_mmu.c
> +++ linux-2.6.23-rc2-mm2/fs/proc/task_mmu.c
> @@ -319,6 +319,7 @@ const struct file_operations proc_maps_o
> struct mem_size_stats
> {
> unsigned long resident;
> + u64 pss; /* proportional set size: my share of rss */
> unsigned long shared_clean;
> unsigned long shared_dirty;
> unsigned long private_clean;
> @@ -341,6 +342,7 @@ static int smaps_pte_range(pmd_t *pmd, u
> pte_t *pte, ptent;
> spinlock_t *ptl;
> struct page *page;
> + int mapcount;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> @@ -357,16 +359,19 @@ static int smaps_pte_range(pmd_t *pmd, u
> /* Accumulate the size in pages that have been accessed. */
> if (pte_young(ptent) || PageReferenced(page))
> mss->referenced += PAGE_SIZE;
> - if (page_mapcount(page) >= 2) {
> + mapcount = page_mapcount(page);
> + if (mapcount >= 2) {
This accounting is of-course racy. Mapcount can change any moment.
> if (pte_dirty(ptent))
> mss->shared_dirty += PAGE_SIZE;
> else
> mss->shared_clean += PAGE_SIZE;
> + mss->pss += (PAGE_SIZE << 12) / mapcount;
> } else {
> if (pte_dirty(ptent))
> mss->private_dirty += PAGE_SIZE;
> else
> mss->private_clean += PAGE_SIZE;
> + mss->pss += (PAGE_SIZE << 12);
> }
> }
> pte_unmap_unlock(pte - 1, ptl);
> @@ -395,18 +400,20 @@ static int show_smap(struct seq_file *m,
> seq_printf(m,
> "Size: %8lu kB\n"
> "Rss:%8lu kB\n"
> +"Pss:%8lu kB\n"
> "Shared_Clean: %8lu kB\n"
> "Shared_Dirty: %8lu kB\n"
> "Private_Clean: %8lu kB\n"
> "Private_Dirty: %8lu kB\n"
> "Referenced: %8lu kB\n",
> (vma->vm_end - vma->vm_start) >> 10,
> -sarg.mss.resident >> 10,
> +sarg.mss.resident >> 10,
> +(unsigned long)(mss->pss >> 22),
> sarg.mss.shared_clean >> 10,
> sarg.mss.shared_dirty >> 10,
> sarg.mss.private_clean >> 10,
> sarg.mss.private_dirty >> 10,
> -sarg.mss.referenced >> 10);
> +sarg.mss.referenced>> 10);
>
> return ret;
> }
>
If we are reasonably sure that mapping will not change at the time
of page_rmap_x() operations, we could handle shared accounting
at those points and implement accurate shared accounting.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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] PSS(proportional set size) accounting in smaps
Fengguang Wu wrote:
> The "proportional set size" (PSS) of a process is the count of pages it has in
> memory, where each page is divided by the number of processes sharing it. So
> if
> a process has 1000 pages all to itself, and 1000 shared with one other
> process,
> its PSS will be 1500.
>- lwn.net: "ELC: How much memory are applications really
> using?"
>
> The PSS proposed by Matt Mackall is a very nice metic for measuring an
> process's
> memory footprint. So collect and export it via /proc//smaps.
>
> Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the job,
> providing pretty much details. But for PSS, let's do it in a simple way.
>
> Cc: Matt Mackall <[EMAIL PROTECTED]>
> Cc: John Berthels <[EMAIL PROTECTED]>
> Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
I like the idea of moving towards PSS. I had sent some patches back in December
last year
http://marc.info/?l=linux-mm=116738715329816=4
> ---
> fs/proc/task_mmu.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> --- linux-2.6.23-rc2-mm2.orig/fs/proc/task_mmu.c
> +++ linux-2.6.23-rc2-mm2/fs/proc/task_mmu.c
> @@ -319,6 +319,7 @@ const struct file_operations proc_maps_o
> struct mem_size_stats
> {
> unsigned long resident;
> + u64 pss; /* proportional set size: my share of rss */
> unsigned long shared_clean;
> unsigned long shared_dirty;
> unsigned long private_clean;
> @@ -341,6 +342,7 @@ static int smaps_pte_range(pmd_t *pmd, u
> pte_t *pte, ptent;
> spinlock_t *ptl;
> struct page *page;
> + int mapcount;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> @@ -357,16 +359,19 @@ static int smaps_pte_range(pmd_t *pmd, u
> /* Accumulate the size in pages that have been accessed. */
> if (pte_young(ptent) || PageReferenced(page))
> mss->referenced += PAGE_SIZE;
> - if (page_mapcount(page) >= 2) {
> + mapcount = page_mapcount(page);
> + if (mapcount >= 2) {
This accounting is of-course racy. Mapcount can change any moment.
> if (pte_dirty(ptent))
> mss->shared_dirty += PAGE_SIZE;
> else
> mss->shared_clean += PAGE_SIZE;
> + mss->pss += (PAGE_SIZE << 12) / mapcount;
> } else {
> if (pte_dirty(ptent))
> mss->private_dirty += PAGE_SIZE;
> else
> mss->private_clean += PAGE_SIZE;
> + mss->pss += (PAGE_SIZE << 12);
> }
> }
> pte_unmap_unlock(pte - 1, ptl);
> @@ -395,18 +400,20 @@ static int show_smap(struct seq_file *m,
> seq_printf(m,
> "Size: %8lu kB\n"
> "Rss:%8lu kB\n"
> +"Pss:%8lu kB\n"
> "Shared_Clean: %8lu kB\n"
> "Shared_Dirty: %8lu kB\n"
> "Private_Clean: %8lu kB\n"
> "Private_Dirty: %8lu kB\n"
> "Referenced: %8lu kB\n",
> (vma->vm_end - vma->vm_start) >> 10,
> -sarg.mss.resident >> 10,
> +sarg.mss.resident >> 10,
> +(unsigned long)(mss->pss >> 22),
> sarg.mss.shared_clean >> 10,
> sarg.mss.shared_dirty >> 10,
> sarg.mss.private_clean >> 10,
> sarg.mss.private_dirty >> 10,
> -sarg.mss.referenced >> 10);
> +sarg.mss.referenced>> 10);
>
> return ret;
> }
>
If we are reasonably sure that mapping will not change at the time
of page_rmap_x() operations, we could handle shared accounting
at those points and implement accurate shared accounting.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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] [28/2many] MAINTAINERS - ACPI VIDEO DRIVER
Hi, Len, I can take charge of the ACPI video driver. Thanks, Rui -Original Message- From: Len Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 1:16 PM To: [EMAIL PROTECTED]; Zhang, Rui Cc: [EMAIL PROTECTED]; Yu, Luming; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] [28/2many] MAINTAINERS - ACPI VIDEO DRIVER On Monday 13 August 2007 02:22, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index b159b00..4faf1ce 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -300,6 +300,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > S: Supported > +F: drivers/acpi/video.c Acked-by: Len Brown <[EMAIL PROTECTED]> Also, as Luming has moved onto other things, and Rui is shy about being in MAINTAINERS as yet... Please update to P: Len Brown M: [EMAIL PROTECTED] while you are there. thanks, -Len > ADM1025 HARDWARE MONITOR DRIVER > P: Jean Delvare > - > 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/ > - 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] [28/2many] MAINTAINERS - ACPI VIDEO DRIVER
On Monday 13 August 2007 02:22, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index b159b00..4faf1ce 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -300,6 +300,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > S: Supported > +F: drivers/acpi/video.c Acked-by: Len Brown <[EMAIL PROTECTED]> Also, as Luming has moved onto other things, and Rui is shy about being in MAINTAINERS as yet... Please update to P: Len Brown M: [EMAIL PROTECTED] while you are there. thanks, -Len > ADM1025 HARDWARE MONITOR DRIVER > P: Jean Delvare > - > 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/ > - 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/
ACPI patch for 2.6.23-rc3
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This will update the file shown below -- fixing a 2.6.23-rc3 regression. thanks! -Len ps. individual patches are available on [EMAIL PROTECTED] and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.23/acpi-release-20070126-2.6.23-rc3.diff.gz drivers/acpi/ec.c | 17 + 1 file changed, 17 insertions(+) through these commits: Alexey Starikovskiy (1): ACPI: EC: Fix "no battery" regression with this log: commit c019b1933015ee31366eeaa085bad3ee9516991c Author: Alexey Starikovskiy <[EMAIL PROTECTED]> Date: Tue Aug 14 01:03:42 2007 -0400 ACPI: EC: Fix "no battery" regression Restore deleted call to register query methods. http://bugzilla.kernel.org/show_bug.cgi?id=8886 Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[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: System call interposition/unprotecting the table
Alan Cox wrote: > This is to protect it from being changed by an attacker or someone trying > to do strange and bogus things to the kernel. > Someone who apparently hasn't heard of vmap(), etc. It's a debug aid at best. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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] net/tulip/xircom_cb.c: remove superfulous priv assignment
Mariusz Kozlowski wrote:
Hello,
Unpatched version does sth like this:
dev = alloc_etherdev(...
private = netdev_priv(dev);
...
dev->priv = private;
which doesn't make much sense (does it?) because this is done in
alloc_netdev() already.
struct net_device *alloc_netdev(...
{
...
if (sizeof_priv)
dev->priv = netdev_priv(dev);
This patch removes superfluous code.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
applied
-
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] fix NULL pointer dereference in __vm_enough_memory()
On Mon, 13 Aug 2007 14:01:06 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > On Mon, 13 Aug 2007 15:38:53 +0800 > WU Fengguang <[EMAIL PROTECTED]> wrote: > > > On Sun, Aug 12, 2007 at 04:17:44PM +0100, Alan Cox wrote: > > > Try this (it compiles but isnt tested). Its a weekend here, the sun is > > > shining, the beach is a short walk, and I have more interesting things to > > > do right now 8) > > > > Have a nice day~~~ It works! > > Ok please apply the patch then Andrew > > --- > > The new exec code inserts an accounted vma into an mm struct which is not > current->mm. The existing memory check code has a hard coded assumption > that this does not happen as does the security code. > > As the correct mm is known we pass the mm to the security method and the > helper function. A new security test is added for the case where we need > to pass the mm and the existing one is modified to pass current->mm to > avoid the need to change large amounts of code. > > Signed-off-by: Alan Cox <[EMAIL PROTECTED]> > > > diff -u --new-file --recursive --exclude-from /usr/src/exclude > linux.vanilla-2.6.23rc1-mm1/include/linux/mm.h > linux-2.6.23rc1-mm1/include/linux/mm.h > --- linux.vanilla-2.6.23rc1-mm1/include/linux/mm.h2007-07-26 > 15:02:58.0 +0100 erp, we have major version skew between 2.6.23-rc1-mm1 and 2.6.23-rc3 here, sorry. Could I ask for a redone patch against mainline? Thanks. - 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: Bad addresses in MAINTAINERS
On 8/14/07, Bryan Wu <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 23:54 -0400, Robin Getz wrote: > > On Mon 13 Aug 2007 15:56, Mike Frysinger pondered: > > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2007-08-13 at 15:10 -0400, Mike Frysinger wrote: > > > > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > > > > But if anyone has a new email address and still wants > > > > > > to be in the maintainers file, please send. > > > > > > > > > > > > BLACKFIN ARCHITECTURE > > > > > > P: Aubrey Li > > > > > > M: [EMAIL PROTECTED] > > > > > > P: Jerry Zeng > > > > > > M: [EMAIL PROTECTED] > > > > > > > > > > we know these guys needed to be removed as they've recently left ADI, > > > > > we just havent pushed to mainline > > > > > > > > Maybe you can have a "[EMAIL PROTECTED]" list as maintainers? > > > > > > we have a mailing list already ... could just drop the general list of > > > people for Blackfin and keep specific e-mails for specific drivers > > > > There is a public mailing list - but it is closed - must be subscribed to > > post > > (cuts down on spam), and I thought the requirement was to have these be open > > lists? > > Yes, open a public mailing list is a good choice to replace the whole > team member list. [EMAIL PROTECTED] would not be an open public mailing list, it'd be a private alias that only ADI people can subscribe to. what we have now ([EMAIL PROTECTED]) is best i think: [quickly] moderated for non-subscribers, open subscription, no spam. -mike - 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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
> On Tue, 2007-08-14 at 00:29 -0400, Cal Peake wrote:
> > Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
> > double quotes (e.g. "Jonathan \"Jon\" Doe" <[EMAIL PROTECTED]>).
>
> A-Z and [[:space:]] are OK too.
The 'i' at the end of the regex means case-insensitive ;) but yes, I
forgot whitespace. So something like:
if ($name =~ /[^a-z0-9[:space:]]/i) {
quote_name;
}
> I skimmed the spec, but nothing jumped out at me.
My recommendation was mostly based on what pine does. It seems to be a
pretty sane MUA...
--
Cal Peake
-
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: [Bugme-new] [Bug 8885] New: Unable to access memory card reader anymore
(resend, fixed mailing list address) On Mon, 13 Aug 2007 09:07:36 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8885 > >Summary: Unable to access memory card reader anymore >Product: IO/Storage >Version: 2.5 > KernelVersion: 2.6.23-rc3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: SCSI > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur: 2.6.22.1, maybe 2.6.23-rc2 > Distribution: Slackware 12.0 > Hardware Environment: Athlon64 3000, laptop Aspire 1511LMi, nForce3 150 > Software Environment: Kernel 2.6.23-rc3, blockdev, udev, KDE 3.5.7 > Problem Description: > With kernel 2.6.22.1, when I plug a memory card in the integrated card reader > of my laptop, the card is detected and KDE(via udev) asks me for mounting the > device. > With kernel 2.6.23-rc3, this does not happens anymore: > - first, at boot, there are some new lines in dmesg saying /dev/sda is seen > but > size cannot be get (normal: there is no memory card in the reader); > - second, plugging the card does nothing; > - third, issuing "blockdev --rereadpt /dev/sda" does not work; > - finally, fdisk /dev/sda fails (unable to open /dev/sda). > So the device seems to be completly unusable now (this is a Thomson card > reader > if I remember well). > > dmesg output for 2.6.22.1-cfs19 and 2.6.23-rc3 appended to show the > differences. > > Steps to reproduce: > Maybe the problem is specific to my hardware. I presume: boot with an empty > card reader connected, the plug the card and see it is inaccessible? > I'm struggling a bit to work out if this is a scsi bug, a USB bug, an MMC bug or whatever. But it's a bug. Michal, can you please track this as a post-2.6.22 regression? Others: can you please take a look at the dmesg output, see if we can work out which subsystem is (newly) failing? Thanks. - 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/3] /drivers/net ucc_geth ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing /
return check,
previous patchset contained wordwrap errors:
corrects:
--sbus_ioremap return unchecked.
--ioremap function unchecked
--function failure cases did not clean up ioremap'd values.
lne390.c -- believe had incorrect/not ideal variable check on if for iounmap
this audit was only for files directly in drivers/net directory, not the full
tree.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 12e01b2..30acbe2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2430,6 +2430,11 @@ static int ucc_struct_init(struct ucc_geth_private
*ugeth)
ugeth->ug_regs = (struct ucc_geth *) ioremap(uf_info->regs,
sizeof(struct ucc_geth));
+ if (!ugeth->ug_regs){
+ ugeth_err("%s: Failed to ioremap.", __FUNCTION__);
+ return -ENOMEM;
+ }
+
return 0;
}
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
http://autos.yahoo.com/carfinder/
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.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/
[PATCH 1/3] /drivers/net ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing / return check, previous patchset contained wordwrap errors: corrects: --sbus_ioremap return unchecked. --ioremap function unchecked --function failure cases did not clean up ioremap'd values. lne390.c -- believe had incorrect/not ideal variable check on if for iounmap this audit was only for files directly in drivers/net directory, not the full tree. Signed-off-by: Scott Thompson hushmail.com> -- diff --git a/drivers/net/es3210.c b/drivers/net/es3210.c index 822e5bf..d7d6b90 100644 --- a/drivers/net/es3210.c +++ b/drivers/net/es3210.c @@ -307,6 +307,10 @@ out1: free_irq(dev->irq, dev); out: release_region(ioaddr + ES_SA_PROM, ES_IO_EXTENT); + + if (ei_status.mem) + iounmap(ei_status.mem); + return retval; } diff --git a/drivers/net/lne390.c b/drivers/net/lne390.c index 0a08d0c..f6d9fb6 100644 --- a/drivers/net/lne390.c +++ b/drivers/net/lne390.c @@ -290,7 +290,7 @@ static int __init lne390_probe1(struct net_device *dev, int ioaddr) goto unmap; return 0; unmap: - if (ei_status.reg0) + if (ei_status.mem) iounmap(ei_status.mem); cleanup: free_irq(dev->irq, dev); Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - 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/3] /drivers/net myri_sbus.c ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing /
return check,
previous patchset contained wordwrap errors:
corrects:
--sbus_ioremap return unchecked.
--ioremap function unchecked
--function failure cases did not clean up ioremap'd values.
lne390.c -- believe had incorrect/not ideal variable check on if for iounmap
this audit was only for files directly in drivers/net directory, not the full
tree.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/net/myri_sbus.c b/drivers/net/myri_sbus.c
index 13444da..138aabd 100644
--- a/drivers/net/myri_sbus.c
+++ b/drivers/net/myri_sbus.c
@@ -1007,6 +1007,13 @@ static int __devinit myri_ether_init(struct sbus_dev
*sdev)
mp->lanai =
sbus_ioremap(>resource[0], (512 * 1024),
mp->eeprom.ramsz, "MyriCOM SRAM");
+
+
+ if (!mp->cregs || !mp->lregs || !mp->lanai ) {
+ printk("MyriCOM: Cannot map registers for ioremap
fail.\n");
+ goto err;
+ }
+
}
DET(("Registers mapped: cregs[%p] lregs[%p] lanai[%p]\n",
mp->cregs, mp->lregs, mp->lanai));
@@ -1108,6 +1115,16 @@ err_free_irq:
err:
/* This will also free the co-allocated 'dev->priv' */
free_netdev(dev);
+
+ if (mp->regs)
+ sbus_iounmap(mp->regs, mp->reg_size);
+ if (mp->cregs)
+ sbus_iounmap(mp->cregs, PAGE_SIZE);
+ if (mp->lregs)
+ sbus_iounmap(mp->lregs, (256 * 1024));
+ if (mp->lanai)
+ sbus_iounmap(mp->lanai, (512 * 1024));
+
return -ENODEV;
}
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list=396545433
-
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 try 4] [libata] libata driver for bf548 on chip ATAPI controller.
Finally. This driver is for bf548 on chip ATAPI controller. Both PIO 4 and UDMA5 mode are enabled. Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/Kconfig | 28 + drivers/ata/Makefile |1 + drivers/ata/pata_bf54x.c | 1585 ++ 3 files changed, 1614 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_bf54x.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index b4a8d60..e679f04 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -583,4 +583,32 @@ config PATA_SCC If unsure, say N. +config PATA_BF54X + tristate "Blackfin 54x ATAPI support" + depends on BF542 || BF548 || BF549 + help + This option enables support for the built-in ATAPI controller on + Blackfin 54x family chips. + + If unsure, say N. + +choice + prompt "Blackfin 54x ATAPI mode" + depends on PATA_BF54X + default PATA_BF54X_DMA + help + This option selects bf54x ATAPI controller working mode. + +config PATA_BF54X_PIO + bool "PIO mode" + help + Blackfin ATAPI controller works under PIO mode. + +config PATA_BF54X_DMA + bool "DMA mode" + help + Blackfin ATAPI controller works under DMA mode. + +endchoice + endif # ATA diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8149c68..c2ecba5 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_PATA_SIS)+= pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o +obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o # Should be last but one libata driver diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c new file mode 100644 index 000..e1236ea --- /dev/null +++ b/drivers/ata/pata_bf54x.c @@ -0,0 +1,1585 @@ +/* + * File: drivers/ata/pata_bf54x.c + * Author: Sonic Zhang <[EMAIL PROTECTED]> + * + * Created: + * Description: ATAPI Driver for blackfin 54x + * + * Modified: + * Copyright 2007 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "bf54x-atapi" +#define DRV_VERSION"0.6" + +#define ATA_REG_CTRL 0x0E +#define ATA_REG_ALTSTATUS ATA_REG_CTRL + +#define ATAPI_OFFSET_CONTROL 0x00 +#define ATAPI_OFFSET_STATUS0x04 +#define ATAPI_OFFSET_DEV_ADDR 0x08 +#define ATAPI_OFFSET_DEV_TXBUF 0x0c +#define ATAPI_OFFSET_DEV_RXBUF 0x10 +#define ATAPI_OFFSET_INT_MASK 0x14 +#define ATAPI_OFFSET_INT_STATUS0x18 +#define ATAPI_OFFSET_XFER_LEN 0x1c +#define ATAPI_OFFSET_LINE_STATUS 0x20 +#define ATAPI_OFFSET_SM_STATE 0x24 +#define ATAPI_OFFSET_TERMINATE 0x28 +#define ATAPI_OFFSET_PIO_TFRCNT0x2c +#define ATAPI_OFFSET_DMA_TFRCNT0x30 +#define ATAPI_OFFSET_UMAIN_TFRCNT 0x34 +#define ATAPI_OFFSET_UDMAOUT_TFRCNT0x38 +#define ATAPI_OFFSET_REG_TIM_0 0x40 +#define ATAPI_OFFSET_PIO_TIM_0 0x44 +#define ATAPI_OFFSET_PIO_TIM_1 0x48 +#define ATAPI_OFFSET_MULTI_TIM_0 0x50 +#define ATAPI_OFFSET_MULTI_TIM_1 0x54 +#define ATAPI_OFFSET_MULTI_TIM_2 0x58 +#define ATAPI_OFFSET_ULTRA_TIM_0 0x60 +#define ATAPI_OFFSET_ULTRA_TIM_1 0x64 +#define ATAPI_OFFSET_ULTRA_TIM_2 0x68 +#define ATAPI_OFFSET_ULTRA_TIM_3 0x6c + + +#define ATAPI_GET_CONTROL(base)\ + bfin_read16(base + ATAPI_OFFSET_CONTROL) +#define ATAPI_SET_CONTROL(base, val)\ + bfin_write16(base + ATAPI_OFFSET_CONTROL, val) +#define ATAPI_GET_STATUS(base)\ + bfin_read16(base + ATAPI_OFFSET_STATUS) +#define ATAPI_GET_DEV_ADDR(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_ADDR) +#define ATAPI_SET_DEV_ADDR(base, val)\ + bfin_write16(base +
Re: [PATCH] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Tue, 2007-08-14 at 00:29 -0400, Cal Peake wrote: > Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape > double quotes (e.g. "Jonathan \"Jon\" Doe" <[EMAIL PROTECTED]>). A-Z and [[:space:]] are OK too. I skimmed the spec, but nothing jumped out at me. - 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: USB HC on i.MX21 hangs with error -110
Hi All, Sorry for crossposting. > Let's see ... Linux-ARM is a "please don't crosspost" list; I did not know that. I will not repeat. I did not know which list to ask help for USB untill afterwards I found the linux-usb-users mailing list. Sorry again. Will not repeat. Thanks, Midhun. - 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] [27/2many] MAINTAINERS - ACPI THERMAL DRIVER
On Tue, 2007-08-14 at 00:23 -0400, Len Brown wrote: > Also, as Konstantin has moved on, might as well list me as maintainer too: ACPI THERMAL DRIVER P: Len Brown M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://acpi.sourceforge.net/ S: Supported F: drivers/acpi/*thermal* - 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 ] /drivers/atm ioremap balancing/ returncode check (re-resend)
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls..
I attempted to actually reapply the patch that was sent but the following two
lines that aren't
changed with this patch exceed the yahoo wordwrap maximum (argh). I also fixed
an if condition in
the first patch that would exceed 80 columns as well.
fore200e->regs.sba.isr = sbus_ioremap(_dev->resource[2], 0,
SBA200E_ISR_LENGTH, "SBA
ISR");
fore200e->virt_base= sbus_ioremap(_dev->resource[3], 0,
SBA200E_RAM_LENGTH, "SBA
RAM");
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit. This patch had been submitted previously but
hushmail client caused
wordwrap issues, resending with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 405ee5e..1d47ebe 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -795,8 +795,10 @@ fore200e_sba_map(struct fore200e* fore200e)
fore200e->regs.sba.isr = sbus_ioremap(_dev->resource[2], 0,
SBA200E_ISR_LENGTH, "SBA
ISR");
fore200e->virt_base= sbus_ioremap(_dev->resource[3], 0,
SBA200E_RAM_LENGTH, "SBA
RAM");
-if (fore200e->virt_base == NULL) {
+if (!fore200e->regs.sba.hcr || !fore200e->regs.sba.bsr
+ || !fore200e->regs.sba.isr || !fore200e->virt_base) {
printk(FORE200E "unable to map RAM of device %s\n", fore200e->name);
+ fore200e_sba_unmap(fore200e);
return -EFAULT;
}
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d33aba6..5ac9260 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1107,6 +1107,7 @@ he_start(struct atm_dev *dev)
status = he_readl(he_dev, RESET_CNTL);
if ((status & BOARD_RST_STATUS) == 0) {
hprintk("reset failed\n");
+ iounmap(he_dev->membase);
return -EINVAL;
}
@@ -1170,8 +1171,10 @@ he_start(struct atm_dev *dev)
he_writel(he_dev, lb_swap, LB_SWAP);
/* 4.10 initialize the interrupt queues */
- if ((err = he_init_irq(he_dev)) != 0)
+ if ((err = he_init_irq(he_dev)) != 0) {
+ iounmap(he_dev->membase);
return err;
+ }
#ifdef USE_TASKLET
tasklet_init(_dev->tasklet, he_tasklet, (unsigned long) he_dev);
@@ -1226,6 +1229,7 @@ he_start(struct atm_dev *dev)
if (nvpibits != -1 && nvcibits != -1 && nvpibits+nvcibits !=
HE_MAXCIDBITS) {
hprintk("nvpibits + nvcibits != %d\n", HE_MAXCIDBITS);
+ iounmap(he_dev->membase);
return -ENODEV;
}
@@ -1474,9 +1478,10 @@ he_start(struct atm_dev *dev)
/* 5.1.8 cs block connection memory initialization */
- if (he_init_cs_block_rcm(he_dev) < 0)
+ if (he_init_cs_block_rcm(he_dev) < 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
-
+ }
/* 5.1.10 initialize host structures */
he_init_tpdrq(he_dev);
@@ -1486,6 +1491,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_tpd), TPD_ALIGNMENT, 0);
if (he_dev->tpd_pool == NULL) {
hprintk("unable to create tpd pci_pool\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
@@ -1493,8 +1499,10 @@ he_start(struct atm_dev *dev)
#else
he_dev->tpd_base = (void *) pci_alloc_consistent(he_dev->pci_dev,
CONFIG_NUMTPDS * sizeof(struct he_tpd),
_dev->tpd_base_phys);
- if (!he_dev->tpd_base)
+ if (!he_dev->tpd_base) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (i = 0; i < CONFIG_NUMTPDS; ++i) {
he_dev->tpd_base[i].status = (i << TPD_ADDR_SHIFT);
@@ -1505,8 +1513,10 @@ he_start(struct atm_dev *dev)
he_dev->tpd_end = _dev->tpd_base[CONFIG_NUMTPDS - 1];
#endif
- if (he_init_group(he_dev, 0) != 0)
+ if (he_init_group(he_dev, 0) != 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (group = 1; group < HE_NUM_GROUPS; ++group) {
he_writel(he_dev, 0x0, G0_RBPS_S + (group * 32));
@@ -1540,6 +1550,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_hsp), _dev->hsp_phys);
if (he_dev->hsp == NULL) {
hprintk("failed to allocate host status page\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
memset(he_dev->hsp, 0, sizeof(struct he_hsp));
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
Re: [PATCH] [463/2many] MAINTAINERS - STRADIS MPEG-2 DECODER DRIVER
On Mon, 2007-08-13 at 21:04 -0700, Nathan Laredo wrote: > Well, technically speaking, there are multiple files to the stradis > driver, not just stradis.c. These files seem to be shared between drivers. the Kconfig file shows: obj-$(CONFIG_VIDEO_STRADIS) += stradis.o as the only STRADIS file. Are you the maintainer for other entries? Should I add these entries? drivers/media/video/cs8420.h drivers/media/video/ibmmpeg2.h drivers/media/video/saa5249.c drivers/media/video/saa7110.c drivers/media/video/saa7111.c drivers/media/video/saa7121.h drivers/media/video/saa7146*.h drivers/media/video/saa7185.h drivers/media/video/saa7196.h drivers/media/video/videodev.c - 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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
> On Mon, 2007-08-13 at 09:35 -0700, Joe Perches wrote:
> > On Mon, 2007-08-13 at 09:15 -0700, Kok, Auke wrote:
> > > or properly put it on "quotes":
> >
> > I'll improve the script and revert the name changes.
>
> # check for "must quote" chars in name
>
> sub format_email {
> my ($name, $email) = @_;
>
> if ($name =~ tr@,\@<>@@) {
> $formatted_email = "\"${name}\"\ \<${email}\>";
> } else {
> $formatted_email = "${name} \<${email}\>";
> }
> return $formatted_email;
> }
>
> Anyone know what chars require the name be quoted?
> I've got: "," "@" "<" ">" ?
Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
double quotes (e.g. "Jonathan \"Jon\" Doe" <[EMAIL PROTECTED]>).
Cheers,
--
Cal Peake
-
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] [27/2many] MAINTAINERS - ACPI THERMAL DRIVER
Acked-by: Len Brown <[EMAIL PROTECTED]> Also, as Konstantin has moved on, might as well list me as maintainer too: P: Len Brown M: [EMAIL PROTECTED] On Monday 13 August 2007 02:22, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index aca4528..b159b00 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -292,6 +292,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > S: Supported > +F: drivers/acpi/*thermal* > > ACPI VIDEO DRIVER > P: Luming Yu > - > 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/ > - 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] [25/2many] MAINTAINERS - ACPI FAN DRIVER
Acked-by: Len Brown <[EMAIL PROTECTED]> (and the maintainer can just be me now, per other message) thanks, -Len On Monday 13 August 2007 02:22, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index ef63c9d..e99d959 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -277,6 +277,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > S: Supported > +F: drivers/acpi/fan.c > > ACPI PCI HOTPLUG DRIVER > P: Kristen Carlson Accardi > - > 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/ > - 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: Bad addresses in MAINTAINERS
> > ACPI FAN DRIVER > > P: Konstantin A. Karasyov > > M: [EMAIL PROTECTED] > > Len? Konstantin is gone, so I guess this is effectively me for the time-being. P: Len Brown M: [EMAIL PROTECTED] thanks, -Len - 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] [24/2many] MAINTAINERS - ACPI EC DRIVER
Acked-by: Len Brown <[EMAIL PROTECTED]> On Monday 13 August 2007 02:22, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6bb5785..ef63c9d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -269,6 +269,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > S: Supported > +F: drivers/acpi/ec.c > > ACPI FAN DRIVER > P: Konstantin A. Karasyov > - > 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/ > - 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: Bad addresses in MAINTAINERS
On Tue, 2007-08-14 at 12:12 +0800, Bryan Wu wrote: > Yes, open a public mailing list is a good choice to replace the whole > team member list. > > How about some driver code maintainers? Just let me know please. cheers, Joe - 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: Bad addresses in MAINTAINERS
On Mon, 2007-08-13 at 23:54 -0400, Robin Getz wrote: > On Mon 13 Aug 2007 15:56, Mike Frysinger pondered: > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-08-13 at 15:10 -0400, Mike Frysinger wrote: > > > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > > > But if anyone has a new email address and still wants > > > > > to be in the maintainers file, please send. > > > > > > > > > > BLACKFIN ARCHITECTURE > > > > > P: Aubrey Li > > > > > M: [EMAIL PROTECTED] > > > > > P: Jerry Zeng > > > > > M: [EMAIL PROTECTED] > > > > > > > > we know these guys needed to be removed as they've recently left ADI, > > > > we just havent pushed to mainline > > > > > > Maybe you can have a "[EMAIL PROTECTED]" list as maintainers? > > > > we have a mailing list already ... could just drop the general list of > > people for Blackfin and keep specific e-mails for specific drivers > > There is a public mailing list - but it is closed - must be subscribed to > post > (cuts down on spam), and I thought the requirement was to have these be open > lists? Yes, open a public mailing list is a good choice to replace the whole team member list. How about some driver code maintainers? - Bryan > - > 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/ - 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: Bad addresses in MAINTAINERS
On 8/13/07, Robin Getz <[EMAIL PROTECTED]> wrote: > On Mon 13 Aug 2007 15:56, Mike Frysinger pondered: > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-08-13 at 15:10 -0400, Mike Frysinger wrote: > > > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > > > But if anyone has a new email address and still wants > > > > > to be in the maintainers file, please send. > > > > > > > > > > BLACKFIN ARCHITECTURE > > > > > P: Aubrey Li > > > > > M: [EMAIL PROTECTED] > > > > > P: Jerry Zeng > > > > > M: [EMAIL PROTECTED] > > > > > > > > we know these guys needed to be removed as they've recently left ADI, > > > > we just havent pushed to mainline > > > > > > Maybe you can have a "[EMAIL PROTECTED]" list as maintainers? > > > > we have a mailing list already ... could just drop the general list of > > people for Blackfin and keep specific e-mails for specific drivers > > There is a public mailing list - but it is closed - must be subscribed to post > (cuts down on spam), and I thought the requirement was to have these be open > lists? many other people do the same ... just a subscriber list but ours is more open -- we moderate e-mails, they dont get flat out rejected ;) -mike - 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] [463/2many] MAINTAINERS - STRADIS MPEG-2 DECODER DRIVER
Well, technically speaking, there are multiple files to the stradis driver, not just stradis.c. The tar file, http://kernel.org/pub/linux/kernel/people/laredo/stradis.tar.gz should make clear which files originated in the stradis driver. - Nathan Laredo [EMAIL PROTECTED] On 8/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9da5a44..3e51fc6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4406,6 +4406,7 @@ P:Nathan Laredo > M: [EMAIL PROTECTED] > W: http://www.stradis.com/ > S: Maintained > +F: drivers/media/video/stradis.c > > SUPERH (sh) > P: Paul Mundt > - 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 of 5 ] /drivers/char/rio ioremap balancing/ returncode check
On Mon, 13 Aug 2007 16:30:14 -0400 Jiri Slaby <[EMAIL PROTECTED]> wrote: >why [EMAIL PROTECTED] > David Airlie was listed as the owner on several of the files and in maintainers for "DRM", which was my best to: guess for /drivers/char/drm (which was patch 3 in this series). If there was a better list, or just to linux-kernel, please let me know as tracking down the 'right' list for these kernel-janitor kind of tasks can be tricky --- Scott Thompson / [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/
[PATCH ] /drivers/atm ioremap balancing/ returncode check (resend)
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls..
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit. This patch had been submitted previously but
hushmail client caused
wordwrap issues, resending with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 405ee5e..99e4ae4 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -795,8 +795,9 @@ fore200e_sba_map(struct fore200e* fore200e)
fore200e->regs.sba.isr = sbus_ioremap(_dev->resource[2], 0,
SBA200E_ISR_LENGTH, "SBA
ISR");
fore200e->virt_base= sbus_ioremap(_dev->resource[3], 0,
SBA200E_RAM_LENGTH, "SBA
RAM");
-if (fore200e->virt_base == NULL) {
+if (!fore200e->regs.sba.hcr || !fore200e->regs.sba.bsr ||
!fore200e->regs.sba.isr ||
!fore200e->virt_base) {
printk(FORE200E "unable to map RAM of device %s\n", fore200e->name);
+ fore200e_sba_unmap(fore200e);
return -EFAULT;
}
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d33aba6..92d0d51 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1107,6 +1107,7 @@ he_start(struct atm_dev *dev)
status = he_readl(he_dev, RESET_CNTL);
if ((status & BOARD_RST_STATUS) == 0) {
hprintk("reset failed\n");
+ iounmap(he_dev->membase);
return -EINVAL;
}
@@ -1170,8 +1171,10 @@ he_start(struct atm_dev *dev)
he_writel(he_dev, lb_swap, LB_SWAP);
/* 4.10 initialize the interrupt queues */
- if ((err = he_init_irq(he_dev)) != 0)
+ if ((err = he_init_irq(he_dev)) != 0) {
+ iounmap(he_dev->membase);
return err;
+ }
#ifdef USE_TASKLET
tasklet_init(_dev->tasklet, he_tasklet, (unsigned long) he_dev);
@@ -1226,6 +1229,7 @@ he_start(struct atm_dev *dev)
if (nvpibits != -1 && nvcibits != -1 && nvpibits+nvcibits !=
HE_MAXCIDBITS) {
hprintk("nvpibits + nvcibits != %d\n", HE_MAXCIDBITS);
+ iounmap(he_dev->membase);
return -ENODEV;
}
@@ -1474,9 +1478,10 @@ he_start(struct atm_dev *dev)
/* 5.1.8 cs block connection memory initialization */
- if (he_init_cs_block_rcm(he_dev) < 0)
+ if (he_init_cs_block_rcm(he_dev) < 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
-
+ }
/* 5.1.10 initialize host structures */
he_init_tpdrq(he_dev);
@@ -1486,6 +1491,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_tpd), TPD_ALIGNMENT, 0);
if (he_dev->tpd_pool == NULL) {
hprintk("unable to create tpd pci_pool\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
@@ -1493,8 +1499,10 @@ he_start(struct atm_dev *dev)
#else
he_dev->tpd_base = (void *) pci_alloc_consistent(he_dev->pci_dev,
CONFIG_NUMTPDS * sizeof(struct he_tpd),
_dev->tpd_base_phys);
- if (!he_dev->tpd_base)
+ if (!he_dev->tpd_base) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (i = 0; i < CONFIG_NUMTPDS; ++i) {
he_dev->tpd_base[i].status = (i << TPD_ADDR_SHIFT);
@@ -1505,8 +1513,10 @@ he_start(struct atm_dev *dev)
he_dev->tpd_end = _dev->tpd_base[CONFIG_NUMTPDS - 1];
#endif
- if (he_init_group(he_dev, 0) != 0)
+ if (he_init_group(he_dev, 0) != 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (group = 1; group < HE_NUM_GROUPS; ++group) {
he_writel(he_dev, 0x0, G0_RBPS_S + (group * 32));
@@ -1540,6 +1550,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_hsp), _dev->hsp_phys);
if (he_dev->hsp == NULL) {
hprintk("failed to allocate host status page\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
memset(he_dev->hsp, 0, sizeof(struct he_hsp));
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-
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/
"pci=routeirq" on IBM Thinkpad A20m Type 2628-3au fixes wireless card in cardbus/pcmcia slot
pci=routeirq makes my wireless lan card in a cardbus/pcmcia slot work. I'm posting these are requested in the dmesg. (below are lspci and dmesg, more available by request) Here's the lspci: 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Flags: bus master, medium devsel, latency 64 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 128 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 2000-2fff Memory behind bridge: f420-f5ff Prefetchable memory behind bridge: 3000-300f 00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03) Subsystem: IBM Thinkpad T20/T22/A21m Flags: bus master, medium devsel, latency 168, IRQ 5 Memory at 5000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 2000-23fff000 (prefetchable) Memory window 1: 2400-27fff000 I/O window 0: 1400-14ff I/O window 1: 1c00-1cff 16-bit legacy interface ports at 0001 00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03) Subsystem: IBM Thinkpad T20/T22/A21m Flags: bus master, medium devsel, latency 168, IRQ 9 Memory at 5010 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 2800-2bfff000 (prefetchable) Memory window 1: 2c00-2000 I/O window 0: 3000-30ff I/O window 1: 3400-34ff 16-bit legacy interface ports at 0001 00:03.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 09) Subsystem: Intel Corporation EtherExpress PRO/100+ MiniPCI Flags: bus master, medium devsel, latency 66, IRQ 10 Memory at f412 (32-bit, non-prefetchable) [size=4K] I/O ports at 1800 [size=64] Memory at f410 (32-bit, non-prefetchable) [size=128K] [virtual] Expansion ROM at 3010 [disabled] [size=1M] Capabilities: [dc] Power Management version 2 00:03.1 Serial controller: Xircom Mini-PCI V.90 56k Modem (prog-if 02 [16550]) Subsystem: Intel Corporation Unknown device 2408 Flags: medium devsel, IRQ 10 I/O ports at 1840 [size=8] Memory at f4121000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01) Subsystem: IBM ThinkPad A20m Flags: bus master, slow devsel, latency 64, IRQ 5 Memory at f4122000 (32-bit, non-prefetchable) [size=4K] Memory at f400 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Power Management version 2 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 1850 [size=16] 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1860 [size=32] 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Flags: medium devsel, IRQ 9 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: IBM ThinkPad A20m/A21m Flags: bus master, stepping, medium devsel, latency 66, IRQ 5 Memory at f500 (32-bit, non-prefetchable) [size=16M] I/O ports at 2000 [size=256] Memory at f420 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 3000 [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Capabilities: [5c] Power Management version 2 dmesg: Linux version 2.6.22-1-686 (Debian 2.6.22-3) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 SMP Sun Jul 29 14:37:42 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 13ff (usable) BIOS-e820: 13ff - 13ffec00 (ACPI data) BIOS-e820: 13ffec00 - 1400 (ACPI NVS) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 319MB LOWMEM available. Entering
RE: [PATCH] [61/2many] MAINTAINERS - ARM/INTEL IOP13XX ARM ARCHITECTURE
On Mon, 2007-08-13 at 16:09 -0700, Williams, Dan J wrote: > For IOP13XX, IOP33X, and IOP32X add: > F: arch/arm/plat-iop/ > F: include/asm-arm/hardware/iop* ARM/INTEL IOP32X ARM ARCHITECTURE P: Lennert Buytenhek M: [EMAIL PROTECTED] P: Dan Williams M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Supported F: arch/arm/plat-iop/ F: arch/arm/mach-iop32x/ F: include/asm-arm/hardware/iop* F: include/asm-arm/plat-iop/ ARM/INTEL IOP33X ARM ARCHITECTURE P: Dan Williams M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Supported F: arch/arm/plat-iop/ F: arch/arm/mach-iop33x/ F: include/asm-arm/hardware/iop* F: include/asm-arm/plat-iop/ ARM/INTEL IOP13XX ARM ARCHITECTURE P: Lennert Buytenhek M: [EMAIL PROTECTED] P: Dan Williams M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Supported F: include/asm-arm/hardware/iop* F: arch/arm/plat-iop/ F: arch/arm/mach-iop13xx/ F: include/asm-arm/plat-iop/ - 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] [404/2many] MAINTAINERS - RCUTORTURE MODULE
Joe Perches wrote: > On Mon, 2007-08-13 at 08:09 -0700, Josh Triplett wrote: >> Also: >> +F: Documentation/RCU/torture.txt > > RCUTORTURE MODULE > P:Josh Triplett > M:[EMAIL PROTECTED] > L:linux-kernel@vger.kernel.org > S:Maintained > F:Documentation/RCU/torture.txt > F:kernel/rcutorture.c That looks fine. Acked-by: Josh Triplett <[EMAIL PROTECTED]> signature.asc Description: OpenPGP digital signature
Re: Bad addresses in MAINTAINERS
On Mon 13 Aug 2007 15:56, Mike Frysinger pondered: > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-13 at 15:10 -0400, Mike Frysinger wrote: > > > On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > > > But if anyone has a new email address and still wants > > > > to be in the maintainers file, please send. > > > > > > > > BLACKFIN ARCHITECTURE > > > > P: Aubrey Li > > > > M: [EMAIL PROTECTED] > > > > P: Jerry Zeng > > > > M: [EMAIL PROTECTED] > > > > > > we know these guys needed to be removed as they've recently left ADI, > > > we just havent pushed to mainline > > > > Maybe you can have a "[EMAIL PROTECTED]" list as maintainers? > > we have a mailing list already ... could just drop the general list of > people for Blackfin and keep specific e-mails for specific drivers There is a public mailing list - but it is closed - must be subscribed to post (cuts down on spam), and I thought the requirement was to have these be open lists? - 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: Withdrawn for now: /drivers/char/* /drivers/net/* drivers/atm/* ioremap balancing/ returncode check
On Mon, 13 Aug 2007 12:00:28 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > >It's highly unlikely that the server side would wrap email. > > Jeff Heard back from hushmail support -- "Outgoing mail is currently wrapping at 68 characters for new mail, and 64 chars for replies. This is to ensure that digital signatures retain the correct format for the recipient to be able to verify." and no way to change from w/in any hushmail client. just attempted similar thing with a yahoo account and was able to resolve this issue, so all hushmail users can be warned that wordwrapping will be an issue on patch submission and another route will be required. --- Scott Thompson / [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/
[PATCH ] /drivers/ata ioremap returncode check
patchset against 2.6.23-rc3. corrects missing ioremap return checks.
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 4ca7fd6..eaebc4d 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -189,6 +189,14 @@ static __devinit int ixp4xx_pata_probe(struct
platform_device *pdev)
data->cs0 = devm_ioremap(>dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(>dev, cs1->start, 0x1000);
+ if (!data->cs0 || !data->cs1) {
+ if (data->cs0)
+ iounmap(data->cs0);
+ if (data->cs1)
+ iounmap(data->cs1);
+ return -ENOMEM;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq)
set_irq_type(irq, IRQT_RISING);
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail=graduation+gifts=bz
-
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: lmbench ctxsw regression with CFS
From: Andrew Morton <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2007 20:00:38 -0700 > Guys, repeat after me: "context switch is not a fast path". Take > that benchmark and set fire to it. Nothing in this world is so absolute :-) Regardless of the value of lat_ctx, we should thank it for showing that something is more expensive now. And it definitely warrants figuring out what paths are big cycle eaters now and why. Not "on IA64 indirect calls are expensive, so that must be it", but rather doing cycle analysis of the relevant scheduling functions to figure out what might be wrong. I'm willing to bet it's something completely trivial and easy to amend, rather than a fundamental issue. But somebody has to _look_ instead of supposing this and that. - 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] [210/2many] MAINTAINERS - HARDWARE MONITORING
On Mon, 2007-08-13 at 21:59 -0400, Mark M. Hoffman wrote: > If you collect the hwmon stuff into one (1) patch, I'll take it. I suspect that someone will either take or reject the whole thing. I'll send a batch of 10 or so patches to MAINTAINERS with all the collected changes tomorrow along with the modified script. Thanks, Joe - 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: lmbench ctxsw regression with CFS
On Mon, Aug 13, 2007 at 08:00:38PM -0700, Andrew Morton wrote: > On Mon, 13 Aug 2007 14:30:31 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Mon, Aug 06 2007, Nick Piggin wrote: > > > > > What CPU did you get these numbers on? Do the indirect calls hurt > > > > > much > > > > > on those without an indirect predictor? (I'll try running some tests). > > > > > > > > it was on an older Athlon64 X2. I never saw indirect calls really > > > > hurting on modern x86 CPUs - dont both CPU makers optimize them pretty > > > > efficiently? (as long as the target function is always the same - which > > > > it is here.) > > > > > > I think a lot of CPUs do. I think ia64 does not. It predicts > > > based on the contents of a branch target register which has to > > > be loaded I presume before instructoin fetch reaches the branch. > > > I don't know if this would hurt or not. > > > > Testing on ia64 showed that the indirect calls in the io scheduler hurt > > quite a bit, so I'd be surprised if the impact here wasn't an issue > > there. > > With what workload? lmbench ctxsw? Who cares? > > Look, if you're doing 100,000 context switches per second per then *that* > is your problem. You suck, and making context switches a bit faster > doesn't stop you from sucking. And ten microseconds is a very long time > indeed. > > Put it this way: if a 50% slowdown in context switch times yields a 5% > improvement in, say, balancing decisions then it's probably a net win. > > Guys, repeat after me: "context switch is not a fast path". Take that > benchmark and set fire to it. It definitely can be. For workloads that are inherently asynchronous, high speed networking or disk IO (ie. with event generation significantly outside the control of the kernel or app), then it can be. Sure, you may just be switching between the main working thread and idle thread, but in that case a slowdown in the scheduler will be _more_ pronounced because you don't have to do as much work to actually switch contexts. If there was a performance tradeoff involved, then we could think about it, and you might be right. But this is just a case of "write code to do direct calls or do indirect calls". Ken Chen's last ia64 database benchmark I could find says schedule takes 6.5% of the clock cycles, the second highest consumer. Considering the lengths he was going to shave cycles off other paths, I'd call schedule() a fastpath. Would be really interesting to rerun that benchmark with CFS. Is anyone at Intel still doing those tests? - 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 try 3] [libata] libata driver for bf548 on chip ATAPI controller.
Sorry, word wrap again in my last email. Hope this is the last one. 8-( This driver is for bf548 on chip ATAPI controller. Both PIO 4 and UDMA5 mode are enabled. Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/Kconfig | 28 + drivers/ata/Makefile |1 + drivers/ata/pata_bf54x.c | 1585 ++ 3 files changed, 1614 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_bf54x.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index b4a8d60..e679f04 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -583,4 +583,32 @@ config PATA_SCC If unsure, say N. +config PATA_BF54X + tristate "Blackfin 54x ATAPI support" + depends on BF542 || BF548 || BF549 + help + This option enables support for the built-in ATAPI controller on + Blackfin 54x family chips. + + If unsure, say N. + +choice + prompt "Blackfin 54x ATAPI mode" + depends on PATA_BF54X + default PATA_BF54X_DMA + help + This option selects bf54x ATAPI controller working mode. + +config PATA_BF54X_PIO + bool "PIO mode" + help + Blackfin ATAPI controller works under PIO mode. + +config PATA_BF54X_DMA + bool "DMA mode" + help + Blackfin ATAPI controller works under DMA mode. + +endchoice + endif # ATA diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8149c68..c2ecba5 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_PATA_SIS)+= pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o +obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o # Should be last but one libata driver diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c new file mode 100644 index 000..e1236ea --- /dev/null +++ b/drivers/ata/pata_bf54x.c @@ -0,0 +1,1585 @@ +/* + * File: drivers/ata/pata_bf54x.c + * Author: Sonic Zhang <[EMAIL PROTECTED]> + * + * Created: + * Description: ATAPI Driver for blackfin 54x + * + * Modified: + * Copyright 2007 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "bf54x-atapi" +#define DRV_VERSION"0.6" + +#define ATA_REG_CTRL 0x0E +#define ATA_REG_ALTSTATUS ATA_REG_CTRL + +#define ATAPI_OFFSET_CONTROL 0x00 +#define ATAPI_OFFSET_STATUS0x04 +#define ATAPI_OFFSET_DEV_ADDR 0x08 +#define ATAPI_OFFSET_DEV_TXBUF 0x0c +#define ATAPI_OFFSET_DEV_RXBUF 0x10 +#define ATAPI_OFFSET_INT_MASK 0x14 +#define ATAPI_OFFSET_INT_STATUS0x18 +#define ATAPI_OFFSET_XFER_LEN 0x1c +#define ATAPI_OFFSET_LINE_STATUS 0x20 +#define ATAPI_OFFSET_SM_STATE 0x24 +#define ATAPI_OFFSET_TERMINATE 0x28 +#define ATAPI_OFFSET_PIO_TFRCNT0x2c +#define ATAPI_OFFSET_DMA_TFRCNT0x30 +#define ATAPI_OFFSET_UMAIN_TFRCNT 0x34 +#define ATAPI_OFFSET_UDMAOUT_TFRCNT0x38 +#define ATAPI_OFFSET_REG_TIM_0 0x40 +#define ATAPI_OFFSET_PIO_TIM_0 0x44 +#define ATAPI_OFFSET_PIO_TIM_1 0x48 +#define ATAPI_OFFSET_MULTI_TIM_0 0x50 +#define ATAPI_OFFSET_MULTI_TIM_1 0x54 +#define ATAPI_OFFSET_MULTI_TIM_2 0x58 +#define ATAPI_OFFSET_ULTRA_TIM_0 0x60 +#define ATAPI_OFFSET_ULTRA_TIM_1 0x64 +#define ATAPI_OFFSET_ULTRA_TIM_2 0x68 +#define ATAPI_OFFSET_ULTRA_TIM_3 0x6c + + +#define ATAPI_GET_CONTROL(base)\ + bfin_read16(base + ATAPI_OFFSET_CONTROL) +#define ATAPI_SET_CONTROL(base, val)\ + bfin_write16(base + ATAPI_OFFSET_CONTROL, val) +#define ATAPI_GET_STATUS(base)\ + bfin_read16(base + ATAPI_OFFSET_STATUS) +#define ATAPI_GET_DEV_ADDR(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_ADDR)
Re: [PATCH again 2] [libata] libata driver for bf548 on chip ATAPI controller.
On 8/13/07, Sonic Zhang <[EMAIL PROTECTED]> wrote: > Sorry, word wrap in my last email. So, send again. i think this too got word wrapped ... pasting into gmail will word wrap things (even though it looks like it wont in the edit window), so you'll probably have to send the patch "from" your gmail.com address using the git commandline ... -mike - 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: lmbench ctxsw regression with CFS
On Mon, 13 Aug 2007 14:30:31 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Mon, Aug 06 2007, Nick Piggin wrote: > > > > What CPU did you get these numbers on? Do the indirect calls hurt much > > > > on those without an indirect predictor? (I'll try running some tests). > > > > > > it was on an older Athlon64 X2. I never saw indirect calls really > > > hurting on modern x86 CPUs - dont both CPU makers optimize them pretty > > > efficiently? (as long as the target function is always the same - which > > > it is here.) > > > > I think a lot of CPUs do. I think ia64 does not. It predicts > > based on the contents of a branch target register which has to > > be loaded I presume before instructoin fetch reaches the branch. > > I don't know if this would hurt or not. > > Testing on ia64 showed that the indirect calls in the io scheduler hurt > quite a bit, so I'd be surprised if the impact here wasn't an issue > there. With what workload? lmbench ctxsw? Who cares? Look, if you're doing 100,000 context switches per second per then *that* is your problem. You suck, and making context switches a bit faster doesn't stop you from sucking. And ten microseconds is a very long time indeed. Put it this way: if a 50% slowdown in context switch times yields a 5% improvement in, say, balancing decisions then it's probably a net win. Guys, repeat after me: "context switch is not a fast path". Take that benchmark and set fire to it. - 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: Bad addresses in MAINTAINERS
On Tue, 2007-08-14 at 11:21 +0900, Paul Mundt wrote: > I also haven't had one of these devices in years, though I never got > around to updating MAINTAINERS. Perhaps this should be orphaned? IMS TWINTURBO FRAMEBUFFER DRIVER L: [EMAIL PROTECTED] (subscribers-only) S: Orphan F: drivers/video/imsttfb.c - 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 again 2] [libata] libata driver for bf548 on chip ATAPI controller.
Sorry, word wrap in my last email. So, send again. This driver is for bf548 on chip ATAPI controller. Both PIO 4 and UDMA5 mode are enabled. Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/Kconfig | 28 + drivers/ata/Makefile |1 + drivers/ata/pata_bf54x.c | 1585 ++ 3 files changed, 1614 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_bf54x.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index b4a8d60..e679f04 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -583,4 +583,32 @@ config PATA_SCC If unsure, say N. +config PATA_BF54X + tristate "Blackfin 54x ATAPI support" + depends on BF542 || BF548 || BF549 + help + This option enables support for the built-in ATAPI controller on + Blackfin 54x family chips. + + If unsure, say N. + +choice + prompt "Blackfin 54x ATAPI mode" + depends on PATA_BF54X + default PATA_BF54X_DMA + help + This option selects bf54x ATAPI controller working mode. + +config PATA_BF54X_PIO + bool "PIO mode" + help + Blackfin ATAPI controller works under PIO mode. + +config PATA_BF54X_DMA + bool "DMA mode" + help + Blackfin ATAPI controller works under DMA mode. + +endchoice + endif # ATA diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8149c68..c2ecba5 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_PATA_SIS)+= pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o +obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o # Should be last but one libata driver diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c new file mode 100644 index 000..e1236ea --- /dev/null +++ b/drivers/ata/pata_bf54x.c @@ -0,0 +1,1585 @@ +/* + * File: drivers/ata/pata_bf54x.c + * Author: Sonic Zhang <[EMAIL PROTECTED]> + * + * Created: + * Description: ATAPI Driver for blackfin 54x + * + * Modified: + * Copyright 2007 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "bf54x-atapi" +#define DRV_VERSION"0.6" + +#define ATA_REG_CTRL 0x0E +#define ATA_REG_ALTSTATUS ATA_REG_CTRL + +#define ATAPI_OFFSET_CONTROL 0x00 +#define ATAPI_OFFSET_STATUS0x04 +#define ATAPI_OFFSET_DEV_ADDR 0x08 +#define ATAPI_OFFSET_DEV_TXBUF 0x0c +#define ATAPI_OFFSET_DEV_RXBUF 0x10 +#define ATAPI_OFFSET_INT_MASK 0x14 +#define ATAPI_OFFSET_INT_STATUS0x18 +#define ATAPI_OFFSET_XFER_LEN 0x1c +#define ATAPI_OFFSET_LINE_STATUS 0x20 +#define ATAPI_OFFSET_SM_STATE 0x24 +#define ATAPI_OFFSET_TERMINATE 0x28 +#define ATAPI_OFFSET_PIO_TFRCNT0x2c +#define ATAPI_OFFSET_DMA_TFRCNT0x30 +#define ATAPI_OFFSET_UMAIN_TFRCNT 0x34 +#define ATAPI_OFFSET_UDMAOUT_TFRCNT0x38 +#define ATAPI_OFFSET_REG_TIM_0 0x40 +#define ATAPI_OFFSET_PIO_TIM_0 0x44 +#define ATAPI_OFFSET_PIO_TIM_1 0x48 +#define ATAPI_OFFSET_MULTI_TIM_0 0x50 +#define ATAPI_OFFSET_MULTI_TIM_1 0x54 +#define ATAPI_OFFSET_MULTI_TIM_2 0x58 +#define ATAPI_OFFSET_ULTRA_TIM_0 0x60 +#define ATAPI_OFFSET_ULTRA_TIM_1 0x64 +#define ATAPI_OFFSET_ULTRA_TIM_2 0x68 +#define ATAPI_OFFSET_ULTRA_TIM_3 0x6c + + +#define ATAPI_GET_CONTROL(base)\ + bfin_read16(base + ATAPI_OFFSET_CONTROL) +#define ATAPI_SET_CONTROL(base, val)\ + bfin_write16(base + ATAPI_OFFSET_CONTROL, val) +#define ATAPI_GET_STATUS(base)\ + bfin_read16(base + ATAPI_OFFSET_STATUS) +#define ATAPI_GET_DEV_ADDR(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_ADDR) +#define
Re: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
On Mon, 2007-08-13 at 22:08 -0400, Michael Krufky wrote: > drivers/media/video -- v4l > drivers/media/radio -- v4l > > drivers/media/dvb -- dvb VIDEO FOR LINUX P: Mauro Carvalho Chehab M: [EMAIL PROTECTED] P: LinuxTV.org Project M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://linuxtv.org T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git S: Maintained F: Documentation/video4linux/ F: drivers/media/video/ F: drivers/media/radio/ F: include/linux/video_decoder.h F include/linux/videodev.h F: include/linux/videodev2.h F: include/media/ DVB SUBSYSTEM AND DRIVERS P: LinuxTV.org Project M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) W: http://linuxtv.org/ T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git S: Maintained F: Documentation/dvb/ F: drivers/media/dvb/ F: drivers/media/common/saa7146*.c F: include/linux/dvb/ - 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 again] [libata] libata driver for bf548 on chip ATAPI controller.
This driver is for bf548 on chip ATAPI controller. Both PIO 4 and UDMA5 mode are enabled. Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/Kconfig | 28 + drivers/ata/Makefile |1 + drivers/ata/pata_bf54x.c | 1585 ++ 3 files changed, 1614 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/pata_bf54x.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index b4a8d60..e679f04 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -583,4 +583,32 @@ config PATA_SCC If unsure, say N. +config PATA_BF54X + tristate "Blackfin 54x ATAPI support" + depends on BF542 || BF548 || BF549 + help + This option enables support for the built-in ATAPI controller on + Blackfin 54x family chips. + + If unsure, say N. + +choice + prompt "Blackfin 54x ATAPI mode" + depends on PATA_BF54X + default PATA_BF54X_DMA + help + This option selects bf54x ATAPI controller working mode. + +config PATA_BF54X_PIO + bool "PIO mode" + help + Blackfin ATAPI controller works under PIO mode. + +config PATA_BF54X_DMA + bool "DMA mode" + help + Blackfin ATAPI controller works under DMA mode. + +endchoice + endif # ATA diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8149c68..c2ecba5 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_PATA_SIS)+= pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o +obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o # Should be last but one libata driver diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c new file mode 100644 index 000..e1236ea --- /dev/null +++ b/drivers/ata/pata_bf54x.c @@ -0,0 +1,1585 @@ +/* + * File: drivers/ata/pata_bf54x.c + * Author: Sonic Zhang <[EMAIL PROTECTED]> + * + * Created: + * Description: ATAPI Driver for blackfin 54x + * + * Modified: + * Copyright 2007 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "bf54x-atapi" +#define DRV_VERSION"0.6" + +#define ATA_REG_CTRL 0x0E +#define ATA_REG_ALTSTATUS ATA_REG_CTRL + +#define ATAPI_OFFSET_CONTROL 0x00 +#define ATAPI_OFFSET_STATUS0x04 +#define ATAPI_OFFSET_DEV_ADDR 0x08 +#define ATAPI_OFFSET_DEV_TXBUF 0x0c +#define ATAPI_OFFSET_DEV_RXBUF 0x10 +#define ATAPI_OFFSET_INT_MASK 0x14 +#define ATAPI_OFFSET_INT_STATUS0x18 +#define ATAPI_OFFSET_XFER_LEN 0x1c +#define ATAPI_OFFSET_LINE_STATUS 0x20 +#define ATAPI_OFFSET_SM_STATE 0x24 +#define ATAPI_OFFSET_TERMINATE 0x28 +#define ATAPI_OFFSET_PIO_TFRCNT0x2c +#define ATAPI_OFFSET_DMA_TFRCNT0x30 +#define ATAPI_OFFSET_UMAIN_TFRCNT 0x34 +#define ATAPI_OFFSET_UDMAOUT_TFRCNT0x38 +#define ATAPI_OFFSET_REG_TIM_0 0x40 +#define ATAPI_OFFSET_PIO_TIM_0 0x44 +#define ATAPI_OFFSET_PIO_TIM_1 0x48 +#define ATAPI_OFFSET_MULTI_TIM_0 0x50 +#define ATAPI_OFFSET_MULTI_TIM_1 0x54 +#define ATAPI_OFFSET_MULTI_TIM_2 0x58 +#define ATAPI_OFFSET_ULTRA_TIM_0 0x60 +#define ATAPI_OFFSET_ULTRA_TIM_1 0x64 +#define ATAPI_OFFSET_ULTRA_TIM_2 0x68 +#define ATAPI_OFFSET_ULTRA_TIM_3 0x6c + + +#define ATAPI_GET_CONTROL(base)\ + bfin_read16(base + ATAPI_OFFSET_CONTROL) +#define ATAPI_SET_CONTROL(base, val)\ + bfin_write16(base + ATAPI_OFFSET_CONTROL, val) +#define ATAPI_GET_STATUS(base)\ + bfin_read16(base + ATAPI_OFFSET_STATUS) +#define ATAPI_GET_DEV_ADDR(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_ADDR) +#define ATAPI_SET_DEV_ADDR(base, val)\ + bfin_write16(base +
Re: [PATCH 00/23] per device dirty throttling -v8
On Tue, Aug 14, 2007 at 11:44:56AM +1000, Stewart Smith wrote: > > Since the database fits in RAM, the only kind of access Mysql is doing > > is writing to the innodb log, the mysql binlog and finally to the innodb > > database files. > > There are certainly a whole lot of fsync'ing happening. > > yes. Keep in mind that the binlog grows in file size too... so this has > to sync all the metadata as well (ick, i know). It might be an interesting experiment to see if it still happens with the file system remounted as ext2. ext2 has a much more benign fsync than ext3. -Andi - 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: Bad addresses in MAINTAINERS
On Tue, Aug 14, 2007 at 04:27:23AM +0800, Antonino A. Daplas wrote: > On Mon, 2007-08-13 at 12:07 -0700, Joe Perches wrote: > > IMS TWINTURBO FRAMEBUFFER DRIVER > > P: Paul Mundt > > M: [EMAIL PROTECTED] > > That's not Paul's current email. > I also haven't had one of these devices in years, though I never got around to updating MAINTAINERS. Perhaps this should be orphaned? - 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: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
On 8/14/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 23:22 +0400, Manu Abraham wrote: > > > F: drivers/media/ > > This means everything under media is maintained under V4L. Incorrect > > What would you like? > media/video and media/radio *only* belong under V4L Manu - 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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On 8/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote: > > Hello, > > > > I don't recall discusion about this so here are my 3 cents: > > > > I like the idea. > > I don't actually. It shows a central MAINTAINERS file is the wrong > approach; just that 500+ patches to the same file were needed shows > that. > > The maintainer info should be in the source file itself! That's the only > reasonable way to keep it updated; now I'm all for having it machine > parsable so that tools can use it, but it still really should be in the > code itself, not in some central file that will always just go out of > data, and will be a huge source of needless patch conflicts. ACK. Very much agree. In fact MAINTAINERS is a wrong thing altogether. For example, code/drivers under a subsystem, might not be easily add "able" to a central file in some cases as it is scattered around. Maintainer info in the source is the right way to go. - 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][rfc] 2.6.23-rc1 mm: NUMA replicated pagecache
On Mon, Aug 13, 2007 at 10:05:01AM -0400, Lee Schermerhorn wrote: > On Mon, 2007-08-13 at 09:43 +0200, Nick Piggin wrote: > > > > Replication may be putting more stress on some locks. It will cause more > > tlb flushing that can not be batched well, which could cause the call_lock > > to get hotter. Then i_mmap_lock is held over tlb flushing, so it will > > inherit the latency from call_lock. (If this is the case, we could > > potentially extend the tlb flushing API slightly to cope better with > > unmapping of pages from multiple mm's, but that comes way down the track > > when/if replication proves itself!). > > > > tlb flushing AFAIKS should not do the IPI unless it is deadling with a > > multithreaded mm... does usex use threads? > > Yes. Apparently, there are some tests, perhaps some of the /usr/bin > apps that get run repeatedly, that are multi-threaded. This job mix > caught a number of races in my auto-migration patches when > multi-threaded tasks race in the page fault paths. > > More below... Hmm, come to think of it: I'm a bit mistaken. The replica zaps will often to be coming from _other_ CPUs, so they will require an IPI regardless of whether they are threaded or not. The generic ia64 tlb flushing code also does a really bad job at flushing one 'mm' from another: it uses the single-threaded smp_call_function and broadcasts IPIs (and TLB invalidates) to ALL CPUs, regardless of the cpu_vm_mask of the target process. So you have a multiplicative problem with call_lock. I think this path could be significantly optimised... but it's a bit nasty to be playing around with the TLB flushing code while trying to test something else :P Can we make a simple change to smp_flush_tlb_all to do smp_flush_tlb_cpumask(cpu_online_map), rather than on_each_cpu()? At least then it will use the direct IPI vector and avoid call_lock. > > Ah, so it does eventually die? Any hints of why? > > No, doesn't die--as in panic. I was just commenting that I'd leave it > running ... However [:-(], it DID hang again. The test window said > that the tests ran for 62h:28m before the screen stopped updating. In > another window, I was running a script to snap the replication and # > file pages vmstats, along with a timestamp, every 10 minutes. That > stopped reporting stats at about 7:30am on Saturday--about 14h:30m into > the test. It still wrote the timestamps [date command] until around 7am > this morning [Monday]--or ~62 hours into test. > > So, I do have ~14 hours of replication stats that I can send you or plot > up... If you think it could be useful, sure. > Re: the hang: again, console was scrolling soft lockups continuously. > Checking the messages file, I see hangs in copy_process(), > smp_call_function [as in prev test], vma_link [from mmap], ... I don't suppose it should hang even if it is encountering 10s delays on call_lock but I wonder how it would go with the tlb flush change. With luck, it would add more concurrency and make it hang _faster_ ;) > > Yeah I guess it can be a little misleading: as time approaches infinity, > > zaps will probably approach replications. But that doesn't tell you how > > long a replica stayed around and usefully fed CPUs with local memory... > > May be able to capture that info with a more invasive patch -- e.g., add > a timestamp to the page struct. I'll think about it. Yeah that actually could be a good approach. You could make a histogram of lifetimes which would be a decent metric to start tuning with. Ideally you'd also want to record some context of what caused the zap and the status of the file, but it may be difficult to get a good S/N on those metrics. > And, I'll keep you posted. Not sure how much time I'll be able to > dedicate to this patch stream. Got a few others I need to get back > to... Thanks, I appreciate it. I'm pretty much in the same boat, just spending a bit of time on it here and there. Thanks, Nick - 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: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
Joe Perches wrote: > On Mon, 2007-08-13 at 23:22 +0400, Manu Abraham wrote: > >>> F: drivers/media/ >>> >> This means everything under media is maintained under V4L. Incorrect >> > > What would you like? > > Just dont list "drivers/media". Instead: drivers/media/video -- v4l drivers/media/radio -- v4l drivers/media/dvb -- dvb Cheers, Michael Krufky - 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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On 08/14/2007 03:51 AM, Rene Herman wrote: MODULE_MAINTAINER() was discussed a while ago but embedding information into the binary has the problem you can't ever change deployed systems, meaning it lags by design. If a maintainer changes, people would still be using the information from their old binaries, meaning a replaced maintainer might get contacted for potentially years still (and the new one not). (you could avoid that by placing not a name/address in the maintainer tag but a pointer to somewhere else but at that point this gets to be about solving something else). Keeping it in the source alone is fine. C files could just embed their MAINTAINERS entry as a header: /* * P: Maintainer * M: Mail patches to * L: Mailing list that is relevant to this area * W: Web-page with status/info * T: SCM tree type and location. Type is one of: git, hg, quilt. * S: Status, one of the following: */ And probably adding fields: * I: Info/Summary (for index files and the like) * A: Author * G: License and such. Yes, while we're at it, we can pick better letters or full word tags ;-) Okay, and if a single "maintenance unit" consists of many files, this gets to be too much yes. But they _could_ just grow a header pointing back to the MINTAINERS file/database; /* * MAINTAINERS: 3C359 NETWORK DRIVER */ Thst should keep things minimal enough to keep them updated, no? Rene. - 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 00/23] per device dirty throttling -v8
On Mon, 2007-08-06 at 10:40 +0200, Brice Figureau wrote: > Mysql accesses its database files in O_DIRECT mode. binlog is written using buffered IO. for InnoDB, binlog is synced first, then innodb log. on restart (in 5.0) these are synced back up so you don't get inconsistencies. and from a quick look at the innobase source, only data file is using O_DIRECT. > Since the database fits in RAM, the only kind of access Mysql is doing > is writing to the innodb log, the mysql binlog and finally to the innodb > database files. > There are certainly a whole lot of fsync'ing happening. yes. Keep in mind that the binlog grows in file size too... so this has to sync all the metadata as well (ick, i know). -- Stewart Smith, Senior Software Engineer MySQL AB, www.mysql.com Office: +14082136540 Ext: 6616 VoIP: [EMAIL PROTECTED] Mobile: +61 4 3 8844 332 Jumpstart your cluster: http://www.mysql.com/consulting/packaged/cluster.html signature.asc Description: This is a digitally signed message part
Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On Mon, Aug 13, 2007 at 06:19:26PM -0700, Arjan van de Ven wrote: > > On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote: > > If the problem is to do with people failing to update the MAINTAINERS > > file, why would moving the same data into 20 or 30 source files motivate > > them to keep it up to date? As far as I can see, that would just serve > > to multiply the amount of stale data... > > if each .c file has a MODULE_MAINTAINER() tag... > > people tend to update .c files a lot better than way off-the-side other > files. I think this approach makes a lot more sense than adding a bunch of data to MAINTAINERS all for a tool that I'll wager few people would ever use. John -- John W. Linville [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/
ignoring unimplemented functions that are old and crusty on shiny new ports
would it be possible to get the class of "old and crusty" functions permanently ignored ? i'm thinking of course of "uselib" and "sysfs" ... Blackfin does not implement either of these and i think that's a good thing Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh index 0dcc01c..7f1a830 100755 --- a/scripts/checksyscalls.sh +++ b/scripts/checksyscalls.sh @@ -104,6 +104,10 @@ cat << EOF #define __IGNORE_sync_file_range #endif +/* Old optional stuff no one actually uses */ +#define __IGNORE_sysfs +#define __IGNORE_uselib + /* Unmerged syscalls for AFS, STREAMS, etc. */ #define __IGNORE_afs_syscall #define __IGNORE_getpmsg - 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] [210/2many] MAINTAINERS - HARDWARE MONITORING
Joe: * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-08-12 23:28:20 -0700]: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index e35e29c..f422277 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2015,6 +2015,7 @@ L: [EMAIL PROTECTED] > W: http://www.lm-sensors.org/ > T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git > S: Maintained > +F: drivers/hwmon/ > > HARDWARE RANDOM NUMBER GENERATOR CORE > P: Michael Buesch I guess you know by now not to ever do that again. If you collect the hwmon stuff into one (1) patch, I'll take it. Now you'll excuse me while I drive a nail through my delete key. -- Mark M. Hoffman [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: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
On Mon, 2007-08-13 at 23:22 +0400, Manu Abraham wrote: > > F: drivers/media/ > This means everything under media is maintained under V4L. Incorrect What would you like? - 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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On 08/14/2007 03:19 AM, Arjan van de Ven wrote: On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote: On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote: The maintainer info should be in the source file itself! That's the only reasonable way to keep it updated; now I'm all for having it machine parsable so that tools can use it, but it still really should be in the code itself, not in some central file that will always just go out of data, and will be a huge source of needless patch conflicts. If the problem is to do with people failing to update the MAINTAINERS file, why would moving the same data into 20 or 30 source files motivate them to keep it up to date? As far as I can see, that would just serve to multiply the amount of stale data... if each .c file has a MODULE_MAINTAINER() tag... people tend to update .c files a lot better than way off-the-side other files. MODULE_MAINTAINER() was discussed a while ago but embedding information into the binary has the problem you can't ever change deployed systems, meaning it lags by design. If a maintainer changes, people would still be using the information from their old binaries, meaning a replaced maintainer might get contacted for potentially years still (and the new one not). (you could avoid that by placing not a name/address in the maintainer tag but a pointer to somewhere else but at that point this gets to be about solving something else). Keeping it in the source alone is fine. C files could just embed their MAINTAINERS entry as a header: /* * P: Maintainer * M: Mail patches to * L: Mailing list that is relevant to this area * W: Web-page with status/info * T: SCM tree type and location. Type is one of: git, hg, quilt. * S: Status, one of the following: */ And probably adding fields: * I: Info/Summary (for index files and the like) * A: Author * G: License and such. Yes, while we're at it, we can pick better letters or full word tags ;-) Rene. - 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/
[GIT PATCH] hwmon updates against ~v2.6.23-rc2-git
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get four bugfixes. This takes care of all known hwmon regressions, and hopefully it's the last you'll hear from me before v2.6.23 goes final. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-August/020843.html Thanks & regards, drivers/hwmon/smsc47m1.c |2 + drivers/hwmon/w83627ehf.c | 56 +--- drivers/hwmon/w83781d.c |4 +- 3 files changed, 36 insertions(+), 26 deletions(-) Jean Delvare (2): hwmon: (w83627ehf) don't assume bank 0 hwmon: (smsc47m1) restore missing name attribute Mark M. Hoffman (2): hwmon: fix w83781d temp sensor type setting hwmon: (w83627ehf) read fan_div values during probe -- Mark M. Hoffman [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/
[PATCH] PSS(proportional set size) accounting in smaps
The "proportional set size" (PSS) of a process is the count of pages it has in
memory, where each page is divided by the number of processes sharing it. So if
a process has 1000 pages all to itself, and 1000 shared with one other process,
its PSS will be 1500.
- lwn.net: "ELC: How much memory are applications really using?"
The PSS proposed by Matt Mackall is a very nice metic for measuring an process's
memory footprint. So collect and export it via /proc//smaps.
Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the job,
providing pretty much details. But for PSS, let's do it in a simple way.
Cc: Matt Mackall <[EMAIL PROTECTED]>
Cc: John Berthels <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
fs/proc/task_mmu.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc2-mm2.orig/fs/proc/task_mmu.c
+++ linux-2.6.23-rc2-mm2/fs/proc/task_mmu.c
@@ -319,6 +319,7 @@ const struct file_operations proc_maps_o
struct mem_size_stats
{
unsigned long resident;
+ u64 pss; /* proportional set size: my share of rss */
unsigned long shared_clean;
unsigned long shared_dirty;
unsigned long private_clean;
@@ -341,6 +342,7 @@ static int smaps_pte_range(pmd_t *pmd, u
pte_t *pte, ptent;
spinlock_t *ptl;
struct page *page;
+ int mapcount;
pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
for (; addr != end; pte++, addr += PAGE_SIZE) {
@@ -357,16 +359,19 @@ static int smaps_pte_range(pmd_t *pmd, u
/* Accumulate the size in pages that have been accessed. */
if (pte_young(ptent) || PageReferenced(page))
mss->referenced += PAGE_SIZE;
- if (page_mapcount(page) >= 2) {
+ mapcount = page_mapcount(page);
+ if (mapcount >= 2) {
if (pte_dirty(ptent))
mss->shared_dirty += PAGE_SIZE;
else
mss->shared_clean += PAGE_SIZE;
+ mss->pss += (PAGE_SIZE << 12) / mapcount;
} else {
if (pte_dirty(ptent))
mss->private_dirty += PAGE_SIZE;
else
mss->private_clean += PAGE_SIZE;
+ mss->pss += (PAGE_SIZE << 12);
}
}
pte_unmap_unlock(pte - 1, ptl);
@@ -395,18 +400,20 @@ static int show_smap(struct seq_file *m,
seq_printf(m,
"Size: %8lu kB\n"
"Rss:%8lu kB\n"
+ "Pss:%8lu kB\n"
"Shared_Clean: %8lu kB\n"
"Shared_Dirty: %8lu kB\n"
"Private_Clean: %8lu kB\n"
"Private_Dirty: %8lu kB\n"
"Referenced: %8lu kB\n",
(vma->vm_end - vma->vm_start) >> 10,
- sarg.mss.resident >> 10,
+ sarg.mss.resident >> 10,
+ (unsigned long)(mss->pss >> 22),
sarg.mss.shared_clean >> 10,
sarg.mss.shared_dirty >> 10,
sarg.mss.private_clean >> 10,
sarg.mss.private_dirty >> 10,
- sarg.mss.referenced >> 10);
+ sarg.mss.referenced>> 10);
return ret;
}
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote: > On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote: > > The maintainer info should be in the source file itself! That's the only > > reasonable way to keep it updated; now I'm all for having it machine > > parsable so that tools can use it, but it still really should be in the > > code itself, not in some central file that will always just go out of > > data, and will be a huge source of needless patch conflicts. > > If the problem is to do with people failing to update the MAINTAINERS > file, why would moving the same data into 20 or 30 source files motivate > them to keep it up to date? As far as I can see, that would just serve > to multiply the amount of stale data... if each .c file has a MODULE_MAINTAINER() tag... people tend to update .c files a lot better than way off-the-side other files. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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] [464/2many] MAINTAINERS - SUPERH (sh)
On Tue, 2007-08-14 at 09:43 +0900, Paul Mundt wrote: > On Sun, Aug 12, 2007 at 11:36:51PM -0700, [EMAIL PROTECTED] wrote: > I suppose you meant include/ here? Yes. Thanks. I've replace them with this in my tree. SUPERH (sh) P: Paul Mundt M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) W: http://www.linux-sh.org S: Maintained F: arch/sh/ F: include/asm-sh/ SUPERH64 (sh64) P: Paul Mundt M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linux-sh.org S: Maintained F: arch/sh64/ F: include/asm-sh64/ > The more pressing question that comes to mind is what the point of this > is? Architecture related drivers and things of that nature fall under > this also, as most folks don't create a separate entry for every trivial > driver. Are you intending to have a long list of individual drivers here > that your script can parse? If there are separate maintainers, sure. Look at drivers/foo for instance. > Is there actually a problem with people just opening up MAINTAINERS in a > text file? Surely this is not such a non-intuitive thing, there are > already keywords there you can grep for. It's an automation problem. It's just for CC's. cheers, Joe - 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] [464/2many] MAINTAINERS - SUPERH (sh)
On Sun, Aug 12, 2007 at 11:36:51PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3e51fc6..f42712c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4414,6 +4414,8 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] (subscribers-only) > W: http://www.linux-sh.org > S: Maintained > +F: arch/sh/ > +F: arch/asm-sh/ > I suppose you meant include/ here? On Sun, Aug 12, 2007 at 11:36:53PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index f42712c..df097fb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4423,6 +4423,8 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.linux-sh.org > S: Maintained > +F: arch/sh64/ > +F: arch/asm-sh64/ > Likewise? The more pressing question that comes to mind is what the point of this is? Architecture related drivers and things of that nature fall under this also, as most folks don't create a separate entry for every trivial driver. Are you intending to have a long list of individual drivers here that your script can parse? Is there actually a problem with people just opening up MAINTAINERS in a text file? Surely this is not such a non-intuitive thing, there are already keywords there you can grep for. - 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] [384/2many] MAINTAINERS - PPP PROTOCOL DRIVERS AND COMPRESSORS
On Tue, 2007-08-14 at 09:55 +1000, Paul Mackerras wrote: > It seems poor form to have to rename the file just because of a > deficiency in the tools. How about an X: exclude file pattern ? - 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] drivers/net/tokenring: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
Sent 2007-05-01, no replys
diff --git a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c
index 1e8958e..0c69eaa 100644
--- a/drivers/net/tokenring/ibmtr.c
+++ b/drivers/net/tokenring/ibmtr.c
@@ -116,9 +116,6 @@ in the event that chatty debug messages are desired - jjs
12/30/98 */
#define ENABLE_PAGING 1
#endif
-#define FALSE 0
-#define TRUE (!FALSE)
-
/* changes the output format of driver initialization */
#define TR_VERBOSE 0
@@ -1542,7 +1539,7 @@ static void initial_tok_int(struct net_device *dev)
ti->ring_speed = init_status & 0x01 ? 16 : 4;
DPRINTK("Initial interrupt : %d Mbps, shared RAM base %08x.\n",
ti->ring_speed, (unsigned int)dev->mem_start);
- ti->auto_speedsave=readb(ti->init_srb+INIT_STATUS_2_OFST)&4?TRUE:FALSE;
+ ti->auto_speedsave = (readb(ti->init_srb+INIT_STATUS_2_OFST) & 4) != 0;
if (ti->open_mode == MANUAL) wake_up(>wait_for_reset);
elsetok_open_adapter((unsigned long)dev);
-
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] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
On Monday 13 August 2007 21:54:37 Jeremy Fitzhardinge wrote: > xennet_tx_bug_gc can free the skb before we use it, so make sure we don't. > > Jeff, this is -rc material. > > Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> > Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Cc: Jeff Garzik <[EMAIL PROTECTED]> > > diff -r 8bfc43f6d1b0 drivers/net/xen-netfront.c > --- a/drivers/net/xen-netfront.c Tue Aug 07 14:26:30 2007 -0700 > +++ b/drivers/net/xen-netfront.c Mon Aug 13 09:39:15 2007 -0700 > @@ -566,15 +566,16 @@ static int xennet_start_xmit(struct sk_b > if (notify) > notify_remote_via_irq(np->netdev->irq); > > + np->stats.tx_bytes += skb->len; > + np->stats.tx_packets++; > + > + /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ > xennet_tx_buf_gc(dev); > > if (!netfront_tx_slot_available(np)) > netif_stop_queue(dev); > > spin_unlock_irq(>tx_lock); > - > - np->stats.tx_bytes += skb->len; > - np->stats.tx_packets++; > > return 0; > This moves the updating of both tx_bytes and tx_packets inside the spinlock, but as far as I can see we only _really_ need to move the tx_bytes update. Considering that we generally want to do as little work as possible while holding a lock, wouldn't the following be slightly better? Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/net/xen-netfront.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 489f69c..640e270 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -566,6 +566,9 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) if (notify) notify_remote_via_irq(np->netdev->irq); + np->stats.tx_bytes += skb->len; + + /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ xennet_tx_buf_gc(dev); if (!netfront_tx_slot_available(np)) @@ -573,7 +576,6 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) spin_unlock_irq(>tx_lock); - np->stats.tx_bytes += skb->len; np->stats.tx_packets++; return 0; - 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]: proc: export a processes resource limits via proc/
On Tue, Aug 14, 2007 at 01:04:02AM +0400, Alexey Dobriyan wrote:
> On Mon, Aug 13, 2007 at 04:11:30PM -0400, Neil Horman wrote:
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task,
> > char *buffer)
> > return sprintf(buffer, "%lu\n", points);
> > }
> >
> > +struct limit_names {
> > + char *name;
> > + char *unit;
> > +};
> > +
> > +static const struct limit_names lnames[RLIM_NLIMITS] = {
> > + [RLIMIT_CPU] = {"Max cpu time", "ms"},
> > + [RLIMIT_FSIZE] = {"Max file size", "bytes"},
> > + [RLIMIT_DATA] = {"Max data size", "bytes"},
> > + [RLIMIT_STACK] = {"Max stack size", "bytes"},
> > + [RLIMIT_CORE] = {"Max core file size", "bytes"},
> > + [RLIMIT_RSS] = {"Max resident set", "bytes"},
> > + [RLIMIT_NPROC] = {"Max processes", "processes"},
> > + [RLIMIT_NOFILE] = {"Max open files", "files"},
> > + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"},
> > + [RLIMIT_AS] = {"Max address space", "bytes"},
> > + [RLIMIT_LOCKS] = {"Max file locks", "locks"},
> > + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"},
>
> this and processes should be left empty methinks, because max signals is
> in fact unitless.
>
not sure I agree with that. According to the man page, RLIMIT_SIGPENDING is
counted in number of signals and RLIMIT_NPROC is counted as a number of
processes.
> > + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
> > + [RLIMIT_NICE] = {"Max nice priority", NULL},
> > + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
> > +};
>
> aha! trailing whitespace!
>
Fixed :)
> > +static int proc_pid_limits(struct task_struct *task, char *buffer)
> > +{
> > + unsigned int i;
> > + int count = 0;
> > + char *bufptr = buffer;
> > +
> > + struct rlimit rlim[RLIM_NLIMITS];
> > +
> > + read_lock(_lock);
> > + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) *
> > RLIM_NLIMITS));
>
> unneeded (, )
>
I prefer to explicitly show order of operations, but I'm wierd that way, so I'll
change it :)
> > + read_unlock(_lock);
>
> hmm, fork copies this under task lock of group leader and system calls
> in sys.c too. What's up?
>
> I'm sure it will give you nonsensical output because of wrong locks but
> I haven't checked.
>
I don't think so, I borrowed the code there from sys_getrlimit, which also reds
task->signal->rlim (only for one element instead of the whole array, so if its
broken here it should be broken there, but I don't see how.
> FWIW, it survived ~1 hour of cat /proc/*/limits, mini fork bombs, LTP,
> gdb testsuite and one sooper sikrit proggie. on core2
>
Its survived for a few days for me (while true; do cat /proc/*/limits;done),
with not noticible side effects (other than a slightly higher CPU load :)).
New patch with the ()'s and whitespace fixed.
Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
base.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224..b3ddf08 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -74,6 +74,7 @@
#include
#include
#include
+#include
#include "internal.h"
/* NOTE:
@@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char
*buffer)
return sprintf(buffer, "%lu\n", points);
}
+struct limit_names {
+ char *name;
+ char *unit;
+};
+
+static const struct limit_names lnames[RLIM_NLIMITS] = {
+ [RLIMIT_CPU] = {"Max cpu time", "ms"},
+ [RLIMIT_FSIZE] = {"Max file size", "bytes"},
+ [RLIMIT_DATA] = {"Max data size", "bytes"},
+ [RLIMIT_STACK] = {"Max stack size", "bytes"},
+ [RLIMIT_CORE] = {"Max core file size", "bytes"},
+ [RLIMIT_RSS] = {"Max resident set", "bytes"},
+ [RLIMIT_NPROC] = {"Max processes", "processes"},
+ [RLIMIT_NOFILE] = {"Max open files", "files"},
+ [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"},
+ [RLIMIT_AS] = {"Max address space", "bytes"},
+ [RLIMIT_LOCKS] = {"Max file locks", "locks"},
+ [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"},
+ [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
+ [RLIMIT_NICE] = {"Max nice priority", NULL},
+ [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
+};
+
+/* Display limits for a process */
+static int proc_pid_limits(struct task_struct *task, char *buffer)
+{
+ unsigned int i;
+ int count = 0;
+ char *bufptr = buffer;
+
+ struct rlimit rlim[RLIM_NLIMITS];
+
+ read_lock(_lock);
+ memcpy(rlim, task->signal->rlim, sizeof(struct rlimit) * RLIM_NLIMITS);
+ read_unlock(_lock);
+
+ /*
+* print the file header
+*/
+ count += sprintf([count], "%-25s %-20s %-20s %-10s\n",
+ "Limit","Soft Limit","Hard Limit","Units");
+
+ for (i=0; i < RLIM_NLIMITS; i++) {
+ if (rlim[i].rlim_cur ==
[PATCH] drivers/net/tlan: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
Sent 2007-05-01, no replys
diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
index 106dc1e..db630c4 100644
--- a/drivers/net/tlan.c
+++ b/drivers/net/tlan.c
@@ -337,7 +337,7 @@ static int TLan_PhyInternalService( struct net_device * );
static int TLan_PhyDp83840aCheck( struct net_device * );
*/
-static int TLan_MiiReadReg( struct net_device *, u16, u16, u16 * );
+static boolTLan_MiiReadReg( struct net_device *, u16, u16, u16 * );
static voidTLan_MiiSendData( u16, u32, unsigned );
static voidTLan_MiiSync( u16 );
static voidTLan_MiiWriteReg( struct net_device *, u16, u16, u16 );
@@ -2240,7 +2240,7 @@ TLan_ResetAdapter( struct net_device *dev )
u32 data;
u8 data8;
- priv->tlanFullDuplex = FALSE;
+ priv->tlanFullDuplex = false;
priv->phyOnline=0;
netif_carrier_off(dev);
@@ -2295,7 +2295,7 @@ TLan_ResetAdapter( struct net_device *dev )
TLan_DioWrite8( dev->base_addr, TLAN_ACOMMIT, 0x0a );
} else if ( priv->duplex == TLAN_DUPLEX_FULL ) {
TLan_DioWrite8( dev->base_addr, TLAN_ACOMMIT, 0x00 );
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
} else {
TLan_DioWrite8( dev->base_addr, TLAN_ACOMMIT, 0x08 );
}
@@ -2676,14 +2676,14 @@ void TLan_PhyStartLink( struct net_device *dev )
TLan_MiiWriteReg( dev, phy, MII_GEN_CTL, 0x);
} else if ( priv->speed == TLAN_SPEED_10 &&
priv->duplex == TLAN_DUPLEX_FULL) {
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
TLan_MiiWriteReg( dev, phy, MII_GEN_CTL, 0x0100);
} else if ( priv->speed == TLAN_SPEED_100 &&
priv->duplex == TLAN_DUPLEX_HALF) {
TLan_MiiWriteReg( dev, phy, MII_GEN_CTL, 0x2000);
} else if ( priv->speed == TLAN_SPEED_100 &&
priv->duplex == TLAN_DUPLEX_FULL) {
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
TLan_MiiWriteReg( dev, phy, MII_GEN_CTL, 0x2100);
} else {
@@ -2720,7 +2720,7 @@ void TLan_PhyStartLink( struct net_device *dev )
tctl &= ~TLAN_TC_AUISEL;
if ( priv->duplex == TLAN_DUPLEX_FULL ) {
control |= MII_GC_DUPLEX;
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
}
if ( priv->speed == TLAN_SPEED_100 ) {
control |= MII_GC_SPEEDSEL;
@@ -2775,9 +2775,9 @@ void TLan_PhyFinishAutoNeg( struct net_device *dev )
TLan_MiiReadReg( dev, phy, MII_AN_LPA, _lpa );
mode = an_adv & an_lpa & 0x03E0;
if ( mode & 0x0100 ) {
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
} else if ( ! ( mode & 0x0080 ) && ( mode & 0x0040 ) ) {
- priv->tlanFullDuplex = TRUE;
+ priv->tlanFullDuplex = true;
}
if ( ( ! ( mode & 0x0180 ) ) && ( priv->adapter->flags &
TLAN_ADAPTER_USE_INTERN_10 ) && ( priv->phyNum != 0 ) ) {
@@ -2896,17 +2896,17 @@ void TLan_PhyMonitor( struct net_device *dev )
*
**/
-int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
+bool TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
{
u8 nack;
u16 sio, tmp;
u32 i;
- int err;
+ boolerr;
int minten;
TLanPrivateInfo *priv = netdev_priv(dev);
unsigned long flags = 0;
- err = FALSE;
+ err = false;
outw(TLAN_NET_SIO, dev->base_addr + TLAN_DIO_ADR);
sio = dev->base_addr + TLAN_DIO_DATA + TLAN_NET_SIO;
@@ -2939,7 +2939,7 @@ int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16
reg, u16 *val )
TLan_SetBit(TLAN_NET_SIO_MCLK, sio);
}
tmp = 0x;
- err = TRUE;
+ err = true;
} else {/* ACK, so read data */
for (tmp = 0, i = 0x8000; i; i >>= 1) {
TLan_ClearBit(TLAN_NET_SIO_MCLK, sio);
diff --git a/drivers/net/tlan.h b/drivers/net/tlan.h
index 41ce0b6..e0791aa 100644
--- a/drivers/net/tlan.h
+++ b/drivers/net/tlan.h
@@ -33,9 +33,6 @@
*
Re: Linux 2.6.22.2
On Thu, Aug 09, 2007 at 05:40:16PM -0400, Ayaz Abdulla wrote:
> Yes, you are right. Copy and paste error. I have attached a patch which will
> fix this issue.
>
> Thanks for catching it.
> Ayaz
>
> Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
>
>
> Prakash Punnoor wrote:
> > Hi,
> > I just noticed that PHY_OUI_VITESSE == PHY_OUI_REALTEK. Is that really
> > intentional?
> >> diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> >> index 42ba1c0..a361dba 100644
> >> --- a/drivers/net/forcedeth.c
> >> +++ b/drivers/net/forcedeth.c
> >> @@ -550,6 +550,8 @@ union ring_type {
> >> /* PHY defines */
> >> #define PHY_OUI_MARVELL0x5043
> >> #define PHY_OUI_CICADA 0x03f1
> >> +#define PHY_OUI_VITESSE 0x01c1
> >> +#define PHY_OUI_REALTEK 0x01c1
> > - (?= =?)
> > //\ Prakash Punnoor /\\
> > V_/ \_V
> --- old/drivers/net/forcedeth.c 2007-08-09 17:37:12.0 -0400
> +++ new/drivers/net/forcedeth.c 2007-08-09 17:37:07.0 -0400
> @@ -551,7 +551,7 @@
> #define PHY_OUI_MARVELL 0x5043
> #define PHY_OUI_CICADA 0x03f1
> #define PHY_OUI_VITESSE 0x01c1
> -#define PHY_OUI_REALTEK 0x01c1
> +#define PHY_OUI_REALTEK 0x0732
> #define PHYID1_OUI_MASK 0x03ff
> #define PHYID1_OUI_SHFT 6
> #define PHYID2_OUI_MASK 0xfc00
Is this something that really matters for this driver? And if so, care
to send this patch to mainline as well as to the [EMAIL PROTECTED] team
with a proper changelog?
thanks,
greg k-h
-
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] [384/2many] MAINTAINERS - PPP PROTOCOL DRIVERS AND COMPRESSORS
Joe Perches writes: > On Mon, 2007-08-13 at 19:38 +1000, Paul Mackerras wrote: > > Except for drivers/net/ppp_synctty.c. > > It seems poor form to have 5 file entries where 1 would do. > > Would renaming this one file to pppsynctty.c work? It seems poor form to have to rename the file just because of a deficiency in the tools. Paul. - 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/23] document preferred use of volatile with atomic_t
On Mon, Aug 13, 2007 at 07:04:15AM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Document proper use of volatile for atomic_t operations.
Looks good, as did a once-over on the arch-specific files. Good stuff!!!
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
>
> --- linux-2.6.23-rc3-orig/Documentation/atomic_ops.txt2007-07-08
> 19:32:17.0 -0400
> +++ linux-2.6.23-rc3/Documentation/atomic_ops.txt 2007-08-13
> 03:36:43.0 -0400
> @@ -12,13 +12,20 @@
> C integer type will fail. Something like the following should
> suffice:
>
> - typedef struct { volatile int counter; } atomic_t;
> + typedef struct { int counter; } atomic_t;
> +
> + Historically, counter has been declared as a volatile int. This
> +is now discouraged in favor of explicitly casting it as volatile where
> +volatile behavior is required. Most architectures will only require such
> +a cast in atomic_read() and atomic_set(), as well as their 64-bit versions
> +if applicable, since the more complex atomic operations directly or
> +indirectly use assembly that results in volatile behavior.
>
> The first operations to implement for atomic_t's are the
> initializers and plain reads.
>
> #define ATOMIC_INIT(i) { (i) }
> - #define atomic_set(v, i)((v)->counter = (i))
> + #define atomic_set(v, i)(*(volatile int *)&(v)->counter = (i))
>
> The first macro is used in definitions, such as:
>
> @@ -38,7 +45,7 @@
>
> Next, we have:
>
> - #define atomic_read(v) ((v)->counter)
> + #define atomic_read(v) (*(volatile int *)&(v)->counter)
>
> which simply reads the current value of the counter.
>
-
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: binutils trouble was Re: [1/2] 2.6.23-rc3: known regressions with patches
On Tue, Aug 14, 2007 at 12:54:10AM +0200, Adrian Bunk wrote: > On Tue, Aug 14, 2007 at 12:42:05AM +0200, Andi Kleen wrote: > > On Mon, Aug 13, 2007 at 11:29:47PM +0200, Adrian Bunk wrote: > > > Debian 4.0 has older ones, and all distributions released more than a > > > year ago for sure also have older ones (the required patch went into > > > binutils CVS on 2006-05-30 and 2.17.50.0.3 was released on 2006-07-15). > > > > I have no problem on SUSE 10.0 (2.16.91.0.2-8) or SLES9 > > (2.15.90.0.1.1-32.10) > > which are both far older than a year. Both produce good looking > > vdso.sos. > > OK sorry, then I misunderstood it and missing -Wl,-z,max-page-size=4096 > -Wl,-z,common-page-size=4096 support is not the problem. It might be. The change to default to 1MB pages happened some time ago and then the common-page-size options were added some time after that. I expect you'll get the obscenly large 1MB vdso if your binutils happens to fall inside that time window, but before or after should be ok. I haven't tested it, but in theory a 1MB vdso should work (just waste a lot of memory and probably some CPU time) I was pondering to add a build time test for this and fail (not sure it's worth it) But the header offset problem that actually broke the compilation seemed to be something else, probably some sort of bug. > > sles8 (2.12.90.0.15; it was really one of the first production > > binutils for x86-64) doesn't work out of the box (looks like as-instr > > doesn't > > work anymore and it has another assembler issue I'll fix) > > but with that workarounded it also builds a reasonble looking vdso > > We had several reports of 2.12* not working (AFAIR also on i386), so > that's not a surprise. Ah I didn't see those. I should test it more often perhaps. I'll take a detailed look later, perhaps it's easy to fix. > > Sam, can you please take a look at the as-instr issue? It seems > > to succeed now when it should fail. > > > > It would be useful if someone could find out which binutils versions > > really not work. > > If Andre is working under Debian 3.1 (as his gcc version indicates) he's > using 2.15, and together with your SLES9 test it seems the border is > somewhere between 2.15 and 2.16. Could someone confirm? Then it could be documented. -Andi - 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] drivers/net/3c505: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
Sent 2007-05-01, no replys
diff --git a/drivers/net/3c505.c b/drivers/net/3c505.c
index e985a85..acede30 100644
--- a/drivers/net/3c505.c
+++ b/drivers/net/3c505.c
@@ -169,21 +169,6 @@ static int elp_debug;
/*
*
- * useful macros
- *
- */
-
-#ifndefTRUE
-#defineTRUE1
-#endif
-
-#ifndefFALSE
-#defineFALSE 0
-#endif
-
-
-/*
- *
* List of I/O-addresses we try to auto-sense
* Last element MUST BE 0!
*/
@@ -270,7 +255,7 @@ static inline void set_hsf(struct net_device *dev, int hsf)
spin_unlock_irqrestore(>lock, flags);
}
-static int start_receive(struct net_device *, pcb_struct *);
+static bool start_receive(struct net_device *, pcb_struct *);
static inline void adapter_reset(struct net_device *dev)
{
@@ -328,28 +313,28 @@ static inline void check_3c505_dma(struct net_device *dev)
}
/* Primitive functions used by send_pcb() */
-static inline unsigned int send_pcb_slow(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_slow(unsigned int base_addr, unsigned char byte)
{
unsigned long timeout;
outb_command(byte, base_addr);
for (timeout = jiffies + 5*HZ/100; time_before(jiffies, timeout);) {
if (inb_status(base_addr) & HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING "3c505: send_pcb_slow timed out\n");
- return TRUE;
+ return true;
}
-static inline unsigned int send_pcb_fast(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_fast(unsigned int base_addr, unsigned char byte)
{
unsigned int timeout;
outb_command(byte, base_addr);
for (timeout = 0; timeout < 4; timeout++) {
if (inb_status(base_addr) & HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING "3c505: send_pcb_fast timed out\n");
- return TRUE;
+ return true;
}
/* Check to see if the receiver needs restarting, and kick it if so */
@@ -386,7 +371,7 @@ static inline void prime_rx(struct net_device *dev)
* timeout is reduced to 500us).
*/
-static int send_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool send_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i;
unsigned long timeout;
@@ -396,14 +381,14 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
check_3c505_dma(dev);
if (adapter->dmaing && adapter->current_dma.direction == 0)
- return FALSE;
+ return false;
/* Avoid contention */
if (test_and_set_bit(1, >send_pcb_semaphore)) {
if (elp_debug >= 3) {
printk(KERN_DEBUG "%s: send_pcb entered while
threaded\n", dev->name);
}
- return FALSE;
+ return false;
}
/*
* load each byte into the command register and
@@ -435,7 +420,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
switch (GET_ASF(dev->base_addr)) {
case ASF_PCB_ACK:
adapter->send_pcb_semaphore = 0;
- return TRUE;
+ return true;
case ASF_PCB_NAK:
#ifdef ELP_DEBUG
@@ -453,7 +438,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
spin_unlock_irqrestore(>lock, flags);
abort:
adapter->send_pcb_semaphore = 0;
- return FALSE;
+ return false;
}
@@ -470,7 +455,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
*
*/
-static int receive_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool receive_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i, j;
int total_length;
@@ -487,7 +472,7 @@ static int receive_pcb(struct net_device *dev, pcb_struct *
pcb)
while (((stat = get_status(dev->base_addr)) & ACRF) == 0 &&
time_before(jiffies, timeout));
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
- return FALSE;
+ return false;
}
pcb->command = inb_command(dev->base_addr);
@@ -497,14 +482,14 @@ static int receive_pcb(struct net_device *dev, pcb_struct
* pcb)
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
printk(KERN_INFO "%s: status %02x\n", dev->name,
RE: [PATCH] [429/2many] MAINTAINERS - SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
@@ -4084,6 +4084,7 @@ P:Pat Gefre M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Supported +F: Documentation/ia64/serial.txt SGI VISUAL WORKSTATION 320 AND 540 P: Andrey Panin Huh? Perhaps this should be: +F: drivers/serial/sn_console.c -Tony - 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/4] Embed zone_id information within the zonelist->zones pointer
> So the only systems really affected are lance systems with >16MB. > I don't think we can stop Linux evolution for those sorry. They'll > just have to live with it. I think thats fair enough too. - 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/4] Embed zone_id information within the zonelist->zones pointer
On Mon, Aug 13, 2007 at 04:25:23PM -0700, Christoph Lameter wrote: > On Tue, 14 Aug 2007, Andi Kleen wrote: > > > > But they use GFP_DMA right now and drivers cannot use DMA32 if they want > > > > The way it was originally designed was that they use GFP_DMA32, > > which would map to itself on x86-64, to GFP_DMA on ia64 and to > > GFP_KERNEL on i386. Unfortunately that seems to have bitrotted > > (perhaps I should have better documented it) > > The DMA boundaries are hardware depending. A 4GB boundary > may not make sense on certain platforms. If it makes sense for the driver it has to make sense for the platform too. If not it cannot run the driver (which might be fine; a lot of architectures only run their own specialized drivers) > > > > to be cross platforms compatible? Doesnt the dma API completely do away > > > with these things? > > > > No GFP_DMA32 in my current plan is still there. > > AFAIK GFP_DMA32 is a x86_64 special that would be easy to remove. Dealing > with physical boundaries is current done via the dma interface right? Lets > keep it there? The difference between the low dma allocation and GFP_DMA32 is that the low dma allocation zone is isolated. This means it is not shared with user pages, no LRU, no vmscan, no try_to_free_pages etc. But that cannot be obviously done for a full 4GB, only for a small area. Right now on swiotlb systems we reserved 82MB for this (64MB swiotlb + 16MB ZONE_DMA). So the new zone is by default <100MB and can afford to be isolated. If GFP_DMA32 was merged into the mask allocator then it would need to learn about all that mess by itself. If GFP_DMA32 stays it can just use the current page allocator which avoids a lot of code duplication. The DMA allocator calls the normal page allocator implicitely though for a 4GB mask, but that still needs such a bit to specify. -Andi - 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/4] Embed zone_id information within the zonelist->zones pointer
On Mon, Aug 13, 2007 at 04:27:42PM -0700, Christoph Lameter wrote: > On Tue, 14 Aug 2007, Andi Kleen wrote: > > > > Ok then lets do it. > > > > Conversion only makes sense once an API with a explicit mask > > is in. Otherwise we have muddled semantics again. > > pci_set_consistent_dma_mask > > has that. While on x86 it is roughly identical (although the low level allocator is currently not very reliable) it makes a significant difference on some platforms. e.g. I was told on PA-RISC consistent memory is much more costly than non consistent ones. That's probably true on anything that's not full IO cache consistent. So while it would be reasonable semantics for x86 and IA64 it's not for everybody else. -Andi > - 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/
