On 02/17/2014 08:03 PM, Lee Jones wrote:
From: Roger Tseng <rogerable@xxxxxxxxxxx>
Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.
Signed-off-by: Roger Tseng <rogerable@xxxxxxxxxxx>
---
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/rtsx_usb.c | 760 +++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/rtsx_usb.h | 628 +++++++++++++++++++++++++++++++++++
4 files changed, 1399 insertions(+)
create mode 100644 drivers/mfd/rtsx_usb.c
create mode 100644 include/linux/mfd/rtsx_usb.h
Applied again, thanks.
Would you also apply patch 2/3 and 3/3 that to make the device fully
operational for users? Or should they be applied by maintainers of
mmc/memstick subsystems?
Chris, would you give some comment?
I can apply them, but I need the other Maintainer Acks.
If they are build orthogonal i.e. there are no build dependencies
between them, it's probably better that they go into their associated
trees separately.
I think it would be better to apply them together since the later
patches really depend on the 1st one,so now we are waiting for Acks
>from mmc/memstick subsystems.
When you say "depend on", do you mean as a build depenency, or won't
run without the first patch applied?
The later 2 patches actually invoke symbols defined in the first
patch and won't compile if it is not applied first. The Kconfig
changes for the later oness also specified this by "depends on".
I'm not sure if this means "build dependency". Sorry for my unclear words.
Yes, that sounds like a build dependency i.e. will not build without
errors or warnings without the previous patch applied.
But there is no one specified for "memstick/host/" in MAINTAINERS.
Could anyone else Ack this?
Andrew (CC'ed) has been Acking these thus far.
Hi Chris and Andrew,
Would you please help comment PATCH 2/3 and 3/3 (for mmc and memstick,
respectively) or give Acks? Thus we can proceed with applying or
revision if necessary.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
