[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080527053737.GA19760@gollum.tnic>
Date: Tue, 27 May 2008 07:37:37 +0200
From: Borislav Petkov <petkovbb@...glemail.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc: linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/40] ide-floppy: merge idefloppy_transfer_pc() and
idefloppy_transfer_pc1()
On Tue, May 27, 2008 at 08:57:42PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 21 May 2008, Borislav Petkov wrote:
> > On Sun, May 18, 2008 at 08:56:33PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > * Check IDEFLOPPY_FLAG_ZIP_DRIVE flag in idefloppy_transfer_pc1()
> > > and skip idefloppy_transfer_pc2()-phase if the flag is not set.
> > >
> > > * Always use idefloppy_transfer_pc1() in idefloppy_issue_pc()
> > > and remove no longer needed idefloppy_transfer_pc().
> >
> > ... and also probably mv idefloppy_transfer_pc1() to something like
> > idefloppy_start_transfer_pc() and rename idefloppy_transfer_pc2() to something
> > more appropriate like e.g. idefloppy_do_transfer_pc() or similar and do away
> > with those misleading names and probably even the comments are superfluous then.
>
> Probably the most intuitive would be to do:
>
> idefloppy_transfer_pc1() -> idefloppy_transfer_pc()
>
> and
>
> idefloppy_transfer_pc2() -> idefloppy_do_transfer_pc()
>
> but I don't feel too strong about it and welcome other ideas
> (preferably in form of patches :).
^Hint^! :) Sure, what about the following:
--
From: Borislav Petkov <petkovbb@...il.com>
Date: Tue, 27 May 2008 07:31:37 +0200
Subject: [PATCH] ide-floppy: fix unfortunate function naming
mv idefloppy_transfer_pc1 idefloppy_start_pc_transfer
mv idefloppy_transfer_pc2 idefloppy_transfer_pc
which describes their functionality and disambiguates them. There should be no
functionality change introduced by this patch.
Signed-off-by: Borislav Petkov <petkovbb@...il.com>
---
drivers/ide/ide-floppy.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 0f3602a..b368943 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -399,12 +399,8 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
* service routine. In interrupt mode, the device sends an interrupt to signal
* that it is ready to receive a packet. However, we need to delay about 2-3
* ticks before issuing the packet or we gets in trouble.
- *
- * So, follow carefully. transfer_pc1 is called as an interrupt (or directly).
- * In either case, when the device says it's ready for a packet, we schedule
- * the packet transfer to occur about 2-3 ticks later in transfer_pc2.
*/
-static int idefloppy_transfer_pc2(ide_drive_t *drive)
+static int idefloppy_transfer_pc(ide_drive_t *drive)
{
idefloppy_floppy_t *floppy = drive->driver_data;
@@ -415,7 +411,13 @@ static int idefloppy_transfer_pc2(ide_drive_t *drive)
return IDEFLOPPY_WAIT_CMD;
}
-static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t *drive)
+
+/*
+ * Called as an interrupt (or directly). When the device says it's ready for a
+ * packet, we schedule the packet transfer to occur about 2-3 ticks later in
+ * transfer_pc.
+ */
+static ide_startstop_t idefloppy_start_pc_transfer(ide_drive_t *drive)
{
idefloppy_floppy_t *floppy = drive->driver_data;
struct ide_atapi_pc *pc = floppy->pc;
@@ -432,7 +434,7 @@ static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t *drive)
*/
if (pc->flags & PC_FLAG_ZIP_DRIVE) {
timeout = floppy->ticks;
- expiry = &idefloppy_transfer_pc2;
+ expiry = &idefloppy_transfer_pc;
} else {
timeout = IDEFLOPPY_WAIT_CMD;
expiry = NULL;
@@ -483,7 +485,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t *drive,
pc->retries++;
- return ide_issue_pc(drive, pc, idefloppy_transfer_pc1,
+ return ide_issue_pc(drive, pc, idefloppy_start_pc_transfer,
IDEFLOPPY_WAIT_CMD, NULL);
}
--
1.5.5.1
--
Regards/Gruß,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists