Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 03:17:25PM +0200, Ahmed S. Darwish wrote: > Hi all, > I'm not able to find the DAC960 block driver maintainer. > If someones knows please reply :). After Leonard Zubkoff unfortunately died in a helicopter accident Dave Olien <[EMAIL PROTECTED]> did some great work on the driver. Maybe he's still around? Regards, Toon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 03:17:25PM +0200, Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). After Leonard Zubkoff unfortunately died in a helicopter accident Dave Olien [EMAIL PROTECTED] did some great work on the driver. Maybe he's still around? Regards, Toon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > Hi all, > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > please reply :). > > It's orphaned. Andrew can decide to merge this, or one of the > storage or block maintainers could possibly do that. > or it could go thru KJ, but then Andrew may still end up > merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > Hi all, > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > please reply :). > > It's orphaned. Andrew can decide to merge this, or one of the > storage or block maintainers could possibly do that. > or it could go thru KJ, but then Andrew may still end up > merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sun, 7 Jan 2007 04:00:10 +0200 Ahmed S. Darwish wrote: > On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > > > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > > > Hi all, > > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > > please reply :). > > > > It's orphaned. Andrew can decide to merge this, or one of the > > storage or block maintainers could possibly do that. > > or it could go thru KJ, but then Andrew may still end up > > merging it. > > Should Kernel janitors then care of cleaning orphaned files ?. Kernel janitors could do that (IMO). It's up to you where you want to send the patch. > If so, I should forward it to Andrew Morton without CCing LKML again, right ? I would expect that Andrew has seen the patch. Anyway, you should always send the patch to a mailing list and usually to a specific maintainer also (like Andrew or a subsystem maintainer or the KJ maintainer). [except for some security-related patches] --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
> Should Kernel janitors then care of cleaning orphaned files ?. If you have the hardware to run tests then yes, if not then they are best handled with caution. Working is preferred to pretty. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > Hi all, > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > please reply :). > > It's orphaned. Andrew can decide to merge this, or one of the > storage or block maintainers could possibly do that. > or it could go thru KJ, but then Andrew may still end up > merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
> Hi all,
> I'm not able to find the DAC960 block driver maintainer. If someones knows
> please reply :).
It's orphaned. Andrew can decide to merge this, or one of the
storage or block maintainers could possibly do that.
or it could go thru KJ, but then Andrew may still end up
merging it.
> A patch to switch kmalloc->kzalloc and to clean unneeded kammloc,
> pci_alloc_consistent casts
>
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
>
> diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
> index 8d81a3a..4febe7f 100644
> --- a/drivers/block/DAC960.c
> +++ b/drivers/block/DAC960.c
> @@ -1373,8 +1373,7 @@ static boolean
> DAC960_V2_EnableMemoryMailboxInterface(DAC960_Controller_T
>Controller->BounceBufferLimit = DAC690_V2_PciDmaMask;
>
>/* This is a temporary dma mapping, used only in the scope of this
> function */
> - CommandMailbox =
> - (DAC960_V2_CommandMailbox_T *)pci_alloc_consistent( PCI_Device,
> + CommandMailbox = pci_alloc_consistent(PCI_Device,
> sizeof(DAC960_V2_CommandMailbox_T), );
>if (CommandMailbox == NULL)
> return false;
> @@ -1879,8 +1878,8 @@ static boolean
> DAC960_V2_ReadControllerConfiguration(DAC960_Controller_T
>if (NewLogicalDeviceInfo->LogicalDeviceState !=
> DAC960_V2_LogicalDevice_Offline)
> Controller->LogicalDriveInitiallyAccessible[LogicalDeviceNumber] = true;
> - LogicalDeviceInfo = (DAC960_V2_LogicalDeviceInfo_T *)
> - kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T), GFP_ATOMIC);
> + LogicalDeviceInfo = kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T),
> +GFP_ATOMIC);
>if (LogicalDeviceInfo == NULL)
> return DAC960_Failure(Controller, "LOGICAL DEVICE ALLOCATION");
>Controller->V2.LogicalDeviceInformation[LogicalDeviceNumber] =
> @@ -2113,8 +2112,8 @@ static boolean
> DAC960_V2_ReadDeviceConfiguration(DAC960_Controller_T
>if (!DAC960_V2_NewPhysicalDeviceInfo(Controller, Channel, TargetID,
> LogicalUnit))
> break;
>
> - PhysicalDeviceInfo = (DAC960_V2_PhysicalDeviceInfo_T *)
> - kmalloc(sizeof(DAC960_V2_PhysicalDeviceInfo_T), GFP_ATOMIC);
> + PhysicalDeviceInfo = kmalloc(sizeof(DAC960_V2_PhysicalDeviceInfo_T),
> + GFP_ATOMIC);
>if (PhysicalDeviceInfo == NULL)
> return DAC960_Failure(Controller, "PHYSICAL DEVICE ALLOCATION");
>Controller->V2.PhysicalDeviceInformation[PhysicalDeviceIndex] =
> @@ -2122,8 +2121,8 @@ static boolean
> DAC960_V2_ReadDeviceConfiguration(DAC960_Controller_T
>memcpy(PhysicalDeviceInfo, NewPhysicalDeviceInfo,
> sizeof(DAC960_V2_PhysicalDeviceInfo_T));
>
> - InquiryUnitSerialNumber = (DAC960_SCSI_Inquiry_UnitSerialNumber_T *)
> - kmalloc(sizeof(DAC960_SCSI_Inquiry_UnitSerialNumber_T), GFP_ATOMIC);
> + InquiryUnitSerialNumber = kmalloc(
> + sizeof(DAC960_SCSI_Inquiry_UnitSerialNumber_T), GFP_ATOMIC);
>if (InquiryUnitSerialNumber == NULL) {
> kfree(PhysicalDeviceInfo);
> return DAC960_Failure(Controller, "SERIAL NUMBER ALLOCATION");
> @@ -4949,8 +4948,8 @@ static void
> DAC960_V2_ProcessCompletedCommand(DAC960_Command_T *Command)
> PhysicalDevice.LogicalUnit = NewLogicalDeviceInfo->LogicalUnit;
> Controller->V2.LogicalDriveToVirtualDevice[LogicalDeviceNumber] =
> PhysicalDevice;
> - LogicalDeviceInfo = (DAC960_V2_LogicalDeviceInfo_T *)
> - kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T), GFP_ATOMIC);
> + LogicalDeviceInfo = kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T),
> + GFP_ATOMIC);
> Controller->V2.LogicalDeviceInformation[LogicalDeviceNumber] =
> LogicalDeviceInfo;
> DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) "
> @@ -5709,14 +5708,14 @@ static boolean
> DAC960_CheckStatusBuffer(DAC960_Controller_T *Controller,
>unsigned int NewStatusBufferLength = DAC960_InitialStatusBufferSize;
>while (NewStatusBufferLength < ByteCount)
> NewStatusBufferLength *= 2;
> - Controller->CombinedStatusBuffer =
> - (unsigned char *) kmalloc(NewStatusBufferLength, GFP_ATOMIC);
> + Controller->CombinedStatusBuffer = kmalloc(NewStatusBufferLength,
> + GFP_ATOMIC);
>if (Controller->CombinedStatusBuffer == NULL) return false;
>Controller->CombinedStatusBufferLength = NewStatusBufferLength;
>return true;
> }
> - NewStatusBuffer = (unsigned char *)
> -kmalloc(2 * Controller->CombinedStatusBufferLength, GFP_ATOMIC);
> + NewStatusBuffer = kmalloc(2 * Controller->CombinedStatusBufferLength,
> + GFP_ATOMIC);
>if (NewStatusBuffer == NULL)
> {
>DAC960_Warning("Unable to expand Combined Status Buffer
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 08:36:23AM -0500, Robert P. J. Day wrote: > a couple bits of advice here. you should start your patch > submission with *only* that descriptive text you want included in the > log, followed by your "Signed-off-by" line, then a line containing > "---". > > *after* that "---" line, and *before* you start the actual patch, > you can add superfluous text, like asking about who the maintainer is, > so that informal dialogue like that doesn't become part of the > permanent patch record. > rday Thanks for all the good notes .. -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On Sat, 6 Jan 2007, Ahmed S. Darwish wrote: > Hi all, > I'm not able to find the DAC960 block driver maintainer. If someones knows > please reply :). > > A patch to switch kmalloc->kzalloc and to clean unneeded kammloc, > pci_alloc_consistent casts > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]> > > diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c a couple bits of advice here. you should start your patch submission with *only* that descriptive text you want included in the log, followed by your "Signed-off-by" line, then a line containing "---". *after* that "---" line, and *before* you start the actual patch, you can add superfluous text, like asking about who the maintainer is, so that informal dialogue like that doesn't become part of the permanent patch record. in short, your patch should look like: A patch to switch... Signed-off-by: ... --- i'm not sure who the maintainer is. can anyone help? diff --git ... rday - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sat, 6 Jan 2007, Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). A patch to switch kmalloc-kzalloc and to clean unneeded kammloc, pci_alloc_consistent casts Signed-off-by: Ahmed Darwish [EMAIL PROTECTED] diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c a couple bits of advice here. you should start your patch submission with *only* that descriptive text you want included in the log, followed by your Signed-off-by line, then a line containing ---. *after* that --- line, and *before* you start the actual patch, you can add superfluous text, like asking about who the maintainer is, so that informal dialogue like that doesn't become part of the permanent patch record. in short, your patch should look like: A patch to switch... Signed-off-by: ... --- i'm not sure who the maintainer is. can anyone help? diff --git ... rday - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 08:36:23AM -0500, Robert P. J. Day wrote: a couple bits of advice here. you should start your patch submission with *only* that descriptive text you want included in the log, followed by your Signed-off-by line, then a line containing ---. *after* that --- line, and *before* you start the actual patch, you can add superfluous text, like asking about who the maintainer is, so that informal dialogue like that doesn't become part of the permanent patch record. rday Thanks for all the good notes .. -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
Hi all,
I'm not able to find the DAC960 block driver maintainer. If someones knows
please reply :).
It's orphaned. Andrew can decide to merge this, or one of the
storage or block maintainers could possibly do that.
or it could go thru KJ, but then Andrew may still end up
merging it.
A patch to switch kmalloc-kzalloc and to clean unneeded kammloc,
pci_alloc_consistent casts
Signed-off-by: Ahmed Darwish [EMAIL PROTECTED]
diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index 8d81a3a..4febe7f 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -1373,8 +1373,7 @@ static boolean
DAC960_V2_EnableMemoryMailboxInterface(DAC960_Controller_T
Controller-BounceBufferLimit = DAC690_V2_PciDmaMask;
/* This is a temporary dma mapping, used only in the scope of this
function */
- CommandMailbox =
- (DAC960_V2_CommandMailbox_T *)pci_alloc_consistent( PCI_Device,
+ CommandMailbox = pci_alloc_consistent(PCI_Device,
sizeof(DAC960_V2_CommandMailbox_T), CommandMailboxDMA);
if (CommandMailbox == NULL)
return false;
@@ -1879,8 +1878,8 @@ static boolean
DAC960_V2_ReadControllerConfiguration(DAC960_Controller_T
if (NewLogicalDeviceInfo-LogicalDeviceState !=
DAC960_V2_LogicalDevice_Offline)
Controller-LogicalDriveInitiallyAccessible[LogicalDeviceNumber] = true;
- LogicalDeviceInfo = (DAC960_V2_LogicalDeviceInfo_T *)
- kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T), GFP_ATOMIC);
+ LogicalDeviceInfo = kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T),
+GFP_ATOMIC);
if (LogicalDeviceInfo == NULL)
return DAC960_Failure(Controller, LOGICAL DEVICE ALLOCATION);
Controller-V2.LogicalDeviceInformation[LogicalDeviceNumber] =
@@ -2113,8 +2112,8 @@ static boolean
DAC960_V2_ReadDeviceConfiguration(DAC960_Controller_T
if (!DAC960_V2_NewPhysicalDeviceInfo(Controller, Channel, TargetID,
LogicalUnit))
break;
- PhysicalDeviceInfo = (DAC960_V2_PhysicalDeviceInfo_T *)
- kmalloc(sizeof(DAC960_V2_PhysicalDeviceInfo_T), GFP_ATOMIC);
+ PhysicalDeviceInfo = kmalloc(sizeof(DAC960_V2_PhysicalDeviceInfo_T),
+ GFP_ATOMIC);
if (PhysicalDeviceInfo == NULL)
return DAC960_Failure(Controller, PHYSICAL DEVICE ALLOCATION);
Controller-V2.PhysicalDeviceInformation[PhysicalDeviceIndex] =
@@ -2122,8 +2121,8 @@ static boolean
DAC960_V2_ReadDeviceConfiguration(DAC960_Controller_T
memcpy(PhysicalDeviceInfo, NewPhysicalDeviceInfo,
sizeof(DAC960_V2_PhysicalDeviceInfo_T));
- InquiryUnitSerialNumber = (DAC960_SCSI_Inquiry_UnitSerialNumber_T *)
- kmalloc(sizeof(DAC960_SCSI_Inquiry_UnitSerialNumber_T), GFP_ATOMIC);
+ InquiryUnitSerialNumber = kmalloc(
+ sizeof(DAC960_SCSI_Inquiry_UnitSerialNumber_T), GFP_ATOMIC);
if (InquiryUnitSerialNumber == NULL) {
kfree(PhysicalDeviceInfo);
return DAC960_Failure(Controller, SERIAL NUMBER ALLOCATION);
@@ -4949,8 +4948,8 @@ static void
DAC960_V2_ProcessCompletedCommand(DAC960_Command_T *Command)
PhysicalDevice.LogicalUnit = NewLogicalDeviceInfo-LogicalUnit;
Controller-V2.LogicalDriveToVirtualDevice[LogicalDeviceNumber] =
PhysicalDevice;
- LogicalDeviceInfo = (DAC960_V2_LogicalDeviceInfo_T *)
- kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T), GFP_ATOMIC);
+ LogicalDeviceInfo = kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T),
+ GFP_ATOMIC);
Controller-V2.LogicalDeviceInformation[LogicalDeviceNumber] =
LogicalDeviceInfo;
DAC960_Critical(Logical Drive %d (/dev/rd/c%dd%d)
@@ -5709,14 +5708,14 @@ static boolean
DAC960_CheckStatusBuffer(DAC960_Controller_T *Controller,
unsigned int NewStatusBufferLength = DAC960_InitialStatusBufferSize;
while (NewStatusBufferLength ByteCount)
NewStatusBufferLength *= 2;
- Controller-CombinedStatusBuffer =
- (unsigned char *) kmalloc(NewStatusBufferLength, GFP_ATOMIC);
+ Controller-CombinedStatusBuffer = kmalloc(NewStatusBufferLength,
+ GFP_ATOMIC);
if (Controller-CombinedStatusBuffer == NULL) return false;
Controller-CombinedStatusBufferLength = NewStatusBufferLength;
return true;
}
- NewStatusBuffer = (unsigned char *)
-kmalloc(2 * Controller-CombinedStatusBufferLength, GFP_ATOMIC);
+ NewStatusBuffer = kmalloc(2 * Controller-CombinedStatusBufferLength,
+ GFP_ATOMIC);
if (NewStatusBuffer == NULL)
{
DAC960_Warning(Unable to expand Combined Status Buffer -
Truncating\n,
--
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). It's orphaned. Andrew can decide to merge this, or one of the storage or block maintainers could possibly do that. or it could go thru KJ, but then Andrew may still end up merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
Should Kernel janitors then care of cleaning orphaned files ?. If you have the hardware to run tests then yes, if not then they are best handled with caution. Working is preferred to pretty. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On Sun, 7 Jan 2007 04:00:10 +0200 Ahmed S. Darwish wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). It's orphaned. Andrew can decide to merge this, or one of the storage or block maintainers could possibly do that. or it could go thru KJ, but then Andrew may still end up merging it. Should Kernel janitors then care of cleaning orphaned files ?. Kernel janitors could do that (IMO). It's up to you where you want to send the patch. If so, I should forward it to Andrew Morton without CCing LKML again, right ? I would expect that Andrew has seen the patch. Anyway, you should always send the patch to a mailing list and usually to a specific maintainer also (like Andrew or a subsystem maintainer or the KJ maintainer). [except for some security-related patches] --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish [EMAIL PROTECTED] wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). It's orphaned. Andrew can decide to merge this, or one of the storage or block maintainers could possibly do that. or it could go thru KJ, but then Andrew may still end up merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc-kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish [EMAIL PROTECTED] wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: Hi all, I'm not able to find the DAC960 block driver maintainer. If someones knows please reply :). It's orphaned. Andrew can decide to merge this, or one of the storage or block maintainers could possibly do that. or it could go thru KJ, but then Andrew may still end up merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
