Re: [PATCH] SH/Dreamcast - fix regressions, whitespace and memory leaks in Maple Bus driver
On Mon, Feb 04, 2008 at 08:23:44AM +, Adrian McMenamin wrote: > > On Mon, 2008-02-04 at 10:10 +0900, Paul Mundt wrote: > > On Sun, Feb 03, 2008 at 08:00:47PM +, Adrian McMenamin wrote: > > > From: Adrian McMenamin > > > > > This is useless if you are submitting the patch, especially if you're > > missing a mail address. > > > > >From Documentation/SubmittingPatches > > The canonical patch message body contains the following: > * > * - A "from" line specifying the patch author. > * > Which doesn't invalidate the missing address problem, and the fact that you are _already_ in the from line. > > > This patch fixes the regression noted here: > > > http://lkml.org/lkml/2008/1/26/189 as well as whitespace issues in the > > > previous commit of this driver and the memory leaks noted here: > > > http://lkml.org/lkml/2008/2/2/143 (as well as one or two other minor > > > cleanups). > > > > > The subject notes 3 specific things that are being addressed, but you've > > rolled this all in to one patch which makes it utterly impossible to > > figure out what you're actually fixing. At the very least, split this in > > to 3 different patches, each dealing with one of the things noted in the > > subject. The fact that regressions is plural also suggests you may want > > to split this down in to smaller patches that deal with specific > > regressions if they are not directly related. > > What would be the point of submitting patches of broken code just to > remove the whitespace your previous commit added to all the lines? > My previous commit was directly from _your_ patch, given that your patches have a history of whitespace damage, this doesn't seem like much of a stretch. It's true I neglected to run it through checkpatch, I'll be more careful with that in the future when applying patches from certain parties. The point of submitting a series of patches is so that it's obvious _what_ you are changing. Lumping it in with the whitespace changes just makes it impossible to read, as GregKH also hinted at when trying to figure out specifically what you were fixing. Since your patch splits up logically in to different components, it makes sense to split the patch up in to a series that makes it obvious. I'm not sure why this needs to be spelled out for you. -- 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: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. I've tested this patch and it seems to work OK with my hardware. Thank you! -- 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] SH/Dreamcast - fix regressions, whitespace and memory leaks in Maple Bus driver
On Sun, 2008-02-03 at 21:29 -0800, Greg KH wrote:
> On Sun, Feb 03, 2008 at 08:00:47PM +, Adrian McMenamin wrote:
> > From: Adrian McMenamin
> >
> > This patch fixes the regression noted here:
> > http://lkml.org/lkml/2008/1/26/189 as well as whitespace issues in the
> > previous commit of this driver and the memory leaks noted here:
> > http://lkml.org/lkml/2008/2/2/143 (as well as one or two other minor
> > cleanups).
>
> Which portion of the patch fixes the kobject WARN_ON()?
+ if (mdev->registered == 0) {
+ retval = device_register(&mdev->dev);
+ if (retval) {
+ printk(KERN_INFO
+ "Maple bus: Attempt to register device"
+ " (%x, %x) failed.\n",
+ mdev->port, mdev->unit);
+ maple_free_dev(mdev);
+ mdev = NULL;
+ return;
+ }
+ mdev->registered = 1;
+ }
}
Specifically the check on mdev->registered
Unfortunately the previous commit was completely corrupted by whitespace
everywhere so the patch essentially covers the whole dirver (I had a
choice of submitting broken code with whitespace removed or working code
with whitespace removed)
--
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] SH/Dreamcast - fix regressions, whitespace and memory leaks in Maple Bus driver
On Mon, 2008-02-04 at 10:10 +0900, Paul Mundt wrote: > On Sun, Feb 03, 2008 at 08:00:47PM +, Adrian McMenamin wrote: > > From: Adrian McMenamin > > > This is useless if you are submitting the patch, especially if you're > missing a mail address. > >From Documentation/SubmittingPatches The canonical patch message body contains the following: * * - A "from" line specifying the patch author. * > > This patch fixes the regression noted here: > > http://lkml.org/lkml/2008/1/26/189 as well as whitespace issues in the > > previous commit of this driver and the memory leaks noted here: > > http://lkml.org/lkml/2008/2/2/143 (as well as one or two other minor > > cleanups). > > > The subject notes 3 specific things that are being addressed, but you've > rolled this all in to one patch which makes it utterly impossible to > figure out what you're actually fixing. At the very least, split this in > to 3 different patches, each dealing with one of the things noted in the > subject. The fact that regressions is plural also suggests you may want > to split this down in to smaller patches that deal with specific > regressions if they are not directly related. > What would be the point of submitting patches of broken code just to remove the whitespace your previous commit added to all the lines? > > Signed off by: Adrian McMenamin <[EMAIL PROTECTED]> > > > Do not invent new sign-off tags, see Documentation/SubmittingPatches. > Scripts do end up having to parse this stuff. Yes, sorry for 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: wrong cylinders of kingston usb pendrive [intel 82801DB]
On Sun, Feb 03, 2008 at 05:59:38PM -0800, Greg KH wrote: > On Mon, Feb 04, 2008 at 01:50:37AM +0100, Patrick Ringl wrote: > > Hello, > > > > I am suffering from the following (usb-related?) problem: > > > > I have several different mashines - all x86 architecture - just lets call > > them mashineA, mashineB and mashineC. > > Is the kernel the same on all of these machines? I'm not sure it matters... usb-storage has no knowledge of CHS geometery. It deals entirely in LBA. Does anyone know where the kernel gets the CHS geometery equivalent from? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp0cO5f1PG26.pgp Description: PGP signature
Re: [PATCH 1/9] firewire: log GUID of new devices
I wrote:
> - else
> - fw_notify("created new fw device %s "
> - "(%d config rom retries, S%d00)\n",
> - device->device.bus_id, device->config_rom_retries,
> - 1 << device->max_speed);
> + } else {
> + if (device->config_rom_retries)
> + fw_notify("created device %s: GUID %08x%08x, S%d00, "
> + "%d config ROM retries\n",
> + device->device.bus_id,
> + device->config_rom[3], device->config_rom[4],
> + 1 << device->max_speed,
> + device->config_rom_retries);
Still to do: If the ROM reading failed, log how it failed and what was
read up until the failure.
--
Stefan Richter
-=-==--- --=- --=--
http://arcgraph.de/sr/
--
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/9] firewire: fw-sbp2: wait for completion of fetch agent reset
I wrote: > Like the old sbp2 driver, wait for the write transaction to the > AGENT_RESET to complete before proceeding (after login, after reconnect, > or in SCSI error handling). > > There is one occasion where AGENT_RESET is written to from atomic > context when getting DEAD status for a command ORB. There we still > continue without waiting for the transaction to complete because this > is more difficult to fix... In addition, we need to serialize agent resets by the SCSI error handler and the command ORB completion against ongoing reconnects/ relogins. -- Stefan Richter -=-==--- --=- --=-- http://arcgraph.de/sr/ -- 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/
