login
Search
Hi list, here are some more cleanups to the firedtv driver. As mentioned during the last round of updates, this driver is currently hosted in a branch at kernel.org's linux1394-2.6.git repo (actually three branches) with the goal to make it merge-ready for 2.6.28(-rc1) --- I hope. Quilt series exist too. More info about the git branches and quilt series can be found at http://user.in-berlin.de/~s5r6/linux1394/firedtv/. I will upload the new patches to these repos later today. This series of updates touches the ieee1394 interface of the driver and cleans up some aspects of the driver initialization and device probing. The three ieee1394 core patches in this series have already been posted to the linux1394-devel mailinglist a while ago. What I would still like to do before posting a proper announcement and review patch on LKML is - many trivial stylistic cleanups, - don't use bitfields for on-the-wire data (there is a bug with big endian CPUs in the driver due to its bitfields), - rename variables, functions, files, and the driver subdirectory from firesat to firedtv. (The module is already called firedtv.) I will follow up with the following patches: 01/10 ieee1394: use correct barrier types between accesses of nodeid and generation 02/10 ieee1394: add hpsb_node_read() and hpsb_node_lock() 03/10 ieee1394: inherit ud vendor_id from node vendor_id 04/10 firedtv: use hpsb_node_read(), _write(), _lock() 05/10 firedtv: add vendor_id and version to driver match table 06/10 firedtv: remove unused dual subunit code from initialization 07/10 firedtv: fix initialization of dvb_frontend.ops 08/10 firedtv: remove unused struct members 09/10 firedtv: fix string comparison and a few sparse warnings 10/10 firedtv: register input device as child of a FireWire device Combined diffstat: drivers/ieee1394/nodemgr.c | 10 drivers/ieee1394/nodemgr.h | 18 + drivers/media/dvb/firesat/avc_api.c | 187 ++++---------- ...
Dearest Beloved, Allah is great and in his name I come to you. As you read this, I don't want you to feel sorry for me.......because......I believe everyone will die someday. I have been diagnosed with esophageal cancer. It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts. The situation has gotten complicated recently with my inability to hear or speak (being deaf and dump now). I have not particularly lived my life so well, as I never really cared for anyone (not even myself) but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends. I have decided to give also to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria, Malaysia and some countries in Africa. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Europe; they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which no one knows of is the huge cash sum of Eleven Million British pounds Sterling (GBP11 million) that I deposited sometime ago in an offshore account in a bank abroad. I will want you to help me collect these de posited funds and use the funds t PLEASE SEND YOUR RESPONSE TO ME WITH YOUR DETAILED INFORMATION AND IDENTIFICATION SO THAT I CAN FORWARD TO THE BANK WHERE FUND IS ...
Hi all, You are getting this message because you have expressed interest in the Linux Driver project. I have set up a mailing list for this, which everyone is now subscribed to. If you want off of the list, just follow the directions at the bottom of this message, or email me directly, I'll be glad to take you off. Sorry for the very long delay in getting this project back up off the ground. When I first announced it back in January, I never expected it to be so popular. Unfortunately, it ended up being pushed way back on my priority list as I had to deal with my day job at Novell first, then my Linux kernel development, then with any spare time left over, this project. The good news is that this has now changed. As of today, Novell is sponsoring me to work on this Linux driver project as my first priority. This means I will have the time and resources to commit to managing the different developers and driver projects as part of my daily job. So, to kick things off, everyone go look at the new wiki we have installed at: www.linuxdriverproject.org It's pretty bare-bones, but should be enough to get people started with how to interact with the project. As individual developers, we have a lot of companies that are currently waiting for developers. The new group of project managers will soon be contacting people on this list with requests for help for specific projects. Please help them out and work with them to help create drivers for the different companies involved. If you are a project manager, I'll be poking you all with the different companies that have contacted me with requests to help you all start going on them. If you are with a company, and you haven't heard from me in a few months as to the status of your driver project, please poke me again so that I can set things up in the new structure so that your driver gets properly developed and maintained. We also need general help getting the word out about this project. If anyone has any PR ...
Christopher Green 28 Hill gate Place London W8 7SS United Kingdom Good day, I am Christopher Green, a financial consultant attached to fidelity investments international, a fund management company with over US$2,000,000,000.00 (Two Billion United States Dollars) capital investment fund. I handle all our investor's direct capital funds and extract 1.2% Excess Maximum Return Capital Profit (EMRCP) per annum on each of the Investor's Marginal Capital Fund. As an expert in this profession, I have funds amounting to US$25,000,000.00 (Twenty-Five Million United States Dollars) from the Investor's EMRCP and hereby looking for someone to trust who will stand as an Investor to receive the fund as Annual Investment Proceeds from Fidelity Marginal Capital Fund for our own partnership business investment in his/her country. All confirmable documents to support this Investment Fund will be made available to you. Meanwhile, I have worked out the modalities and technicalities so that the funds can be claimed in any of our six clearing houses without any hitches. All I require is your honest co-operation. I guarantee that this will be executed under a legitimate arrangement and no government involvement at all. Hope to hear from you soon. Regards, Christopher Green _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Hello list, I bought myself a super-cheap USB drawing tablet, and (shocker) there's no linux driver that supports it. Using SnoopyPro, I was able to reverse-engineer the messages that get passed back and forth to the device, so I'm pretty sure I know exactly how the thing works. Given that information, how hard would it be to make a driver for it, or extend an existing one? Steve _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
The mailing list is having problems, hopefully it is back up and running now... greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
I come from a python background and recently I've been wanting to start writing drivers for Linux. I looked at several different resources (A bunch of docs written by GKH, JCorbet, and etc.) and they have been of great help. However, I have some questions which were not really answered. Any help would be greatly appreciated. 1. I am familiar with C but have never really written a driver. What are the guidelines? Meaning, what are best practices on how to write these drivers. Specifically, what should go in header .h files and what should not (Maybe that's more related to generic C programming...). When is it appropriate to place them in /usr/include instead of the driver folder. 2. What about debugging drivers? I have read a bunch of docs talking about gdb, kdbg, etc. But again what are best practices here? 3. How do I know if a driver has already been written? Right now, I simply do a grep -R trying to match several device name strings. 4. Tips on how to get started? I have read several example drivers but are there any 'platinum' class drivers that you can recommend that is clear and that you recommend regularly to beginners. (Specifically networking phy drivers in my case.) I apologize if these questions have been answered/asked before. Thanks for any help. Amit _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
what is the status of this initiative ? -JoJo _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
An Iraqi made a fixed deposit of $24.5m usd in my bank branch (Hang Seng Bank,Hong Kong) where am a director and he died with his entire family in the war leaving behind no next of kin, am ready to share 50/50 with you if you choose to stand as my deceased client's next of kin. if interested mail me at the address below: y.ming97@yahoo.com.hk Yours Truly, Ming Yang. _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Hi crew, After some upgrades to the server, the folks at Gentoo decided to fix up some initial mistakes they made with the mailman installation. I've shuffled things around now to the new, fixed, compliant format. All seems fine, but if anything does go wobbly over the next few days please let me know. (You may have noticed some oddities over the past few days, maybe a few bounced messages or something, I believe I've addressed those issues now). Regards, Tomasz _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Terrific. Thanks for your efforts Greg. As a matter of infrastructure, I'm wondering whether the newly released Novell "Policy Forge" site might be a very useful tool for coordinating some of these efforts. You can check it out here: http://developer.novell.com/forge/bin/view/NovellForge Briefly, Policy Forge is a controlled access Forge site, hosted at Novell. It provides registered members with a private: * bugzilla * subversion repository * wiki * ftp site * mailing lists I am using it very successfully for my, err, 'day job' on a project involving 8 [hard|soft]ware vendors and the customer with a mix of proprietary and GPL code. Given the sensitive nature of some of the projects, this might provide the necessary access controls needed for development purposes. Best, -PWM
As much as I would like to recommend using the Novell infrastructure, I can't. We currently have access to a dedicated server and free bandwidth on which we can put any of the above if we so desire. We also have full control over the box, with some very capable sysadmins helping us out. Also, all of that would be a lot of overkill for what we need to do here. To do a project, I expect the following to be used: - email between the developers, project managers, and company involved. We can create separate mailing lists to make this easy if necessary, or if confidentiality is needed by the company. - patches for the code sent by email to the above. - We can easily set up git to store kernel modifications in while they are being developed, if the developer(s) need them. (subversion sucks on so many levels, let's just not even go there...) And that's it. No "feature trackers" or bugzilla is needed, as that's not how the Linux kernel development groups work, and we need to intergrate our output into the kernel development process. If we were to set up some separate process, that would just make it harder to intergrate, and cause bigger problems (as some kernel subsystems are now finding out despite them being told to avoid this...) thanks, greg k-h
I'm happy to keep administering the box as far as needed, and to be a developer when I can squeeze that in too! Tomasz
Hi, couldn't this subversion become a git + gitweb ?? -- Best Regards, Felipe Balbi felipebalbi at users.sourceforge.net
Hello, How does one register for the "Policy Forge" website? Thanks, Suman.
You need a "Novell external" account (for lack of a better name). Now either you become the creator of a project, or request (to a project) that your login become enabled for that project. The admin adds your Novell login to the project, you upload your SSH public key, and with a liberal sprinkling of pixie dust, everything works. You can get a Novell account from: https://secure-www.novell.com/selfreg/html/about.jsp
Please don't shoot the messenger. :-) You'd have to take that up with the admin(s) for the site, a link is probably on that main Forge page someplace. I'm just a lowly (ab)user. Best, -PWM
How do we register in the TWiki? As normal users? Or do we need to -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm
I'll be posting a list of outstanding projects that we need help on You don't have to register in the wiki, unless you want to edit the pages to clean things up and change things there. If you don't want to do that, membership on this mailing list is all that is needed. thanks, greg k-h
Ok, then I will. Maybe in the future some help could be needed to All right, thanks. -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm
Hello, I almost forgot about that Project and that I emailed you ;) it will be nice to see it filled with life! regards, Thomas -----Urspr?ngliche Nachricht----- Von: devel-bounces at www.linuxdriverproject.org [mailto:devel-bounces at www.linuxdriverproject.org] Im Auftrag von Greg KH Gesendet: Donnerstag, 27. September 2007 04:32 An: devel at linuxdriverproject.org Betreff: Kick off the Linux Driver Project (again, this time for real) Hi all, You are getting this message because you have expressed interest in the Linux Driver project. I have set up a mailing list for this, which everyone is now subscribed to. If you want off of the list, just follow the directions at the bottom of this message, or email me directly, I'll be glad to take you off. Sorry for the very long delay in getting this project back up off the ground. When I first announced it back in January, I never expected it to be so popular. Unfortunately, it ended up being pushed way back on my priority list as I had to deal with my day job at Novell first, then my Linux kernel development, then with any spare time left over, this project. The good news is that this has now changed. As of today, Novell is sponsoring me to work on this Linux driver project as my first priority. This means I will have the time and resources to commit to managing the different developers and driver projects as part of my daily job. So, to kick things off, everyone go look at the new wiki we have installed at: www.linuxdriverproject.org It's pretty bare-bones, but should be enough to get people started with how to interact with the project. As individual developers, we have a lot of companies that are currently waiting for developers. The new group of project managers will soon be contacting people on this list with requests for help for specific projects. Please help them out and work with them to help create drivers for the different companies involved. If you are a project manager, I'll be poking you all with the ...
ACK :) -- Steven Le Roux steven@le-roux.info xmpp:steven@jabber.fr _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Well then, let's try posting this again... ------------------------------------------ Hi... I'm new to the list, was wondering about those who are interested in or have done work on a Linux driver or any such program to control the Graphtec plotters that go by the name WishBlade, RoboCraft or CraftRobo. http://www.graphteccorp.com/craftrobo/about.html Actually, these are small USB interface home use "paper cutters" that cost hundreds of dollars by Graphtec. A company who's primary product involves vinyl sign cutters that cost thousands of dollars. http://www.graphteccorp.com Their primary use is for cutting out paper figures for scrap booking. However, they can probably be used to cut small vinyl signs. An imaginative use of such a cutter (which might appeal more to this list) might be to cut a printed circuit out of vinyl to be used as an etch resistant pattern. It occurs to me that these small cutters may use the same protocol as their larger cousins. And, that there may already exist Linux based software to control the larger vinyl sign cutters. Does anyone know more about this? The two features that these small cutters have over normal X-Y pen plotters are (1) the larger mechanical force (which apparently can be varied by printer command) exerted by the cutting solenoid and (2) optical scanning of the media to be cut such that the cutting pattern can be autonomously registered with an image previously printed on the media. Several versions of these cutters exist. I am interested in what I think is the first generation (blue WishBlade) cutter. Apparently this generation is no longer supported as the software to control it is not upgradable to Vista. In contrast the next generation (pink WishBlade) software has a patch which makes it compatible with Vista. Also, apparently, the controlling software for these two generations of cutters are not cross compatible. I am making this point in case the Linux drivers have to be ...
Quite good, we have companies participating, drivers being written and accepted upstream. what specifically do you want to know? thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
No enough drivers for all volunteer developers ;-) -- Javi Roman _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
So you have time to act as a tutor ? :)) Davide Madrisan _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Yes, that is the biggest problem we have right now :( I'll write up a summary of how the past year has gone, and how things are progressing in more detail later. Trying to fix bugs in 2.6.25-rc at the moment... thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Date: Wed, 27 Aug 2008 01:18:32 +0200 (CEST)
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
A compiler barrier (explicit on the read side, implicit on the write
side) is not quite enough for what has to be accomplished here. Use
hardware memory barriers on systems which need them.
(Of course a full fix of generation handling would require much more
than this. The ieee1394 core's bus generation counter had to be tied to
the controller's bus generation counter; cf. Kristian's stack. It's
just that I have other current business with the code around these
barrier()s, so why not do at least this small fix.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/nodemgr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux/drivers/ieee1394/nodemgr.c
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.c
+++ linux/drivers/ieee1394/nodemgr.c
@@ -1308,7 +1308,8 @@ static void nodemgr_update_node(struct n
if (ne->in_limbo)
nodemgr_resume_ne(ne);
- /* Mark the node current */
+ /* Finally, mark the node current */
+ smp_wmb();
ne->generation = generation;
}
@@ -1869,7 +1870,7 @@ void hpsb_node_fill_packet(struct node_e
{
packet->host = ne->host;
packet->generation = ne->generation;
- barrier();
+ smp_rmb();
packet->node_id = ne->nodeid;
}
@@ -1878,7 +1879,7 @@ int hpsb_node_write(struct node_entry *n
{
unsigned int generation = ne->generation;
- barrier();
+ smp_rmb();
return hpsb_write(ne->host, ne->nodeid, generation,
addr, buffer, length);
}
--
Stefan Richter
-=====-==--- =--= ===-=
http://arcgraph.de/sr/
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Date: Wed, 27 Aug 2008 13:40:02 +0200
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
These will be used by the firedtv driver. Like hpsb_node_write() they
are much better APIs for high-level drivers than hpsb_write() and its
siblings --- easier to use correctly and also terser.
Unlike hspb_node_write(), the two new functions will only be used by
one call site. Hence make them static inline instead of exported
symbols.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/nodemgr.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
Index: linux/drivers/ieee1394/nodemgr.h
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.h
+++ linux/drivers/ieee1394/nodemgr.h
@@ -21,9 +21,11 @@
#define _IEEE1394_NODEMGR_H
#include <linux/device.h>
+#include <asm/system.h>
#include <asm/types.h>
#include "ieee1394_core.h"
+#include "ieee1394_transactions.h"
#include "ieee1394_types.h"
struct csr1212_csr;
@@ -157,6 +159,22 @@ static inline int hpsb_node_entry_valid(
void hpsb_node_fill_packet(struct node_entry *ne, struct hpsb_packet *packet);
int hpsb_node_write(struct node_entry *ne, u64 addr,
quadlet_t *buffer, size_t length);
+static inline int hpsb_node_read(struct node_entry *ne, u64 addr,
+ quadlet_t *buffer, size_t length)
+{
+ unsigned int g = ne->generation;
+
+ smp_rmb();
+ return hpsb_read(ne->host, ne->nodeid, g, addr, buffer, length);
+}
+static inline int hpsb_node_lock(struct node_entry *ne, u64 addr, int extcode,
+ quadlet_t *buffer, quadlet_t arg)
+{
+ unsigned int g = ne->generation;
+
+ smp_rmb();
+ return hpsb_lock(ne->host, ne->nodeid, g, addr, extcode, buffer, arg);
+}
int nodemgr_for_each_host(void *data, int (*cb)(struct hpsb_host *, void *));
int init_ieee1394_nodemgr(void);
--
Stefan Richter
-=====-==--- =--= ===-=
http://arcgraph.de/sr/
_______________________________________________
devel mailing ...Date: Wed, 27 Aug 2008 01:24:25 +0200 (CEST)
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
While Module_Vendor_ID in the configuration ROM's root directory is
mandatory, there often aren't vendor IDs in unit directories. This
affects the new firedtv driver which is meant to be auto-loaded and
matched only for vendor-specific devices.
We now always copy ne->vendor_id into ud->vendor_id before we scan a
unit directory (and fill in a possibly present vendor ID from there).
This way, the root directory's vendor ID is used as fallback in the
"uevent" environment for modprobe'ing per module alias when a node was
plugged in, and in the driver match routine when protocol drivers are
bound to unit directories. It will however not be used as sysfs
attribute of a unit directory device.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/nodemgr.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux/drivers/ieee1394/nodemgr.c
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.c
+++ linux/drivers/ieee1394/nodemgr.c
@@ -1010,6 +1010,9 @@ static struct unit_directory *nodemgr_pr
ud->ud_kv = ud_kv;
ud->id = (*id)++;
+ /* inherit vendor_id from root directory if none exists in unit dir */
+ ud->vendor_id = ne->vendor_id;
+
csr1212_for_each_dir_entry(ne->csr, kv, ud_kv, dentry) {
switch (kv->key.id) {
case CSR1212_KV_ID_VENDOR:
--
Stefan Richter
-=====-==--- =--= ===-=
http://arcgraph.de/sr/
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
because they are simpler and treat the node generation more correctly.
While we are at it, clean up and simplify surrounding code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/avc_api.c | 133 +++++++----------------
drivers/media/dvb/firesat/cmp.c | 7 -
drivers/media/dvb/firesat/firesat.h | 10 -
drivers/media/dvb/firesat/firesat_1394.c | 24 +---
drivers/media/dvb/firesat/firesat_iso.c | 3
5 files changed, 58 insertions(+), 119 deletions(-)
Index: linux/drivers/media/dvb/firesat/avc_api.c
===================================================================
--- linux.orig/drivers/media/dvb/firesat/avc_api.c
+++ linux/drivers/media/dvb/firesat/avc_api.c
@@ -13,12 +13,13 @@
#include <linux/crc32.h>
#include <linux/delay.h>
+#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
#include <linux/mutex.h>
+#include <linux/string.h>
#include <linux/wait.h>
#include <linux/workqueue.h>
-#include <asm/atomic.h>
#include <ieee1394_transactions.h>
#include <nodemgr.h>
@@ -35,13 +36,6 @@ static unsigned int avc_comm_debug = 0;
module_param(avc_comm_debug, int, 0644);
MODULE_PARM_DESC(avc_comm_debug, "debug logging level [0..2] of AV/C communication, default is 0 (no)");
-/* Frees an allocated packet */
-static void avc_free_packet(struct hpsb_packet *packet)
-{
- hpsb_free_tlabel(packet);
- hpsb_free_packet(packet);
-}
-
static const char* get_ctype_string(__u8 ctype)
{
switch(ctype)
@@ -166,75 +160,46 @@ static void log_response_frame(const AVC
}
static int __AVCWrite(struct firesat *firesat, const AVCCmdFrm *CmdFrm,
- AVCRspFrm *RspFrm) {
- struct hpsb_packet *packet;
- struct node_entry *ne;
- int num_tries = 0;
- int packet_ok = 0;
-
- ne = firesat->nodeentry;
- if(!ne) {
- printk(KERN_ERR "%s: lost node!\n",__func__);
- return -EIO;
- }
-
- /* need all input data */
- if(!firesat || !ne || !CmdFrm) ...Now that nodemgr was enhanced to match against the root directory's
vendor ID if there isn't one in the unit directory, use this to
prevent firedtv to be bound to wrong devices by accident.
Also add the AV/C software version ID to the match flags for
completeness; specifier ID and software only make sense as a pair.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/firesat_1394.c | 52 ++++++++++++++---------
1 file changed, 33 insertions(+), 19 deletions(-)
Index: linux/drivers/media/dvb/firesat/firesat_1394.c
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat_1394.c
+++ linux/drivers/media/dvb/firesat/firesat_1394.c
@@ -39,40 +39,54 @@
#include "firesat-ci.h"
#include "firesat-rc.h"
-#define FIRESAT_Vendor_ID 0x001287
+#define MATCH_FLAGS IEEE1394_MATCH_VENDOR_ID | IEEE1394_MATCH_MODEL_ID | \
+ IEEE1394_MATCH_SPECIFIER_ID | IEEE1394_MATCH_VERSION
+#define DIGITAL_EVERYWHERE_OUI 0x001287
static struct ieee1394_device_id firesat_id_table[] = {
{
/* FloppyDTV S/CI and FloppyDTV S2 */
- .match_flags = IEEE1394_MATCH_MODEL_ID | IEEE1394_MATCH_SPECIFIER_ID,
- .model_id = 0x000024,
- .specifier_id = AVC_UNIT_SPEC_ID_ENTRY & 0xffffff,
+ .match_flags = MATCH_FLAGS,
+ .vendor_id = DIGITAL_EVERYWHERE_OUI,
+ .model_id = 0x000024,
+ .specifier_id = AVC_UNIT_SPEC_ID_ENTRY,
+ .version = AVC_SW_VERSION_ENTRY,
},{
/* FloppyDTV T/CI */
- .match_flags = IEEE1394_MATCH_MODEL_ID | IEEE1394_MATCH_SPECIFIER_ID,
- .model_id = 0x000025,
- .specifier_id = AVC_UNIT_SPEC_ID_ENTRY & 0xffffff,
+ .match_flags = MATCH_FLAGS,
+ .vendor_id = DIGITAL_EVERYWHERE_OUI,
+ .model_id = 0x000025,
+ .specifier_id = AVC_UNIT_SPEC_ID_ENTRY,
+ .version = AVC_SW_VERSION_ENTRY,
},{
/* FloppyDTV C/CI */
- .match_flags = IEEE1394_MATCH_MODEL_ID | IEEE1394_MATCH_SPECIFIER_ID,
- .model_id = 0x000026,
- .specifier_id = AVC_UNIT_SPEC_ID_ENTRY & ...No FireDTVs with more than one subunit exists, hence simplify the
initialization for the special case of one subunit. The driver was able
to check for more than one subunit but was broken for more than two
subunits.
While we are at it, add several missing cleanups after failure, and
include a few dynamically allocated structures diretly into struct
firesat instead of allocating them separately.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/avc_api.c | 36 ---
drivers/media/dvb/firesat/avc_api.h | 1
drivers/media/dvb/firesat/firesat-ci.c | 15 -
drivers/media/dvb/firesat/firesat-ci.h | 2
drivers/media/dvb/firesat/firesat.h | 18 -
drivers/media/dvb/firesat/firesat_1394.c | 214 ++++++++---------------
drivers/media/dvb/firesat/firesat_dvb.c | 166 +++++++----------
drivers/media/dvb/firesat/firesat_fe.c | 22 --
8 files changed, 171 insertions(+), 303 deletions(-)
Index: linux/drivers/media/dvb/firesat/firesat.h
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat.h
+++ linux/drivers/media/dvb/firesat/firesat.h
@@ -25,6 +25,7 @@
#include <demux.h>
#include <dmxdev.h>
#include <dvb_demux.h>
+#include <dvb_frontend.h>
#include <dvb_net.h>
#include <dvbdev.h>
@@ -134,13 +135,13 @@ struct firesat {
struct dvb_demux dvb_demux;
/* DVB bits */
- struct dvb_adapter *adapter;
+ struct dvb_adapter adapter;
struct dmxdev dmxdev;
struct dvb_demux demux;
struct dmx_frontend frontend;
struct dvb_net dvbnet;
struct dvb_frontend_info *frontend_info;
- struct dvb_frontend *fe;
+ struct dvb_frontend fe;
struct dvb_device *cadev;
int ca_last_command;
@@ -162,10 +163,6 @@ struct firesat {
} channel[16];
struct mutex demux_mutex;
- /* needed by avc_api */
- void *respfrm;
- int resp_length;
-
struct unit_directory *ud;
enum model_type type;
@@ -177,6 +174,10 @@ ...There was a NULL pointer reference if no dvb_frontend_info was found.
Also, don't directly assign struct typed values to struct typed
variables. Instead write out assignments to individual strcut members.
This reduces module size by about 1 kB.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/firesat.h | 34 ++--
drivers/media/dvb/firesat/firesat_dvb.c | 3
drivers/media/dvb/firesat/firesat_fe.c | 167 ++++++++++--------------
3 files changed, 91 insertions(+), 113 deletions(-)
Index: linux/drivers/media/dvb/firesat/firesat.h
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat.h
+++ linux/drivers/media/dvb/firesat/firesat.h
@@ -132,25 +132,21 @@ struct hpsb_iso;
struct unit_directory;
struct firesat {
- struct dvb_demux dvb_demux;
-
- /* DVB bits */
- struct dvb_adapter adapter;
- struct dmxdev dmxdev;
- struct dvb_demux demux;
- struct dmx_frontend frontend;
- struct dvb_net dvbnet;
- struct dvb_frontend_info *frontend_info;
- struct dvb_frontend fe;
-
- struct dvb_device *cadev;
- int ca_last_command;
- int ca_time_interval;
-
- struct mutex avc_mutex;
- wait_queue_head_t avc_wait;
- bool avc_reply_received;
- struct work_struct remote_ctrl_work;
+ struct dvb_adapter adapter;
+ struct dmxdev dmxdev;
+ struct dvb_demux demux;
+ struct dmx_frontend frontend;
+ struct dvb_net dvbnet;
+ struct dvb_frontend fe;
+
+ struct dvb_device *cadev;
+ int ca_last_command;
+ int ca_time_interval;
+
+ struct mutex avc_mutex;
+ wait_queue_head_t avc_wait;
+ bool avc_reply_received;
+ struct work_struct remote_ctrl_work;
struct firesat_channel {
struct firesat *firesat;
Index: linux/drivers/media/dvb/firesat/firesat_fe.c
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat_fe.c
+++ linux/drivers/media/dvb/firesat/firesat_fe.c
@@ -12,6 +12,7 ...and redefine an int as a bool.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/firesat.h | 7 +------
drivers/media/dvb/firesat/firesat_dvb.c | 20 ++++++++------------
2 files changed, 9 insertions(+), 18 deletions(-)
Index: linux/drivers/media/dvb/firesat/firesat.h
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat.h
+++ linux/drivers/media/dvb/firesat/firesat.h
@@ -149,13 +149,8 @@ struct firesat {
struct work_struct remote_ctrl_work;
struct firesat_channel {
- struct firesat *firesat;
- struct dvb_demux_feed *dvbdmxfeed;
-
- int active;
- int id;
+ bool active;
int pid;
- int type; /* 1 - TS, 2 - Filter */
} channel[16];
struct mutex demux_mutex;
Index: linux/drivers/media/dvb/firesat/firesat_dvb.c
===================================================================
--- linux.orig/drivers/media/dvb/firesat/firesat_dvb.c
+++ linux/drivers/media/dvb/firesat/firesat_dvb.c
@@ -34,8 +34,8 @@ static struct firesat_channel *firesat_c
return NULL;
for (k = 0; k < 16; k++)
- if (firesat->channel[k].active == 0) {
- firesat->channel[k].active = 1;
+ if (!firesat->channel[k].active) {
+ firesat->channel[k].active = true;
c = &firesat->channel[k];
break;
}
@@ -52,7 +52,7 @@ static int firesat_channel_collect(struc
return -EINTR;
for (k = 0; k < 16; k++)
- if (firesat->channel[k].active == 1)
+ if (firesat->channel[k].active)
pid[l++] = firesat->channel[k].pid;
mutex_unlock(&firesat->demux_mutex);
@@ -68,7 +68,7 @@ static int firesat_channel_release(struc
if (mutex_lock_interruptible(&firesat->demux_mutex))
return -EINTR;
- channel->active = 0;
+ channel->active = false;
mutex_unlock(&firesat->demux_mutex);
return 0;
@@ -102,7 +102,7 @@ int firesat_start_feed(struct dvb_demux_
case DMX_TS_PES_OTHER:
//Dirty fix to keep firesat->channel pid-list up to date
...Sparse found a bug: while ((kv_buf + kv_len - 1) == '\0') should have been while (kv_buf[kv_len - 1] == '\0') We fix it by a better implementation without a temporary copy. Also fix sparse warnings of 0 instead of NULL and signedness mismatches. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/media/dvb/firesat/avc_api.c | 14 +++++++------- drivers/media/dvb/firesat/avc_api.h | 6 +++--- drivers/media/dvb/firesat/firesat_1394.c | 23 +++++++---------------- drivers/media/dvb/firesat/firesat_dvb.c | 2 +- 4 files changed, 18 insertions(+), 27 deletions(-) Index: linux/drivers/media/dvb/firesat/firesat_1394.c =================================================================== --- linux.orig/drivers/media/dvb/firesat/firesat_1394.c +++ linux/drivers/media/dvb/firesat/firesat_1394.c @@ -146,8 +146,8 @@ static int firesat_probe(struct device * struct firesat *firesat; unsigned long flags; int kv_len; + void *kv_str; int i; - char *kv_buf; int err = -ENOMEM; firesat = kzalloc(sizeof(*firesat), GFP_KERNEL); @@ -169,20 +169,12 @@ static int firesat_probe(struct device * /* Reading device model from ROM */ kv_len = (ud->model_name_kv->value.leaf.len - 2) * sizeof(quadlet_t); - kv_buf = kmalloc((sizeof(quadlet_t) * kv_len), GFP_KERNEL); - if (!kv_buf) - goto fail_free; - memcpy(kv_buf, CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA(ud->model_name_kv), - kv_len); - while ((kv_buf + kv_len - 1) == '\0') - kv_len--; - kv_buf[kv_len++] = '\0'; - + kv_str = CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA(ud->model_name_kv); for (i = ARRAY_SIZE(firedtv_model_names); --i;) - if (strcmp(kv_buf, firedtv_model_names[i]) == 0) + if (strlen(firedtv_model_names[i]) <= kv_len && + strncmp(kv_str, firedtv_model_names[i], kv_len) == 0) break; firesat->type = i; - kfree(kv_buf); INIT_LIST_HEAD(&firesat->list); spin_lock_irqsave(&firesat_list_lock, flags); @@ -191,20 +183,19 @@ static int ...
Instead of one virtual input device which exists for the whole lifetime
of the driver and receives events from all connected FireDTVs, register
one input device for each firedtv device. These input devices will show
up as children of the respective firedtv devices in the sysfs hierarchy.
However, the implementation falls short because of a bug in userspace:
Udev's path_id script gets stuck with 100% CPU utilization, maybe
because of an assumption about the maximum ieee1394 device hierarchy
depth.
To avoid this bug, we use the fw-host device instead of the proper
unit_directory device as parent of the input device.
There is hope that the port to the new firewire stack won't be inhibited
by this userspace bug because there are no fw-host devices there.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/media/dvb/firesat/avc_api.c | 4 +-
drivers/media/dvb/firesat/firesat-rc.c | 42 +++++++++++++++--------
drivers/media/dvb/firesat/firesat-rc.h | 9 +++-
drivers/media/dvb/firesat/firesat.h | 5 +-
drivers/media/dvb/firesat/firesat_1394.c | 26 ++++++--------
5 files changed, 52 insertions(+), 34 deletions(-)
Index: linux/drivers/media/dvb/firesat/avc_api.c
===================================================================
--- linux.orig/drivers/media/dvb/firesat/avc_api.c
+++ linux/drivers/media/dvb/firesat/avc_api.c
@@ -225,8 +225,8 @@ int AVCRecv(struct firesat *firesat, u8
RspFrm->operand[2] == SFE_VENDOR_DE_COMPANYID_2 &&
RspFrm->operand[3] == SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL) {
if (RspFrm->resp == CHANGED) {
- firesat_handle_rc(RspFrm->operand[4] << 8 |
- RspFrm->operand[5]);
+ firesat_handle_rc(firesat,
+ RspFrm->operand[4] << 8 | RspFrm->operand[5]);
schedule_work(&firesat->remote_ctrl_work);
} else if (RspFrm->resp != INTERIM) {
dev_info(&firesat->ud->device,
Index: ...Done. -- Stefan Richter -=====-==--- =--= ===-= http://arcgraph.de/sr/ _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Code which will be compiled into object code does not go into headers but into .c files (function definitions, string constants etc.). OTOH, function prototypes, preprocessor macro definitions, definitions of small static inline functions etc. can go into headers. If your driver does not export functions or variables to be called/ accessed by other drivers, you actually don't need a header. In that case, use a header file only if you have a lot of macros to define (e.g. for named register offsets and register contents). Such headers which are not meant to be included by any other file than a single xyz.c are sometimes called something like "xyz-private.h". If you export something to other drivers in the same subdirectory, put the header file into the subdirectory. If you export something for other drivers anywhere across the linux source tree, put the header into linux/include. (Exception: Some subsystems don't do this; their users have to add respective search paths into their Makefiles.) If you export an API to userspace, put the header into linux/include and I personally never used any debugger, just printk and the various nice options in the kernel hacking configuration menu. Maybe I have been missing out on something which only debuggers provide, but lucky me, I'm Usually, drivers are matched against some numeric IDs. Many if not most drivers contain module aliases in their .ko so that they are auto-loaded if the respective hardware is found. However, maybe a driver was written but not yet submitted to the mainline. Open-source out-of-tree drivers are listed at http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers . You could also ask on the relevant subsystem mailinglist if anybody I'm not familiar with networking. Generally, old drivers --- even if still actively maintained --- may contain code which does not reflect currently preferred coding practices. Hence you should rather look at newer drivers. But not at those in ...
On Sat, 11 Apr 2009 03:00:13 -0700 Thanks for the great explanation! This really made things a lot Is there a list of sub-system maintainers? Or do I search for them in Thanks for the tip. For the drivers you are familiar with, anything Amit _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Better ask on mailinglists rather than individual people. Subsystem development mailinglists are listed in linux/MAINTAINERS of course. The I basically only work with drivers/ieee1394 and drivers/firewire; out of them the latter are new and nicely written, though I don't know if they are clear enough to beginners, or solid platinum even... -- Stefan Richter -=====-=-=== -=-= -==-= http://arcgraph.de/sr/ _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
It all depends on what type of data the device sends back. If it is a HID device, it might be trivial. If it's a custom protocol, it's much harder. good luck, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On the product packaging, it says "Hanvon Drawing Tablet"; however dmesg reports: HanWang co. HW Micro Drawing Tablet with a vendor ID of 0B57, and a product ID of 8019. Full output from 2.6.28-11-generic at device connect: [ 1673.776066] usb 2-2: new low speed USB device using uhci_hcd and address 5 [ 1673.961620] usb 2-2: configuration #1 chosen from 1 choice [ 1673.982901] generic-usb 0003:0B57:8019.0005: hiddev96,hidraw1: USB HID v1.00 Device [HanWang co. HW Micro Drawing Tablet] on I'm pretty sure that the device uses HID. On Windows, connecting the tablet causes two USB devices to show up, one of which is labelled "HID compatible device". The communication consists of some initialization messages (that seem to be state-independent), followed by a return of 8 bytes of data for each polling request. Snoopy reports that the functions that show up in the initialization messages are: GET_DESCRIPTOR_FROM_DEVICE, CONTROL_TRANSFER, SELECT_CONFIGURATION, CLASS_INTERFACE, and GET_DESCRIPTOR_FROM_INTERFACE while the main polling data is simply a BULK_OR_INTERRUPT_TRANSFER. I can't say I understand the contents of the init messages, but I do understand the 8 bytes that come back after each poll. Thanks for the quick reply! Steve _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Hmm, It looks like it is a standard HID device and got registered in the input layer. Could you attach lsusb -v of that device and /proc/bus/input/devices? _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Here's lsusb -v :
---------------------------------------------------------------------------------------------------------
$ lsusb -v
Bus 002 Device 002: ID 0b57:8019 Beijing HanwangTechnology Co., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0b57 Beijing HanwangTechnology Co., Ltd
idProduct 0x8019
bcdDevice 1.11
iManufacturer 1 HanWang co.
iProduct 2 HW Micro Drawing Tablet
iSerial 3 V1.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 41
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
...Actually I missed there is no "input" at 1673.982901, so the input is not claimed. You still can read the events through hidraw (or via deprecated hiddev). Jiri, any ideas? Looks like there are no useful applications. A report dump will tell us whether we can handle it through standard path (with forced connect) or it has to be handled by hidraw, am I correct? _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Exactly. The device probably doesn't provide any applications that would pass through IS_INPUT_APPLICATION() macro (see include/linux/hid.h). We might well be extending this definition, as it is quite outdated (and doesn't for example deal with new digitizers very well). Report descriptor dump would absolutely be necessary (i.e. compiling the kernel with CONFIG_HID_DEBUG and modprobing the 'hid' module with 'debug=2' parameter). -- Jiri Kosina SUSE Labs _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Why hiddev is deprecated ? ikbel _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
