Hi
Add linux-scsi and linux-kernel in mail group.
Regards,
Peter Chan
Accusys, Inc.
---------- Forwarded message ----------
From: Peter Chan <[email protected]>
Date: Mon, 22 Oct 2007 18:17:49 +0800
Subject: Add ACCUSYS RAID driver for Linux i386/x86-64
To: Andrew Morton <[email protected]>
Cc: James Bottomley <[email protected]>,
[email protected], [email protected],
[email protected], [email protected]
Dear Morton
Thanks for your doing.
We modified source code as your requested. If you have any comment please
let me know.
Do you need RAID HBA to test at this stage? If "yes", Which address can i
ship RAID HBA for you?
Regards,
Peter Chan
Accusys, Inc.
From: "Peter Chan" <[email protected]>
Date: Tue, 23 Oct 2007 09:45:48 +0800
> Add linux-scsi and linux-kernel in mail group.
Please do not post your driver as a "RAR" attachment,
not only are most Linux folks not familiar with this
archive format, it is also an attachment type rejected
by just about every large email service provider out
there.
gmail.com itself automatically rejects this attachment
type, as I just learned by seeing several hundred bounces
hit vger.kernel.org's postmaster mailbox due to your posting.
On Mon, Oct 22, 2007 at 07:02:53PM -0700, David Miller wrote:
> From: "Peter Chan" <[email protected]>
> Date: Tue, 23 Oct 2007 09:45:48 +0800
>
> > Add linux-scsi and linux-kernel in mail group.
>
> Please do not post your driver as a "RAR" attachment,
> not only are most Linux folks not familiar with this
> archive format, it is also an attachment type rejected
> by just about every large email service provider out
> there.
Before resubmitting this in a different format, this looks
like it will need quite a bit of work before it's
in mergable state.
Just from a quick skim..
* Why are there separate drivers for i386 and x86-64 ?
(With i386 and x86-64 now being one arch/ this makes even
less sense)
Typically in Linux we have one driver capable of driving
the hardware, regardless of which architecture it's running on.
The differences between the two seem to be locking related,
which makes this look even more odd.
* lots of #ifdef LINUX_VERSION_CODE > 2.5.0 and similar.
These should just be removed.
* None of this should be necessary..
#include <linux/version.h>
#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
#define MODVERSIONS
#endif
/* modversions.h should be before module.h */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
#if defined(MODVERSIONS)
#include <config/modversions.h>
#endif
#endif
* Don't use absolute paths in includes
#include "/usr/src/linux/drivers/scsi/scsi.h"
#include "/usr/src/linux/drivers/scsi/hosts.h"
#include "/usr/src/linux/drivers/scsi/constants.h"
#include "/usr/src/linux/drivers/scsi/sd.h"
There's no guarantee (or need) for kernel source to be there.
* Instead of reinventing a linked list implementation, use
the one from <linux/list.h>
* Use <linux/types.h> instead of reinventing your own.
* Remove pointless wrappers like..
#define iowrite32 writel
#define ioread32 readl
and just use the functions directly.
* This raises some eyebrows..
#include "/usr/src/linux/drivers/scsi/scsi_module.c"
Asides from the absolute path problem, no new drivers
should be using this file. There's even a helpful comment
inside that file telling you this.
* This isn't nice..
#define AllocRequestIndex(ResIndex)\
{\
/*DISABLE_IRQ();*/\
AllocRequest++;\
if (RequestHead == NULL) PANIC("Request FULL");\
ResIndex = RequestHead;\
ResIndex->InUsed = TRUE;\
RequestHead = RequestHead->Next;\
/*ENABLE_IRQ();*/\
}
Drivers should never panic the box unless something
seriously critical is happening. An allocation failure
doesn't sound particularly catastrophic.
* You don't need to redefine the SCSI opcodes, they are
already defined for you in <scsi/scsi.h>
I stopped reading at this point. There's probably more lurking
under that, and scripts/checkpatch.pl will probably pick up
another bunch of nits.
Dave
--
http://www.codemonkey.org.uk
On Mon, 22 Oct 2007 18:17:49 +0800 "Peter Chan" <[email protected]> wrote:
> Dear Morton
>
> Thanks for your doing.
> We modified source code as your requested. If you have any comment please
> let me know.
> Do you need RAID HBA to test at this stage? If "yes", Which address can i
> ship RAID HBA for you?
Please, you really will need to become a bit more familiar with the way we
work. As far as I know, nobody in the linux world uses RAR format - that's
a windows thing. I doubt if anyone except I has actually gone to the
effort to decrypt that attachment.
Start with
Documentation/SubmittingPatches
Documentation/SubmittingDrivers
Documentation/SubmitChecklist
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
http://linux.yyz.us/patch-format.html
There are a number of remaining stylistic things which we can look at more
closely when we have patches which are in a usable form.
- Linux doesn't use capitalisation in variable names. Use "tail", not "Tail"
- Linux uses underscored to separate words. Use "reply_frame", not
"replyframe" or "ReplyFrame".
- We don't like to see code which has any dependency on
LINUX_VERSION_CODE or KENREL_VERSION: the code in Linux is suppsoed to
work correctly in the version of the kernel which it s found and that's
it.
- I don't know what this:
+#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
+ #define MODVERSIONS
+#endif
is doing, but it's probably wrong.
- Use request_node, not RequestNode, etc.
- Don't parenthesise the argument to `return'.
- I see at least one U32 in there. Please use u32. (Does U32 even work?)
- This:
+static int acs_ame_get_log(
+ struct Acs_Adapter *acs_adt,
+ struct EventLog *event_log)
isn't preferred style. Use
static int acs_ame_get_log(struct Acs_Adapter *acs_adt,
struct EventLog *event_log)
or, if you particularly dislike that, blow the 80-col rule and do
static int acs_ame_get_log(struct Acs_Adapter *acs_adt, struct EventLog *event_log)
- This
+ writel((replyframe), base_addr+AME_REPLY_MSG_PORT);
is overparenthesised.
- Beware that the scatter/gather APIs just got significantly changed.
You code might need adjustment to work against the latest mainline tree.
- What does CHAR_DEV do? Probably it should be a Kconfig CONFIG_* option.
- All the code around acs_ame_schedule_command() (which is incorrectly
identified as arcmsr_schedule_command in its comment block) is indented a
tab stop. That's really weird. Please make it normal.
- acs_ame_schedule_command() has an up-to-sixty-second busywait. Bad.
Can we get a sleep+wakeup in there?
- This:
+ struct
+ {
+ unsigned int vendor_id;
+ unsigned int device_id;
+ } const acs_ame_devices[] = {
+ { 0x14D6, DEVICEID_ACS_61000_XX }
+ , { 0x14D6, DEVICEID_ACS_62000_08 }
+ , { 0x1AB6, DEVICEID_ACS_61000_XX }
+ , { 0x1AB6, DEVICEID_ACS_62000_08 }
+ };
should be
static const struct {
unsigned int vendor_id;
unsigned int device_id;
} acs_ame_devices[] = {
{ 0x14D6, DEVICEID_ACS_61000_XX },
{ 0x14D6, DEVICEID_ACS_62000_08 },
{ 0x1AB6, DEVICEID_ACS_61000_XX },
{ 0x1AB6, DEVICEID_ACS_62000_08 },
};
which has many changes from the original.
I'd have thought that the kernel already has a data type for this, but
I can't find it. Most drivers just rely upon the normal PCI device ID
tables. It is suspicious that this one doesn't.
Anyway, that's just from a quick scan. There are a huge number of similar
issues in there. Please take some time to study some well-maintained Linux
driver code and the interfaces which scsi and PCI drivers use and try to
make this driver a lot more Linux-like, thanks.