From: Greg KH <greg@kroah.com>
To: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: Andrew Morton <akpm@osdl.org>,
USB Development List <linux-usb-devel@lists.sourceforge.net>,
Kernel Development List <linux-kernel@vger.kernel.org>,
Bart Prescott <bart.prescott@elandigitalsystems.com>
Subject: Re: USB: ftdi-elan: client driver for ELAN Uxxx adapters
Date: Thu, 7 Sep 2006 22:42:17 -0700 [thread overview]
Message-ID: <20060908054217.GA10302@kroah.com> (raw)
In-Reply-To: <200609051619.k85GJqV24114@elandigitalsystems.com>
On Tue, Sep 05, 2006 at 04:12:24PM +0100, Tony Olech wrote:
> + #define FTDI_ERR(format, arg...) printk(KERN_ERR "ftdi.%d " format \
> + " *ERROR*\n", ftdi->sequence_num, ## arg)
> + #define ELAN_ERR(format, arg...) printk(KERN_ERR "ftdi " format " *ERROR*\n", \
> + ## arg)
> + #define FTDI_WARN(format, arg...) printk(KERN_WARNING "ftdi.%d " format \
> + " WARNING\n", ftdi->sequence_num, ## arg)
> + #define ELAN_WARN(format, arg...) printk(KERN_WARNING "ftdi " format \
> + " WARNING\n", ## arg)
> + #define FTDI_INFO(format, arg...) printk(KERN_INFO "ftdi.%d " format "\n", \
> + ftdi->sequence_num, ## arg)
> + #define ELAN_INFO(format, arg...) printk(KERN_INFO "ftdi " format "\n", ## arg)
The dev_err, dev_info, and dev_warn() macros are incouraged to be used
instead of rolling your own, but this is no real big deal.
> + #include "usb_u132.h"
> + #define TD_DEVNOTRESP 5
> + /* Define these values to match your devices*/
> + #define USB_FTDI_ELAN_VENDOR_ID 0x0403
> + #define USB_FTDI_ELAN_PRODUCT_ID 0xd6ea
> + /* table of devices that work with this driver*/
> + static struct usb_device_id ftdi_elan_table[] = {
> + {USB_DEVICE(USB_FTDI_ELAN_VENDOR_ID, USB_FTDI_ELAN_PRODUCT_ID)},
> + { /* Terminating entry */ }
> + };
> +
> + MODULE_DEVICE_TABLE(usb, ftdi_elan_table);
> + /* Get a minor range for your devices from the usb maintainer*/
> + #define USB_FTDI_ELAN_MINOR_BASE 192
How many minor numbers do you need for this driver? Do you ever expect
to have more than one of these devices in a system? 8? 16? 256?
> + int ftdi_elan_send(void *data)
> + {
> + dump_stack();
> + return 0;
This seems like an odd function to export :)
> + }
> +
> +
> + EXPORT_SYMBOL(ftdi_elan_send);
Can this, and the other exports, be marked as EXPORT_SYMBOL_GPL()
instead?
> + void ftdi_elan_gone_away(struct platform_device *pdev)
> + {
> + struct usb_ftdi *ftdi = platform_device_to_usb_ftdi(pdev);
> + ftdi->gone_away += 1;
> + ftdi_elan_put_kref(ftdi);
> + }
> +
> +
> + EXPORT_SYMBOL(ftdi_elan_gone_away);
> + void ftdi_release_platform_dev(struct device *dev)
> + {
> + dev->parent = NULL;
> + dump_stack();
> + }
This also seems like an odd function...
> + /*
> + * usb class driver info in order to get a minor number from the usb core,
> + * and to have the device registered with devfs and the driver core
> + */
This comment is a bit out of date, as there is no more devfs anymore.
> + static struct usb_class_driver ftdi_elan_jtag_class = {
> + .name = "ftdi-%d-jtag",
> + .fops = &ftdi_elan_fops,
> + .minor_base = USB_FTDI_ELAN_MINOR_BASE,
> + };
> +
> + #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
We already have this macro in the kernel.
> + #define cPCIu132rd 0x0
> + #define cPCIu132wr 0x1
> + #define cPCIiord 0x2
> + #define cPCIiowr 0x3
> + #define cPCImemrd 0x6
> + #define cPCImemwr 0x7
> + #define cPCIcfgrd 0xA
> + #define cPCIcfgwr 0xB
> + #define cPCInull 0xF
> + #define cU132cmd_status 0x0
> + #define cU132flash 0x1
> + #define cPIDsetup 0x0
> + #define cPIDout 0x1
> + #define cPIDin 0x2
> + #define cPIDinonce 0x3
> + #define cCCnoerror 0x0
> + #define cCCcrc 0x1
> + #define cCCbitstuff 0x2
> + #define cCCtoggle 0x3
> + #define cCCstall 0x4
> + #define cCCnoresp 0x5
> + #define cCCbadpid1 0x6
> + #define cCCbadpid2 0x7
> + #define cCCdataoverrun 0x8
> + #define cCCdataunderrun 0x9
> + #define cCCbuffoverrun 0xC
> + #define cCCbuffunderrun 0xD
> + #define cCCnotaccessed 0xF
What do these defines refer to? Something in a spec somewhere?
in all, it's a lot of code, so I'll trust that it's working correctly :)
thanks,
greg k-h
parent reply other threads:[~2006-09-08 6:53 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <200609051619.k85GJqV24114@elandigitalsystems.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060908054217.GA10302@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=bart.prescott@elandigitalsystems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=tony.olech@elandigitalsystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox