Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
> On Tue, 22 Jan 2008 08:12:08 -0800 (PST) Alex Dubov <[EMAIL PROTECTED]> wrote: > > --- Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote: > > > > > From: Alex Dubov <[EMAIL PROTECTED]> > > > > > > Sony MemoryStick cards are used in many products manufactured by Sony. > > > They > > > are available both as storage and as IO expansion cards. Currently, only > > > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > > > interface. > > > > > > > Will you be running a git tree for this? If so, please send me the link. > > > > I rectified several additional issues with the driver. I hope you can pull > the changes from here: > > http://58.96.64.63/~oakad/git/.git memstick > Would prefer an emailed, changelogged diff against the previous version, please. -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote: > > > From: Alex Dubov <[EMAIL PROTECTED]> > > > > Sony MemoryStick cards are used in many products manufactured by Sony. They > > are available both as storage and as IO expansion cards. Currently, only > > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > > interface. > > > > Will you be running a git tree for this? If so, please send me the link. > I rectified several additional issues with the driver. I hope you can pull the changes from here: http://58.96.64.63/~oakad/git/.git memstick Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Will you be running a git tree for this? If so, please send me the link. I rectified several additional issues with the driver. I hope you can pull the changes from here: http://58.96.64.63/~oakad/git/.git memstick Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Tue, 22 Jan 2008 08:12:08 -0800 (PST) Alex Dubov [EMAIL PROTECTED] wrote: --- Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Will you be running a git tree for this? If so, please send me the link. I rectified several additional issues with the driver. I hope you can pull the changes from here: http://58.96.64.63/~oakad/git/.git memstick Would prefer an emailed, changelogged diff against the previous version, please. -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > Hello, > > > Sony MemoryStick cards are used in many products manufactured by Sony. They > > are available both as storage and as IO expansion cards. Currently, only > > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > > interface. > > I tried it here and it doesn't work. My Vaio (PCG-FR285M) is from ~2003 (Is > it too old > for this?). I have some memory stick cards around so If you want a tester > just drop me > an email. > > Regards, > > Mariusz > The build year is nowhere as helpful as 'lspci -vv' output. Then, given that your vaio is equipped with tifm controller, you'll have to build the driver with debugging enabled and send me the relevant excerpt of your system log. You should have the following modules loaded, by the way: memstick mspro_block tifm_core tifm_7xx1 tifm_ms The autoloading is handled via udev (so the relevant rules are not there yet). Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
Hello, > Sony MemoryStick cards are used in many products manufactured by Sony. They > are available both as storage and as IO expansion cards. Currently, only > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > interface. I tried it here and it doesn't work. My Vaio (PCG-FR285M) is from ~2003 (Is it too old for this?). I have some memory stick cards around so If you want a tester just drop me an email. Regards, Mariusz -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
Hello, Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. I tried it here and it doesn't work. My Vaio (PCG-FR285M) is from ~2003 (Is it too old for this?). I have some memory stick cards around so If you want a tester just drop me an email. Regards, Mariusz -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Mariusz Kozlowski [EMAIL PROTECTED] wrote: Hello, Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. I tried it here and it doesn't work. My Vaio (PCG-FR285M) is from ~2003 (Is it too old for this?). I have some memory stick cards around so If you want a tester just drop me an email. Regards, Mariusz The build year is nowhere as helpful as 'lspci -vv' output. Then, given that your vaio is equipped with tifm controller, you'll have to build the driver with debugging enabled and send me the relevant excerpt of your system log. You should have the following modules loaded, by the way: memstick mspro_block tifm_core tifm_7xx1 tifm_ms The autoloading is handled via udev (so the relevant rules are not there yet). Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available both as storage and as IO expansion cards. Currently, only
> > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
> > interface.
> >
>
> Will you be running a git tree for this? If so, please send me the link.
>
> Will this enable that thus-far useless slot on my Vaio?
>
> Where did the info come from which enabled this driver to be written? I
> thought Sony were super-secretive about this stuff?
>
I'm going to set-up git tree, yes.
It should support some vaios (newer ones for sure), as far as I know.
The primary reference for the driver is this one:
http://zeniv.linux.org.uk/~winbond/ (link is somewhat slow, but works). Winbond
developed GPLv2
driver for linux and there was enough info in their source code for my
implementation (totally
different from their's). Some reverse engineering of the windows driver was
needed too (for the TI
registers and such).
>
> > @@ -0,0 +1,26 @@
> > +#
> > +# MemoryStick subsystem configuration
> > +#
> > +
> > +menuconfig MEMSTICK
> > + tristate "Sony MemoryStick card support (EXPERIMENTAL)"
> > + help
> > + Sony MemoryStick is a proprietary storage/extension card protocol.
> > +
> > + If you want MemoryStick support, you should say Y here and also
> > + to the specific driver for your MMC interface.
>
> Are you sure this has enough dependencies? CONFIG_TIFM_* for a start?
This is supposed to be a generic layer, akin to mmc. I have a jmicron backend
in the works, and
windbond backend will be possible, too.
>
>
>
> We can create a config which has CONFIG_TIFM_CORE=m, CONFIG_MEMSTICK=y.
> That might not work?
>
> Anyway, please have a think about that.
Considering the previous point this should be ok.
>
> > ...
> >
> > +
> > +struct mspro_sys_attr {
> > + size_t size;
> > + unsigned char *data;
> > + unsigned char id;
> > + charname[32];
> > + struct device_attribute sys_attr;
> > +};
> > +
> > +struct mspro_attr_entry {
> > + unsigned int address;
> > + unsigned int size;
> > + unsigned char id;
> > + unsigned char reserved[3];
> > +} __attribute__((packed));
> > +
> > +struct mspro_attribute {
> > + unsigned short signature;
> > + unsigned short version;
> > + unsigned char count;
> > + unsigned char reserved[11];
> > + struct mspro_attr_entry entries[];
> > +} __attribute__((packed));
>
> Why are these packed? Do they map onto something whcih hardware knows
> about?
Yes, of course; all structures with "packed" attribute correspond to
appropriate protocol ones
(the endianness is tweaked as needed - most, but not all fields, are
big-endian).
> >
> > ...
> >
> > +struct mspro_block_data {
> > + struct memstick_dev *card;
> > + unsigned int usage_count;
> > + struct gendisk*disk;
> > + struct request_queue *queue;
> > + spinlock_tq_lock;
> > + wait_queue_head_t q_wait;
> > + struct task_struct*q_thread;
> > +
> > + unsigned shortpage_size;
> > + unsigned shortcylinders;
> > + unsigned shortheads;
> > + unsigned shortsectors_per_track;
> > +
> > + unsigned char system;
> > + unsigned char read_only:1,
> > + active:1,
> > + has_request:1,
> > + data_dir:1;
>
> You're aware that these four fields occupy the same machine word and that
> the compiler provides no locking? So if one thread attempts to modify
> "read_only" while another modifies "has_request", one can corrupt the work
> of the other?
>
> If this is indeed safe then a comment here whcih clearly explains that
> would be useful.
The access to these fields should be exclusively under q_lock (I'll check the
locking again, just
to make sure). After all, the same applies to old fashioned bit masks.
>
> > +}
> > +
> > +static ssize_t mspro_block_attr_show_modelname(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buffer)
> > +{
> > + struct mspro_sys_attr *x_attr = container_of(attr,
> > +struct mspro_sys_attr,
> > +sys_attr);
> > +
> > + return snprintf(buffer, PAGE_SIZE, "%s", x_attr->data);
> > +}
> >
> > ...
> >
> > +static int mspro_block_sysfs_register(struct memstick_dev *card)
> > +{
> > + struct mspro_block_data *msb = memstick_get_drvdata(card);
> > + int cnt, rc = 0;
> > +
> > + for (cnt = 0; cnt < msb->attr_count; cnt++) {
> > + rc = device_create_file(>dev,
>
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
This happens when trying to compile memory stick support inside the kernel.
drivers/memstick/core/mspro_block.o: In function `memstick_priv':
mspro_block.c:(.text+0x0): multiple definition of `memstick_priv'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x0): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_get_drvdata':
mspro_block.c:(.text+0x6): multiple definition of `memstick_get_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x6): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_set_drvdata':
mspro_block.c:(.text+0xd): multiple definition of `memstick_set_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0xd): first defined here
This is because those three functions are not defined as static in
"include/linux/memstick.h".
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/include/linux/memstick.h b/include/linux/memstick.h
index dc5ac9d..53a8741 100644
--- a/include/linux/memstick.h
+++ b/include/linux/memstick.h
@@ -271,17 +271,17 @@ void memstick_new_req(struct memstick_host *host);
int memstick_set_rw_addr(struct memstick_dev *card);
-inline void *memstick_priv(struct memstick_host *host)
+static inline void *memstick_priv(struct memstick_host *host)
{
return (void *)host->private;
}
-inline void *memstick_get_drvdata(struct memstick_dev *card)
+static inline void *memstick_get_drvdata(struct memstick_dev *card)
{
return dev_get_drvdata(>dev);
}
-inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
+static inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
{
dev_set_drvdata(>dev, data);
}
---
Miguel Botón
--
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] [MEMSTICK] Initial commit for Sony MemoryStick support
This happens when trying to compile memory stick support inside the kernel.
drivers/memstick/core/mspro_block.o: In function `memstick_priv':
mspro_block.c:(.text+0x0): multiple definition of `memstick_priv'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x0): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_get_drvdata':
mspro_block.c:(.text+0x6): multiple definition of `memstick_get_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x6): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_set_drvdata':
mspro_block.c:(.text+0xd): multiple definition of `memstick_set_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0xd): first defined here
This is because those three functions are not defined as static in
include/linux/memstick.h.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
diff --git a/include/linux/memstick.h b/include/linux/memstick.h
index dc5ac9d..53a8741 100644
--- a/include/linux/memstick.h
+++ b/include/linux/memstick.h
@@ -271,17 +271,17 @@ void memstick_new_req(struct memstick_host *host);
int memstick_set_rw_addr(struct memstick_dev *card);
-inline void *memstick_priv(struct memstick_host *host)
+static inline void *memstick_priv(struct memstick_host *host)
{
return (void *)host-private;
}
-inline void *memstick_get_drvdata(struct memstick_dev *card)
+static inline void *memstick_get_drvdata(struct memstick_dev *card)
{
return dev_get_drvdata(card-dev);
}
-inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
+static inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
{
dev_set_drvdata(card-dev, data);
}
---
Miguel Botón
--
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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
From: Alex Dubov [EMAIL PROTECTED]
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently, only
MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
interface.
Will you be running a git tree for this? If so, please send me the link.
Will this enable that thus-far useless slot on my Vaio?
Where did the info come from which enabled this driver to be written? I
thought Sony were super-secretive about this stuff?
I'm going to set-up git tree, yes.
It should support some vaios (newer ones for sure), as far as I know.
The primary reference for the driver is this one:
http://zeniv.linux.org.uk/~winbond/ (link is somewhat slow, but works). Winbond
developed GPLv2
driver for linux and there was enough info in their source code for my
implementation (totally
different from their's). Some reverse engineering of the windows driver was
needed too (for the TI
registers and such).
@@ -0,0 +1,26 @@
+#
+# MemoryStick subsystem configuration
+#
+
+menuconfig MEMSTICK
+ tristate Sony MemoryStick card support (EXPERIMENTAL)
+ help
+ Sony MemoryStick is a proprietary storage/extension card protocol.
+
+ If you want MemoryStick support, you should say Y here and also
+ to the specific driver for your MMC interface.
Are you sure this has enough dependencies? CONFIG_TIFM_* for a start?
This is supposed to be a generic layer, akin to mmc. I have a jmicron backend
in the works, and
windbond backend will be possible, too.
fiddles with Kconfig
We can create a config which has CONFIG_TIFM_CORE=m, CONFIG_MEMSTICK=y.
That might not work?
Anyway, please have a think about that.
Considering the previous point this should be ok.
...
+
+struct mspro_sys_attr {
+ size_t size;
+ unsigned char *data;
+ unsigned char id;
+ charname[32];
+ struct device_attribute sys_attr;
+};
+
+struct mspro_attr_entry {
+ unsigned int address;
+ unsigned int size;
+ unsigned char id;
+ unsigned char reserved[3];
+} __attribute__((packed));
+
+struct mspro_attribute {
+ unsigned short signature;
+ unsigned short version;
+ unsigned char count;
+ unsigned char reserved[11];
+ struct mspro_attr_entry entries[];
+} __attribute__((packed));
Why are these packed? Do they map onto something whcih hardware knows
about?
Yes, of course; all structures with packed attribute correspond to
appropriate protocol ones
(the endianness is tweaked as needed - most, but not all fields, are
big-endian).
...
+struct mspro_block_data {
+ struct memstick_dev *card;
+ unsigned int usage_count;
+ struct gendisk*disk;
+ struct request_queue *queue;
+ spinlock_tq_lock;
+ wait_queue_head_t q_wait;
+ struct task_struct*q_thread;
+
+ unsigned shortpage_size;
+ unsigned shortcylinders;
+ unsigned shortheads;
+ unsigned shortsectors_per_track;
+
+ unsigned char system;
+ unsigned char read_only:1,
+ active:1,
+ has_request:1,
+ data_dir:1;
You're aware that these four fields occupy the same machine word and that
the compiler provides no locking? So if one thread attempts to modify
read_only while another modifies has_request, one can corrupt the work
of the other?
If this is indeed safe then a comment here whcih clearly explains that
would be useful.
The access to these fields should be exclusively under q_lock (I'll check the
locking again, just
to make sure). After all, the same applies to old fashioned bit masks.
+}
+
+static ssize_t mspro_block_attr_show_modelname(struct device *dev,
+ struct device_attribute *attr,
+ char *buffer)
+{
+ struct mspro_sys_attr *x_attr = container_of(attr,
+struct mspro_sys_attr,
+sys_attr);
+
+ return snprintf(buffer, PAGE_SIZE, %s, x_attr-data);
+}
...
+static int mspro_block_sysfs_register(struct memstick_dev *card)
+{
+ struct mspro_block_data *msb = memstick_get_drvdata(card);
+ int cnt, rc = 0;
+
+ for (cnt = 0; cnt msb-attr_count; cnt++) {
+ rc = device_create_file(card-dev,
+ msb-attributes[cnt].sys_attr);
+
+ if (rc) {
+ if (cnt) {
+ for (cnt--; cnt = 0; cnt--)
ow. my brain
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Thu, Jan 10 2008, Andrew Morton wrote:
> > +static void mspro_block_request(struct request_queue *q)
> > +{
> > + struct memstick_dev *card = q->queuedata;
> > + struct mspro_block_data *msb = memstick_get_drvdata(card);
> > + struct request *req = NULL;
> > +
> > + if (!msb->q_thread) {
> > + for (req = elv_next_request(q); req;
> > +req = elv_next_request(q)) {
> > + while (end_that_request_chunk(req, -ENODEV,
> > + req->current_nr_sectors
> > + << 9)) {}
> > + end_that_request_last(req, -ENODEV);
> > + }
> > + } else {
> > + msb->has_request = 1;
> > + wake_up_all(>q_wait);
> > + }
> > +}
>
> Suggest that you cc Jens on this, see if he can check it all over.
It's suboptimal and doesn't work for non-fs request. Just use
end_queued_request() instead:
if (msb->q_thread) {
msb->has_request = 1;
wake_up(>q_wait);
} else {
while ((req = elv_next_request(q)) != NULL)
end_queued_request(req, -ENODEV);
}
which is simpler and gets all cases correct. Reordering for normal case
as well.
--
Jens Axboe
--
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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Thu, Jan 10 2008, Andrew Morton wrote:
+static void mspro_block_request(struct request_queue *q)
+{
+ struct memstick_dev *card = q-queuedata;
+ struct mspro_block_data *msb = memstick_get_drvdata(card);
+ struct request *req = NULL;
+
+ if (!msb-q_thread) {
+ for (req = elv_next_request(q); req;
+req = elv_next_request(q)) {
+ while (end_that_request_chunk(req, -ENODEV,
+ req-current_nr_sectors
+ 9)) {}
+ end_that_request_last(req, -ENODEV);
+ }
+ } else {
+ msb-has_request = 1;
+ wake_up_all(msb-q_wait);
+ }
+}
Suggest that you cc Jens on this, see if he can check it all over.
It's suboptimal and doesn't work for non-fs request. Just use
end_queued_request() instead:
if (msb-q_thread) {
msb-has_request = 1;
wake_up(msb-q_wait);
} else {
while ((req = elv_next_request(q)) != NULL)
end_queued_request(req, -ENODEV);
}
which is simpler and gets all cases correct. Reordering for normal case
as well.
--
Jens Axboe
--
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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
> From: Alex Dubov <[EMAIL PROTECTED]>
>
> Sony MemoryStick cards are used in many products manufactured by Sony. They
> are available both as storage and as IO expansion cards. Currently, only
> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
> interface.
>
Will you be running a git tree for this? If so, please send me the link.
Will this enable that thus-far useless slot on my Vaio?
Where did the info come from which enabled this driver to be written? I
thought Sony were super-secretive about this stuff?
> @@ -0,0 +1,26 @@
> +#
> +# MemoryStick subsystem configuration
> +#
> +
> +menuconfig MEMSTICK
> + tristate "Sony MemoryStick card support (EXPERIMENTAL)"
> + help
> + Sony MemoryStick is a proprietary storage/extension card protocol.
> +
> + If you want MemoryStick support, you should say Y here and also
> + to the specific driver for your MMC interface.
Are you sure this has enough dependencies? CONFIG_TIFM_* for a start?
We can create a config which has CONFIG_TIFM_CORE=m, CONFIG_MEMSTICK=y.
That might not work?
Anyway, please have a think about that.
> +static int memstick_uevent(struct device *dev, struct kobj_uevent_env *env)
> +{
> + struct memstick_dev *card = container_of(dev, struct memstick_dev,
> + dev);
> +
> + if (add_uevent_var(env, "MEMSTICK_TYPE=%02X", card->id.type))
> + return -ENOMEM;
> +
> + if (add_uevent_var(env, "MEMSTICK_CATEGORY=%02X", card->id.category))
> + return -ENOMEM;
I trust higher-level code cleans up the MEMSTICK_TYPE string if this call
fails.
> + if (add_uevent_var(env, "MEMSTICK_CLASS=%02X", card->id.class))
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int memstick_device_probe(struct device *dev)
> +{
> + struct memstick_dev *card = container_of(dev, struct memstick_dev,
> + dev);
> + struct memstick_driver *drv = container_of(dev->driver,
> +struct memstick_driver,
> +driver);
> + int rc = -ENODEV;
> +
> + get_device(dev);
> + if (dev->driver && drv->probe) {
> + rc = drv->probe(card);
> + if (!rc)
> + return 0;
> + }
> + put_device(dev);
> + return rc;
> +}
Could just do:
int rc = -ENODEV;
if (dev->driver && drv->probe) {
rc = drv->probe(card);
if (!rc)
get_device(dev);
}
return rc;
If the earlier get_device() is indeed needed then we already have a
problem..
> +
> +static int memstick_device_remove(struct device *dev)
> +{
> + struct memstick_dev *card = container_of(dev, struct memstick_dev,
> + dev);
> + struct memstick_driver *drv = container_of(dev->driver,
> +struct memstick_driver,
> +driver);
> +
> + if (dev->driver && drv->remove) {
> + drv->remove(card);
> + card->dev.driver = NULL;
Is this needed?
> + }
> +
> + put_device(dev);
> + return 0;
> +}
>
> ...
>
> +void memstick_init_req(struct memstick_request *mrq, unsigned char tpc,
> +void *buf, size_t length)
> +{
> + mrq->tpc = tpc;
> + if (tpc & 8)
> + mrq->data_dir = WRITE;
> + else
> + mrq->data_dir = READ;
> +
> + mrq->data_len = length > sizeof(mrq->data) ? sizeof(mrq->data) : length;
> + if (mrq->data_dir == WRITE)
> + memcpy(mrq->data, buf, mrq->data_len);
> +
> + mrq->io_type = MEMSTICK_IO_VAL;
> +
> + if (tpc == MS_TPC_SET_CMD || tpc == MS_TPC_EX_SET_CMD)
> + mrq->need_card_int = 1;
> + else
> + mrq->need_card_int = 0;
> +
> + mrq->get_int_reg = 0;
> +}
> +EXPORT_SYMBOL(memstick_init_req);
It's kinda polite to add some commentary to global, exported-to-modules
functions.
It leads to more effective code review too. Reviewing code is the process
of determining whether implementation != intention. But without comments,
the reviewer's starting point is intention = implementation. So we end up
incorrectly returning true ;)
> +static int h_memstick_read_dev_id(struct memstick_dev *card,
> + struct memstick_request **mrq)
> +{
> + struct ms_id_register id_reg;
> +
> + if (!(*mrq)) {
> + memstick_init_req(>current_mrq, MS_TPC_READ_REG, NULL,
> + sizeof(struct ms_id_register));
> + *mrq = >current_mrq;
> + return 0;
> + } else {
> + if (!(*mrq)->error) {
> + memcpy(_reg, (*mrq)->data, sizeof(id_reg));
> +
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
From: Alex Dubov [EMAIL PROTECTED]
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently, only
MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
interface.
Will you be running a git tree for this? If so, please send me the link.
Will this enable that thus-far useless slot on my Vaio?
Where did the info come from which enabled this driver to be written? I
thought Sony were super-secretive about this stuff?
@@ -0,0 +1,26 @@
+#
+# MemoryStick subsystem configuration
+#
+
+menuconfig MEMSTICK
+ tristate Sony MemoryStick card support (EXPERIMENTAL)
+ help
+ Sony MemoryStick is a proprietary storage/extension card protocol.
+
+ If you want MemoryStick support, you should say Y here and also
+ to the specific driver for your MMC interface.
Are you sure this has enough dependencies? CONFIG_TIFM_* for a start?
fiddles with Kconfig
We can create a config which has CONFIG_TIFM_CORE=m, CONFIG_MEMSTICK=y.
That might not work?
Anyway, please have a think about that.
+static int memstick_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct memstick_dev *card = container_of(dev, struct memstick_dev,
+ dev);
+
+ if (add_uevent_var(env, MEMSTICK_TYPE=%02X, card-id.type))
+ return -ENOMEM;
+
+ if (add_uevent_var(env, MEMSTICK_CATEGORY=%02X, card-id.category))
+ return -ENOMEM;
I trust higher-level code cleans up the MEMSTICK_TYPE string if this call
fails.
+ if (add_uevent_var(env, MEMSTICK_CLASS=%02X, card-id.class))
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int memstick_device_probe(struct device *dev)
+{
+ struct memstick_dev *card = container_of(dev, struct memstick_dev,
+ dev);
+ struct memstick_driver *drv = container_of(dev-driver,
+struct memstick_driver,
+driver);
+ int rc = -ENODEV;
+
+ get_device(dev);
+ if (dev-driver drv-probe) {
+ rc = drv-probe(card);
+ if (!rc)
+ return 0;
+ }
+ put_device(dev);
+ return rc;
+}
Could just do:
int rc = -ENODEV;
if (dev-driver drv-probe) {
rc = drv-probe(card);
if (!rc)
get_device(dev);
}
return rc;
If the earlier get_device() is indeed needed then we already have a
problem..
+
+static int memstick_device_remove(struct device *dev)
+{
+ struct memstick_dev *card = container_of(dev, struct memstick_dev,
+ dev);
+ struct memstick_driver *drv = container_of(dev-driver,
+struct memstick_driver,
+driver);
+
+ if (dev-driver drv-remove) {
+ drv-remove(card);
+ card-dev.driver = NULL;
Is this needed?
+ }
+
+ put_device(dev);
+ return 0;
+}
...
+void memstick_init_req(struct memstick_request *mrq, unsigned char tpc,
+void *buf, size_t length)
+{
+ mrq-tpc = tpc;
+ if (tpc 8)
+ mrq-data_dir = WRITE;
+ else
+ mrq-data_dir = READ;
+
+ mrq-data_len = length sizeof(mrq-data) ? sizeof(mrq-data) : length;
+ if (mrq-data_dir == WRITE)
+ memcpy(mrq-data, buf, mrq-data_len);
+
+ mrq-io_type = MEMSTICK_IO_VAL;
+
+ if (tpc == MS_TPC_SET_CMD || tpc == MS_TPC_EX_SET_CMD)
+ mrq-need_card_int = 1;
+ else
+ mrq-need_card_int = 0;
+
+ mrq-get_int_reg = 0;
+}
+EXPORT_SYMBOL(memstick_init_req);
It's kinda polite to add some commentary to global, exported-to-modules
functions.
It leads to more effective code review too. Reviewing code is the process
of determining whether implementation != intention. But without comments,
the reviewer's starting point is intention = implementation. So we end up
incorrectly returning true ;)
+static int h_memstick_read_dev_id(struct memstick_dev *card,
+ struct memstick_request **mrq)
+{
+ struct ms_id_register id_reg;
+
+ if (!(*mrq)) {
+ memstick_init_req(card-current_mrq, MS_TPC_READ_REG, NULL,
+ sizeof(struct ms_id_register));
+ *mrq = card-current_mrq;
+ return 0;
+ } else {
+ if (!(*mrq)-error) {
+ memcpy(id_reg, (*mrq)-data, sizeof(id_reg));
+ card-id = (struct memstick_device_id){
+ .match_flags = MEMSTICK_MATCH_ALL,
+
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > So do we require changes to the userspace udev rules here, or just some use > of > modalias in the drivers? > It was handled by whoever manages the distro's udev rules until now. Here's the example: https://lists.ubuntu.com/archives/ubuntu-patches/2007-September/012537.html Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 01:01:08 Alex Dubov wrote: > This is exactly the same as with tifm_sd module if you noticed. Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD cards. > Second, it is impossible to guess in advance, which type of card is put > into slot (Pro, legacy or IO of either sort). I imagined this to be the case. > Same as mmc_block, actually. > The only way to get it autoloaded, is, again, with appropriate udev rule > (uevent is emitted when card type is detected). So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Dec 31 2007 00:01, Carlos Corbacho wrote: > >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > >> From: Alex Dubov <[EMAIL PROTECTED]> > >> > >> Sony MemoryStick cards are used in many products manufactured by Sony. They > >> are available both as storage and as IO expansion cards. Currently, only > >> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > >> interface. > > Actually... my MS slot on PCG-U3 is recognized through usb_storage. > USB storage type controllers have firmware that translates native MS protocol into USB storage (scsi-like) one. We are talking here about native protocol support, needed for dumb controllers. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
> However, my only concerns are that: > > 1) tifm_ms was not autoloaded > 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. > > Although, whether this is an issue with userspace (ie. udev) not dealing with > the modules properly, I don't know. > This is exactly the same as with tifm_sd module if you noticed. First, there are no modaliases for tifm (I was thinking to add them later, when at least two card types are supported, if at all), so the appropriate udev rule should be added (similar to the sd one). Second, it is impossible to guess in advance, which type of card is put into slot (Pro, legacy or IO of either sort). Same as mmc_block, actually. The only way to get it autoloaded, is, again, with appropriate udev rule (uevent is emitted when card type is detected). Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote: > On Dec 31 2007 00:01, Carlos Corbacho wrote: > >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > >> From: Alex Dubov <[EMAIL PROTECTED]> > >> > >> Sony MemoryStick cards are used in many products manufactured by Sony. > >> They are available both as storage and as IO expansion cards. Currently, > >> only MemoryStick Pro storage cards are supported via TI FlashMedia > >> MemoryStick interface. > > Actually... my MS slot on PCG-U3 is recognized through usb_storage. Then consider yourself very lucky - some laptop manufacturers play nice and the card reader identifies itself, and works as, a USB mass storage device; so it works out of the box with no extra drivers needed for either the card reader, or the flash memory card. The Texas Instruments chip/ card reader that Alex's work here is currently aimed at does not - it has a completely proprietary, so called "FlashMedia" chip/ interface that talks to MMC/ SD, MemoryStick (/ Pro), and SmartMedia/ xD cards, of which TI have refused to release any specs. Yes, this chip doesn't even use sdhci for communicating with MMC/ SD cards - tifm_sd (Alex's previous work on the MMC/ SD front for this TI chip) handles that. MemoryStick support is more complicated in this case than MMC/ SD, given that on top of TI refusing to release specs for their own FlashMedia chips, Sony will also not release any specs on MemoryStick cards; the same is also true of xD with Olympus and Fuji. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Dec 31 2007 00:01, Carlos Corbacho wrote: >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: >> From: Alex Dubov <[EMAIL PROTECTED]> >> >> Sony MemoryStick cards are used in many products manufactured by Sony. They >> are available both as storage and as IO expansion cards. Currently, only >> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick >> interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
Mostly just stylistic comments from me here. On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > From: Alex Dubov <[EMAIL PROTECTED]> > > Sony MemoryStick cards are used in many products manufactured by Sony. They > are available both as storage and as IO expansion cards. Currently, only > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > interface. > > Signed-off-by: Alex Dubov <[EMAIL PROTECTED]> For MemoryStick Pro on my TI7421 card reader (since my old MemoryStick card and camera have disappeared somewhere, so I cannot currently test that): Tested-by: Carlos Corbacho <[EMAIL PROTECTED]> However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. > --- /dev/null > +++ b/drivers/memstick/core/memstick.c > @@ -0,0 +1,557 @@ > +/* > + * memstick.c - Sony MemoryStick support File names in comments are now frowned upon - there was a thread on this in October on LKML: http://lkml.org/lkml/2007/10/12/524 Also, before Andrew gets in with this - you should run this through checkpatch, as there are a few errors it throws up (mostly foo* and C99 comments). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
Mostly just stylistic comments from me here. On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Signed-off-by: Alex Dubov [EMAIL PROTECTED] For MemoryStick Pro on my TI7421 card reader (since my old MemoryStick card and camera have disappeared somewhere, so I cannot currently test that): Tested-by: Carlos Corbacho [EMAIL PROTECTED] However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. --- /dev/null +++ b/drivers/memstick/core/memstick.c @@ -0,0 +1,557 @@ +/* + * memstick.c - Sony MemoryStick support File names in comments are now frowned upon - there was a thread on this in October on LKML: http://lkml.org/lkml/2007/10/12/524 Also, before Andrew gets in with this - you should run this through checkpatch, as there are a few errors it throws up (mostly foo* and C99 comments). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Dec 31 2007 00:01, Carlos Corbacho wrote: On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote: On Dec 31 2007 00:01, Carlos Corbacho wrote: On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. Then consider yourself very lucky - some laptop manufacturers play nice and the card reader identifies itself, and works as, a USB mass storage device; so it works out of the box with no extra drivers needed for either the card reader, or the flash memory card. The Texas Instruments chip/ card reader that Alex's work here is currently aimed at does not - it has a completely proprietary, so called FlashMedia chip/ interface that talks to MMC/ SD, MemoryStick (/ Pro), and SmartMedia/ xD cards, of which TI have refused to release any specs. Yes, this chip doesn't even use sdhci for communicating with MMC/ SD cards - tifm_sd (Alex's previous work on the MMC/ SD front for this TI chip) handles that. MemoryStick support is more complicated in this case than MMC/ SD, given that on top of TI refusing to release specs for their own FlashMedia chips, Sony will also not release any specs on MemoryStick cards; the same is also true of xD with Olympus and Fuji. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Jan Engelhardt [EMAIL PROTECTED] wrote: On Dec 31 2007 00:01, Carlos Corbacho wrote: On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. USB storage type controllers have firmware that translates native MS protocol into USB storage (scsi-like) one. We are talking here about native protocol support, needed for dumb controllers. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. This is exactly the same as with tifm_sd module if you noticed. First, there are no modaliases for tifm (I was thinking to add them later, when at least two card types are supported, if at all), so the appropriate udev rule should be added (similar to the sd one). Second, it is impossible to guess in advance, which type of card is put into slot (Pro, legacy or IO of either sort). Same as mmc_block, actually. The only way to get it autoloaded, is, again, with appropriate udev rule (uevent is emitted when card type is detected). Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 01:01:08 Alex Dubov wrote: This is exactly the same as with tifm_sd module if you noticed. Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD cards. Second, it is impossible to guess in advance, which type of card is put into slot (Pro, legacy or IO of either sort). I imagined this to be the case. Same as mmc_block, actually. The only way to get it autoloaded, is, again, with appropriate udev rule (uevent is emitted when card type is detected). So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Carlos Corbacho [EMAIL PROTECTED] wrote: So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? It was handled by whoever manages the distro's udev rules until now. Here's the example: https://lists.ubuntu.com/archives/ubuntu-patches/2007-September/012537.html Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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/
