The usb-ohci driver, widely used on non-x86 platforms, has hit
the same issue. (Including on some ARM setups.) An EHCI driver
(usb 2.0, 60 MByte/sec) under way has it too.
The alternative of having every device driver implement their
own simplified (?) kmem_cache code would just seem wrong;
Also, PCI (Cardbus at least) support should behave
again, thanks to Dan Zink.
For USB hotplug, make sure you have modutils 2.4.2
(kernel 2.4.0 and later).
- Dave
- Original Message -
From: Greg KH [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL
How about this (with documentation fixes by David-B):
Actually I'd be just as happy to call the ARM pci_free_consistent()
behavior (BUG in_interrupt) the problem. Particularly if that ARM
patch works OK! I've gotten success reports with pci_pool from
folk using about half the architectures in
And my opinion is that the hot-plugged approach works for devices even
if they are soldered down ...
Yep. Though I tend to look at the whole problem as autoconfiguration
lately. Solving device naming (even the major/minor subproblem) is only
one part of having a complete autoconfiguration
I couldn't agree with you more. It gives me headaches at work. One note,
their is a except to the eth0 thing. USB to USB networking. It uses usb0,
etc. I personally which they use eth0.
USB to USB networking cables aren't ethernet.
I'm talking about a wireless connection. ipaq
The eth0..N naming is done RIGHT!
Only if it's augmented by additional device IDs, such as the
what 's the physical connection for this interface sort of
primitive that's been mentioned.
Nothing to do with the kernel but, one should then argue that the
current stuff in
[ Re why physical device IDs _should_ have a critical role in sysadmin ]
I would have to agree that stable is critical to not driving people
crazy. In the case of AIX, once a device is enumerated, it will retain
the same name across reboots. Enough information is kept about each
device to
I suppose that for network interface names, some convention for
interface ioctls would suffice to solve that identify step. PCI
devices would return the slot_name, USB devices need something
like a patch I posted to linux-usb-devel a few months back.
This is crap.
Only the ioctl
At this point of the discussion I would like to point to the Device Registry
patch (http://www.tjansen.de/devreg) that already solves these problems and
offers stable device ids for the identification of devices and finding their
/dev nodes.
The devreg device id has four
For identifying this is probably the right approach. However identifying is
not enough, as the ioctl discussion has shown. Capabilities are needed. How
can the device registry provide that information ?
My feedback on device registry 0.1 was that I really liked the
approach of _modeling_
Tbird-700 on MSI-6167 (Viper based) board.
from dmesg
-
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
USB
Note that there's a chip
And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
the root cause of the problem to me!
HWCACHE_ALIGN does not guarantee a certain byte alignment. And
additionally it's not even guaranteed that kmalloc() uses that
Anyways, is this the end of the discussion regarding my patch?
I think one of the maintainers for usb-uhci (Georg) said he'd
want the general fix ...
Manfred said plainly "usb-uhci is broken", Alan kinda
manuevered around my small problem, Dave Brownell looks
unconvinced. So?
There are two
At the time, I didn't feel like creating a custom sub-allocator just
for USB, ...
I'd be good to get it done "properly" at some point though.
Something like
struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align)
struct pci_pool *
pci_create_consistent_pool
(1) CONFIG_SLAB_DEBUG breaks the documented
requirement that the slab cache return adequately aligned
data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16 byte boundaries
It's documented in mm/slab.c (line 612 in
David S. Miller writes:
Russell King writes:
A while ago, I looked at what was required to convert the OHCI driver
to pci_alloc_consistent, and it turns out that the current interface is
highly sub-optimal. It looks good on the face of it, but it _really_
does need sub-page
unlike the slab allocator bug(s) I pointed out. (And which
Manfred seems to have gone silent on.)
which bugs?
See my previous email ... its behavior contradicts its spec,
and I'd sent a patch. You said you wanted kmalloc to have
an "automagic redzoning" feature, which would involve one
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers using those dma handles.
I wonder if it may be feasible to allocate a
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
I am against any API which provides this. It can be extremely
expensive to do this on some architectures,
The implementation I posted needed no architecture-specific
knowledge. If cost is the issue,
Given that some hardware must return the dma addresses, why
should it be a good thing to have an API that doesn't expose
the notion of a reverse mapping? At this level -- not the lower
level code touching hardware PTEs.
Because its' _very_ expensive on certain machines. You have
Grard --
Just for information to people that want to complexify the
pci_alloc_consistent() interface thats looks simple and elegant to me:
I certainly didn't propose that! Just a layer on top of the
pci_alloc_consistent code -- used as a page allocator, just
like you used it.
The object
The reverse mapping
code hast to be less than 0.1KB.
If reverse mapping means bus_to_virt(), then I would suggest not to
provide it since it is a confusing interface. OTOH, only a few drivers
need or want to retrieve the virtual address that lead to some bus dma
Your SCSI code went
I've been quite pleased to see many recent improvement in hotplug
support ... 2.4 test11 is now hotplugging USB network adapters for
me when I need that! And many other devices at least get their
driver modules autoloaded (using modutils support) even if some
devices still need hand setup before
- We have been getting deadlocks at hotplug time because
call_usermodehelper is synchronous: it returns control after the
usermode application has exited. But in some places (esp.
[un]register_netdevice) this happens with a lock held (rtnl_lock).
This cause `ifconfig' to get
- I don't think we can say that the kernel hotplug interface is
complete until we have real, working, tested userspace tools. David,
could you please summarise the state of play here? In particular,
what still needs to be done?
Well, for USB I would like to know which device
This BUG() probably means you need to enable DEBUG in mm/slab.c
before you try have OHCI use slab poisoning.
Enable both, or neither, and all should be fine.
- Dave
- Original Message -
From: Miles Lane [EMAIL PROTECTED]
To: Linux Kernel [EMAIL PROTECTED]; David Brownell [EMAIL
I am writing to let you know that in all test12-pre6+ kernels,
I get a "Bad PCI invocation" error when hotplug attempts to
handle the insertion of a USB host-controller into a Cardbus
slot.
That's new info ... you'd previously thought that it wasn't even
invoking /sbin/hotplug!
The scripts
If this makes it go away, then by all means apply this patch;
though I don't quite see what the failure mode would be.
The proximate cause of that Oops looked to be in one of the
UHCI drivers, but of course it's also possible that it was
triggered by driver misbehavior.
Have we identified
The proximate cause of that Oops looked to be in one of the
UHCI drivers, but of course it's also possible that it was
triggered by driver misbehavior.
You didn't look hard enough. 8;)
I suspected you had ... :-)
hub_thread got a disconnect event, called usb_disconnect,
which tried
Hi Miles,
The whole
"Bad PCI invocation" error was a red herring, sorry.
Not an endangered species ... even if Tux does like to
snack on them! :-)
I have since gone in a tested test12-pre5, test12-pre6 and
test12-pre8. test12-pre5 works. test12-pre6 fails utterly.
That's for
Matt --
It's pretty much the same patch (functionally) as I posted to the
linux-usb-devel mailing list, which I presumed would inform the hotplugging
people. Mea culpa, I seem to have been in error there.
Miles had a suggestion for a "linux-hotplug" mailing list; this
could have been a good
Matching Keith's modutils update, here's a a package of
hotplug scripts ... not yet as neatly packaged! And
also, not (yet) handling with the older file format for
the "modules.usbmap" files associated with 2.4.0 test (and
prerelease) kernels. It "ought" to behave with the usb
hotplug support
I'd guess this is because of a bug that crept into test9,
where a TD is now leaked ... you can get rid of the slab
BUG warning by commenting out the line at the top of
drivers/usb/usb-ohci.c that #defines OHCI_MEM_SLAB.
That TD leak prevents the kmem_cache from getting freed,
and hence prevents
linux-2.4.0-test10-pre7/drivers/usb/usb.c introduced a really
cool feature, where USB drivers can declare a data structure that
describes the various ID bytes of the USB devices that they are
relevant to.
It's the same tool architecture used with PCI: modules.pcimap
(and now
I'm glad to see the CardBus/PCI and network hotplug
support start happening!
Would you motivate two changes I noticed?
- Changing /sbin/hotplug invocations ... now it can
only support "add" and "del" events. (USB now
uses "add" and "remove", though "remove" doesn't
try to
- Changing /sbin/hotplug invocations ... now it can
only support "add" and "del" events. (USB now
uses "add" and "remove", though "remove" doesn't
try to do anything yet.)
This removes the intended flexibility whereby
different subsystems (such as
I suspect the ohci driver currently. I've been reviewing it a little and it
is full of code written by someone who does not know about pci write posting.
I think there's a lot of that going around ... I don't think any of what you
mentioned was in the Documentation/pci.txt writeup, or any
I found the problem.
CONFIG_DEBUG_SLAB "Debug memory allocation"
in the 2.4.2-ac series doesn't work with USB.
2.4.2-ac5 just booted and found the mouse correctly.
On to ac-21 now...
I just glanced at Alan's change list, it didn't have patches
that seemed to cover that (vs ac20).
You
Hi,
Here are updated patches getting usb-ohci and usb-uhci to
behave on an ac20 kernel with slab debugging enabled.
It uses the pci_pool API, discussed earlier.
- pcipool-0323.patch ... adds pci_pool apis to linux/pci.h;
bugfixes vs what I sent to linux-usb-devel yesterday
-
Same problem shows up with most of the USB network
drivers too. /proc/ksyms has the macro-wrapped version
of those names, not the mangled one.
Haven't established whether there's a problem when these
drivers are statically linked.
- Dave
-
To unsubscribe from this list: send the line
Apr 4 14:47:15 campari kernel: usb-ohci.c: bogus NDP=204 for OHCI
usb-00:07.4
Apr 4 14:47:15 campari kernel: usb-ohci.c: rereads as NDP=4
Means that your system would have oopsed if it hadn't
tested for the bogus register read (NDP). That's only one
path; other bogus reads (which could
On Monday 16 April 2007 3:03 am, Francis Moreau wrote:
Good .. this is more like an IRQ question though.
...
IRQ logic on that platform must do a few things, like:
- NR_IRQS includes the N interrupts triggered from that chip,
and their numbers probably fit right sometime after
Update various mailing list addresses to use lists.linux-foundation.org
instead of lists.osdl.org, to help phase out the old addresses.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
I *think* this generalizes beyond linux-pm ... and hey, maybe now I know why
the PM list spends so much time
Cleaning out some of my pending-reviews queue ... after you address
these comments I think what I'd like to do is sign off on one clean
patch, rather than initial-plus-cleanups.
On Monday 05 March 2007 2:41 am, Wu, Bryan wrote:
--- linux-2.6.orig/drivers/spi/Kconfig2007-03-01
On Tuesday 17 April 2007 12:04 am, Francis Moreau wrote:
BTW, are there any plan to make gpio usable from userspace ? I don't
know if it makes sense but I saw some patches on LKML that did that.
Only the usual plan: someone who wants that feature provides a driver,
which can be merged after
On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
Hi!
Are you _sure_ you have a 1-to-1 relationship here? No multiple devices
pointing to the same acpi node? Or the other way around? If so, you
are going to have to change the name to be something more unique.
I've wondered
On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
...
Assuming they all adopt that same parallel tree model, that seems
like a good idea. The tools will likely need to understand how ACPI
and OF differ, but there's no point
On Tuesday 17 April 2007 3:12 pm, Bill Davidsen wrote:
One reason was that there are (were?) a number of machines which only
powered down properly using apm. It was discussed as part of shutting
down after power failure when your UPS is running out of power.
At least the notification
On Tuesday 17 April 2007 8:03 pm, Greg KH wrote:
On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
Looks like the i8042 serial nodes will be bizarre too:
/sys/devices/pnp0/00:09
... touchpad's PNP node
/sys/devices/acpi_system:00/device:00/PNP0A03:00
On Tuesday 17 April 2007 8:10 pm, Len Brown wrote:
On Thursday 12 April 2007 17:14, David Brownell wrote:
--- g26.orig/drivers/acpi/glue.c2007-04-12 10:56:35.0 -0700
+++ g26/drivers/acpi/glue.c 2007-04-12 10:56:35.0 -0700
@@ -316,13 +316,19 @@ static int __init
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches in following messages ... a preliminary gpio_chip core
for such a framework, plus example support for one SOC family's
On Thursday 19 April 2007 1:05 am, Francis Moreau wrote:
On 4/17/07, David Brownell [EMAIL PROTECTED] wrote:
With regards to a userspace interface to GPIOs (rather than to
devices such as leds or switches they control):
In this case I'm not entirely sure how it'd work. I've seen a few
'/implementations of other
architectures in the kernel, but that did not really help me... I also
looked at the patch for the AT91RM9200 CPU posted by David Brownell...
You know, I started that partly because I couldn't find enough
info to satisfy my curiousity about how the new dyntick was
expected to work
On Sunday 22 April 2007, Remy Bohmer wrote:
Hello David,
Thanks for this patch you sent me. This patch will also increase the
clock resolution which is good in RT context.
Yeah, a 32768 Hz timer (battery backed) may leave a bit to be desired.
But, unfortunately, I have some problems with
On Monday 23 April 2007, Paul Sokolovsky wrote:
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches
On Wednesday 07 March 2007 3:48 pm, Chris Lesiak wrote:
From: Chris Lesiak [EMAIL PROTECTED]
This patch fixes a bug in the cleanup of an spi_bitbang bus.
It's nearly right, but see below.
@@ -505,28 +499,10 @@ EXPORT_SYMBOL_GPL(spi_bitbang_start);
*/
int spi_bitbang_stop(struct
On Friday 09 March 2007 8:55 am, Jean Delvare wrote:
+struct i2c_bitbang_gpio {
+ int sda;
+ int scl;
+};
...
Also, this structure alone isn't very useful. I'm waiting to see
drivers actually making use of it before I will consider merging this
patch at all.
The notion would
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
That's the right idea! But remember that
On Friday 09 March 2007 12:08 pm, Russell King wrote:
On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote:
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips
On Friday 09 March 2007 12:43 pm, Håvard Skinnemoen wrote:
On Fri, March 9, 2007 20:30, David Brownell wrote:
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have
On Saturday 10 March 2007 5:13 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. ...
---
This patch is different from the first patch in the following ways:
* Handles pins set up as open drain (aka multidrive) by toggling
On Saturday 10 March 2007 12:15 pm, Jean Delvare wrote:
Hi Haavard,
On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller,
No bug; read net/ethernet/eth.c to see what that parameter means.
drivers/usb/net/usbnet.c:
int
usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
{
struct usbnet *dev;
struct net_device *net;
struct
isn't defined. Other X86 boards
would need something similar, based on what chips are wired to the CPU.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- linux-2.6.20.noarch/drivers/rtc/Kconfig~ 2007-02-14 13:07:07.0
-0500
+++ linux
On Wednesday 14 February 2007 3:20 pm, Len Brown wrote:
I still need to resubmit the patch, for X86_PC, which defines the platform
device in the (common) case where PNPACPI isn't defined.
CONFIG_PNPACPI=y is not the common case?
It's certainly not in the defconfig for x86-64. And it's
various code-bloating fixes that got merged because of
this modpost bug
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
NOTE: this is a **RESEND** of a patch against 2.6.20-rc4 ... it's
past time to merge a fix, please!! I don't see an entry for modpost
in the MAINTAINERS file, so I'm
of get_rtc_dev()
It isn't needed in ACPI code anymore because
now ACPI always includes PNPACPI.
Cc: David Brownell [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Friday 16 February 2007 9:37 am, Nicolas Ferre wrote:
David Brownell :
[..]
Thanks! I'll be glad to see fewer versions of this driver floating around.
And to see the next version of the ads7843 patches ... :)
Hi,
Here is the ads7843 support for the ads7846 touchscreen driver
On Thursday 15 February 2007 9:12 pm, David Brownell wrote:
On Thursday 15 February 2007 8:38 pm, Len Brown wrote:
So I've taken Andi's advice and checked in the patches below.
OK; that simplifies things for me, good! I can discard that patch
(broken by Andi's pcspkr change anyway), stop
If you don't do it sooner, I'll look at the error paths in rndis
and/or usbnet.
Try that patch I sent by this morning. ISTR getting some
positive reports from that...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
need to
be prepared for the device node to be null.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/char/lp.c|2 +-
drivers/char/ppdev.c |2 +-
drivers/char/tipar.c |2 +-
drivers/i2c/busses/i2c-parport.c |3 ++-
drivers/parport
On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
One more thing:
rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
Unable to handle kernel NULL pointer dereference at 0030 RIP:
On Sunday 18 February 2007 9:28 pm, Randy Dunlap wrote:
On Sun, 18 Feb 2007 21:08:07 -0800 David Brownell wrote:
Currently a parport_driver can't get a handle on the device node for the
underlying parport (PNPACPI, PCI, etc). That prevents correct placement
of sysfs child nodes, which
On Monday 19 February 2007 6:18 am, Jean Delvare wrote:
Hi David,
On Sun, 18 Feb 2007 21:08:07 -0800, David Brownell wrote:
Currently a parport_driver can't get a handle on the device node for the
underlying parport (PNPACPI, PCI, etc). That prevents correct placement
of sysfs child
On Monday 19 February 2007 4:48 am, Nicolas Ferre wrote:
- /* maybe off internal vREF */
- if (use_internal) {
This part doesn't make sense. Could you say what you're trying
to do? The ads7846 requres an external vREF. Is the issue that
maybe the REF_OFF command isn't just
choice presentation.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/sound/soc/Kconfig
===
--- g26.orig/sound/soc/Kconfig 2007-03-18 14:11:36.0 -0700
+++ g26/sound/soc/Kconfig 2007-03-20 13:33:06.0
when using the obsolete old-style hotplug scripts ... which are unusable
on ~100 BogoMIPS embedded systems that only run busybox, but may have no
options for lots of external storage other than USB.) Yep, this is a LOT
faster too.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/scsi
On Wednesday 21 March 2007 4:01 am, Michael Tokarev wrote:
David Brownell wrote:
This teaches scsi devices how to support new style hotplug/coldplug:
using a modalias sysfs attribute for coldplug, and MODALIAS environment
variable for hotplug.
How this is different from http://marc.info
device may then be able to issue system wakeup events. RS232, USB, Ethernet,
and other drivers can use driver model wakeup flags as userspace directions
about how to trade off between the lowest power full off driver states and
the more functional wakeup-enabled ones.
Signed-off-by: David Brownell
such driver, but it doesn't
currently implement wake-on-LAN even in the standby mode.)
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/mach-at91/clock.c| 18 ++
arch/arm/mach-at91/generic.h |1 +
arch/arm/mach-at91/pm.c |7 +--
drivers/serial
On Thursday 22 March 2007 12:54 pm, Tino Keitel wrote:
On Thu, Mar 22, 2007 at 15:40:40 -0400, Alan Stern wrote:
_Something_ is generating those overcurrent
warnings, and it sure looks like a hardware malfunction.
But it works with 2.6.20.
So can you bisect to find what caused the
,
and updates non-legacy port drivers to initialize that device pointer.
That field replaces the analagous PCI-only support in parport_pc.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
NOTE this depends on an earlier patch to make pnp devices set up DMA,
parport is the primary user of legacy i8237 dma
port device
drivers will finally have a device to work with.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/parport/parport_pc.c | 39 +++
1 file changed, 39 insertions(+)
--- linux-2.6.21-pre.orig
class_device)
There are still drivers that should be updated, like some of the input
drivers; but they won't be any worse off than they are today.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/char/lp.c|2 +-
drivers/char/ppdev.c |2 +-
drivers/char
Fix unused variable compiler warning on non-SMP x86_64 configs.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- a/arch/x86_64/kernel/early-quirks.c
+++ b/arch/x86_64/kernel/early-quirks.c
@@ -73,9 +73,9 @@ static void __init ati_bugs(void)
static void intel_bugs(void)
{
+#ifdef
On Monday 26 March 2007 2:59 pm, Andrew Morton wrote:
On Mon, 26 Mar 2007 09:06:19 -0700
David Brownell [EMAIL PROTECTED] wrote:
Currently a parport_driver can't get a handle on the device node for the
underlying parport (PNPACPI, PCI, etc). That prevents correct placement
of sysfs
On Monday 26 March 2007 3:14 am, Wu, Bryan wrote:
Hi folks,
This patch cleanup blackfin SPI driver code and fix some coding style
problems.
Good, thanks. I'll forward the current state of my review, after
I cross-check it against these two patches.
That'll mean I need to re-start that
On Tuesday 03 April 2007 11:28 pm, Wu, Bryan wrote:
USB gadget rndis: skb_push function may return a pointer which is not
aligned as required by struct rndis_packet_msg_type.
Can you instead try to update the declaration of that struct
so that it's __attribute__((packed))? That's less
On Friday 06 April 2007 2:36 am, Zhang Rui wrote:
On Thu, 2007-04-05 at 03:58 -0700, David Brownell wrote:
For wakeup devices, the main issue I've seen is with button devices.
In my limited set of test sytems, everything else is either PCI, PNP,
or a bug (listing a non-existent device
On Thursday 05 April 2007 1:35 pm, Jan Engelhardt wrote:
obeys the only-ident-by-tabs rule, as does
1if (To control chain reactions, your odds
2Improve if you've got cadmium rods) {
3In your fission reactor
4Their lack is a factor
5}
6
On Friday 06 April 2007 12:16 pm, Jan Engelhardt wrote:
and that the inner block code
(lines 3 and 4) should have more indent than line 2.
We disagree. The inner block should in all cases have one-tab indent.
You disagree. We, as in, the kernel coders,
... agree with what I said,
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
and
if ((one___ ||
one_and_a_half)
This is a minor correctness fix: since the at91_cf driver probe() routine
is in the init section, it should use platform_driver_probe() instead of
leaving that pointer around in the driver struct after init section removal.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
This is a refresh
to
suspend/resume without a platform_driver.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Another patch sent to the linux-pcmcia black hole, now being
re-sent ...
--- osk2.orig/drivers/pcmcia/omap_cf.c 2007-03-17 21:00:49.0 -0700
+++ osk2/drivers/pcmcia/omap_cf.c 2007-04-01
On Friday 06 April 2007 2:37 pm, Jeremy Fitzhardinge wrote:
David Brownell wrote:
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Spaces are used
On Friday 06 April 2007 2:38 pm, Roland Dreier wrote:
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
At least you weren't the target of attacks there ... for daring to
actually follow the only published Linux style guide in that area!!
Please change your
On Friday 06 April 2007 3:04 pm, Jan Engelhardt wrote:
if (...) {
THAT WAS ONE MORE TAB
}
and
for (...) {
THAT WAS ALSO ONE MORE TAB
}
Come on, stop wasting everyone's time with utter nonsense.
I was never debating these two things.
On Friday 06 April 2007 3:07 pm, Jan Engelhardt wrote:
On Apr 6 2007 15:05, David Brownell wrote:
but... egads! Linus
put spaces before the s to line them up nicely!
more in the breach and all that I guess...
Yeah, nobody likes style nazis. On the other hand, it's rather
On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote:
David,
http://tglx.de/private/tglx/usbnet.png
/me recommends emacs-develock.el for colorful white space wreckage
display !
Then I'd have to switch to EMACS ... no thanks! ;)
At the risk of switching to a VI/EMACS flamewar (could
On Friday 06 April 2007 4:21 pm, Thomas Gleixner wrote:
David,
On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote:
This particular issue doesn't actually affect indentation, since the
tab trumps that space. So it's a bit off-agenda for this particular
flamage.
ROTFL, the tab
1 - 100 of 1706 matches
Mail list logo
