LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
@ 2008-02-10 22:57 Adrian McMenamin
  2008-02-10 23:05 ` [PATCH 2/2] SH/Dreamcast - joystick (controlpad) Adrian McMenamin
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Adrian McMenamin @ 2008-02-10 22:57 UTC (permalink / raw)
  To: dtor; +Cc: Paul Mundt, linux-sh, LKML

Adds support for the Dreamcast control pad.

This is a port of the 2.4 driver (never in mainline) by Yaegashi
Takeshi.

Signed-off-by: Adrian McMenamin <adrian@mcmen.demon.co.uk>

======

--- /dev/null	2007-10-16 19:02:41.000000000 +0100
+++ drivers/input/joystick/maplecontrol.c	2008-02-10 22:50:17.000000000 +0000
@@ -0,0 +1,215 @@
+/*
+ * 	SEGA Dreamcast controller driver
+ *	Based on drivers/usb/iforce.c
+ *
+ * 	Copyright Yaegashi Takeshi, 2001
+ *	Ported to 2.6 by Adrian McMenamin, 2008
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/timer.h>
+#include <linux/maple.h>
+#include <asm/mach/maple.h>
+
+MODULE_AUTHOR("YAEGASHI Takeshi <t@keshi.org>");
+MODULE_DESCRIPTION("SEGA Dreamcast controller driver");
+MODULE_LICENSE("GPL");
+
+struct dc_pad {
+	struct input_dev *dev;
+	int open;
+};
+
+static void dc_pad_callback(struct mapleq *mq)
+{
+	unsigned short buttons;
+	struct maple_device *mapledev = mq->dev;
+	struct dc_pad *pad = mapledev->private_data;
+	struct input_dev *dev = pad->dev;
+	unsigned char *res = mq->recvbuf;
+
+	buttons = ~*(unsigned short *)(res+8);
+
+	input_report_abs(dev, ABS_HAT0Y,
+			 (buttons & 0x0010 ? -1:0) + (buttons & 0x0020 ? 1:0));
+	input_report_abs(dev, ABS_HAT0X,
+			 (buttons & 0x0040 ? -1:0) + (buttons & 0x0080 ? 1:0));
+	input_report_abs(dev, ABS_HAT1Y,
+			 (buttons & 0x1000 ? -1:0) + (buttons & 0x2000 ? 1:0));
+	input_report_abs(dev, ABS_HAT1X,
+			 (buttons & 0x4000 ? -1:0) + (buttons & 0x8000 ? 1:0));
+
+	input_report_key(dev, BTN_C,      buttons & 0x0001);
+	input_report_key(dev, BTN_B,      buttons & 0x0002);
+	input_report_key(dev, BTN_A,      buttons & 0x0004);
+	input_report_key(dev, BTN_START,  buttons & 0x0008);
+	input_report_key(dev, BTN_Z,      buttons & 0x0100);
+	input_report_key(dev, BTN_Y,      buttons & 0x0200);
+	input_report_key(dev, BTN_X,      buttons & 0x0400);
+	input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+
+	input_report_abs(dev, ABS_GAS,   res[10]);
+	input_report_abs(dev, ABS_BRAKE, res[11]);
+	input_report_abs(dev, ABS_X,     res[12]);
+	input_report_abs(dev, ABS_Y,     res[13]);
+	input_report_abs(dev, ABS_RX,    res[14]);
+	input_report_abs(dev, ABS_RY,    res[15]);
+}
+
+static int dc_pad_open(struct input_dev *dev)
+{
+	struct dc_pad *pad = dev->private;
+	pad->open++;
+	return 0;
+}
+
+static void dc_pad_close(struct input_dev *dev)
+{
+	struct dc_pad *pad = dev->private;
+	pad->open--;
+}
+
+static int dc_pad_connect(struct maple_device *mdev)
+{
+	int i, error;
+	unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
+	struct dc_pad *pad;
+	struct input_dev *dev;
+
+	const short btn_bit[32] = {
+		BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
+		BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
+		-1, -1, -1, -1, -1, -1, -1, -1,
+		-1, -1, -1, -1, -1, -1, -1, -1,
+	};
+
+	const short abs_bit[32] = {
+		-1, -1, -1, -1, ABS_HAT0Y, ABS_HAT0Y, ABS_HAT0X, ABS_HAT0X,
+		-1, -1, -1, -1, ABS_HAT1Y, ABS_HAT1Y, ABS_HAT1X, ABS_HAT1X,
+		ABS_GAS, ABS_BRAKE, ABS_X, ABS_Y, ABS_RX, ABS_RY, -1, -1,
+		-1, -1, -1, -1, -1, -1, -1, -1,
+	};
+
+	pad = kzalloc(sizeof(struct dc_pad), GFP_KERNEL);
+	if (!pad)
+		return -ENOMEM;
+
+	dev = input_allocate_device();
+	if (!dev) {
+		kfree(pad);
+		return -ENOMEM;
+	}
+
+	pad->dev = dev;
+
+	mdev->private_data = pad;
+
+	for (i = 0; i < 32; i++)
+		if (data & (1<<i) && btn_bit[i] >= 0)
+			pad->dev->keybit[BTN_JOYSTICK/32] |= BIT(btn_bit[i]);
+
+	if (pad->dev->keybit[BTN_JOYSTICK/32])
+		pad->dev->evbit[0] |= BIT(EV_KEY);
+
+	for (i = 0; i < 32; i++)
+		if (data&(1<<i) && abs_bit[i] >= 0)
+			pad->dev->absbit[0] |= BIT(abs_bit[i]);
+
+	if (pad->dev->absbit[0])
+		pad->dev->evbit[0] |= BIT(EV_ABS);
+
+	for (i = ABS_X; i <= ABS_BRAKE; i++) {
+		pad->dev->absmax[i] = 255;
+		pad->dev->absmin[i] = 0;
+		pad->dev->absfuzz[i] = 0;
+		pad->dev->absflat[i] = 0;
+	}
+
+	for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++) {
+		pad->dev->absmax[i] = 1;
+		pad->dev->absmin[i] = -1;
+		pad->dev->absfuzz[i] = 0;
+		pad->dev->absflat[i] = 0;
+	}
+
+	pad->dev->private = pad;
+	pad->dev->open = dc_pad_open;
+	pad->dev->close = dc_pad_close;
+	pad->dev->event = NULL;
+	pad->dev->dev.parent = &mdev->dev;
+	pad->dev->name = mdev->product_name;
+	pad->dev->id.bustype = BUS_HOST;
+	input_set_capability(pad->dev, EV_ABS, MSC_SCAN);
+	input_set_drvdata(dev, pad);
+
+	error = input_register_device(pad->dev);
+	if (error) {
+		input_free_device(pad->dev);
+		kfree(pad);
+		return -ENODEV;
+	}
+
+	maple_getcond_callback(mdev, dc_pad_callback, HZ/50,
+		MAPLE_FUNC_CONTROLLER);
+
+	return 0;
+}
+
+static void dc_pad_disconnect(struct maple_device *mdev)
+{
+	struct dc_pad *pad = mdev->private_data;
+
+	input_unregister_device(pad->dev);
+	kfree(pad);
+}
+
+/* allow the controller to be used */
+static int probe_maple_controller(struct device *dev)
+{
+	struct maple_device *mdev = to_maple_dev(dev);
+	struct maple_driver *mdrv = to_maple_driver(dev->driver);
+	int error;
+
+	error = dc_pad_connect(mdev);
+	if (error)
+		return error;
+
+	mdev->driver = mdrv;
+
+	return 0;
+}
+
+static struct maple_driver dc_pad_driver = {
+	.function =	MAPLE_FUNC_CONTROLLER,
+	.connect =	dc_pad_connect,
+	.disconnect =	dc_pad_disconnect,
+	.drv = {
+		.name = "Dreamcast_controller",
+		.probe = probe_maple_controller,
+	},
+};
+
+static int __init dc_pad_init(void)
+{
+	return 	maple_driver_register(&dc_pad_driver.drv);
+}
+
+static void __exit dc_pad_exit(void)
+{
+	driver_unregister(&dc_pad_driver.drv);
+}
+
+module_init(dc_pad_init);
+module_exit(dc_pad_exit);



^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH 2/2] SH/Dreamcast - joystick (controlpad)
  2008-02-10 22:57 [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Adrian McMenamin
@ 2008-02-10 23:05 ` Adrian McMenamin
  2008-02-11  0:22 ` [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Mike Frysinger
  2008-02-11 16:13 ` Dmitry Torokhov
  2 siblings, 0 replies; 10+ messages in thread
From: Adrian McMenamin @ 2008-02-10 23:05 UTC (permalink / raw)
  To: dtor; +Cc: Paul Mundt, linux-sh, LKML

Changes to the Kconfig and Makefile needed to build the Maple controlpad
code.

Signed-off-by: Adrian McMenamin <adrian@mcmen.demon.co.uk>
======

diff --combined drivers/input/joystick/Kconfig
index 7c662ee,7c662ee..3566fa2
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@@ -282,4 -282,4 +282,17 @@@ config JOYSTICK_XPAD_LED
  	  This option enables support for the LED which surrounds the Big X on
  	  XBox 360 controller.
  
+config JOYSTICK_MAPLE
+	tristate "Dreamcast control pad"
+	depends on SH_DREAMCAST
+	select MAPLE
+	help
+	 Say Y here if you have a SEGA Dreamcast and want to use your
+	 controller.
+
+	 Most Dreamcast users will say Y.
+
+	 To compile this as a module choose M here: the
+	 module will be called maplecontrol.
+
  endif
diff --combined drivers/input/joystick/Makefile
index e855abb,e855abb..62929ef
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@@ -27,5 -27,5 +27,6 @@@ obj-$(CONFIG_JOYSTICK_TURBOGRAFX)	+= tu
  obj-$(CONFIG_JOYSTICK_TWIDJOY)		+= twidjoy.o
  obj-$(CONFIG_JOYSTICK_WARRIOR)		+= warrior.o
  obj-$(CONFIG_JOYSTICK_XPAD)		+= xpad.o
+ obj-$(CONFIG_JOYSTICK_MAPLE)		+= maplecontrol.o
  
  obj-$(CONFIG_JOYSTICK_IFORCE)		+= iforce/






^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-10 22:57 [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Adrian McMenamin
  2008-02-10 23:05 ` [PATCH 2/2] SH/Dreamcast - joystick (controlpad) Adrian McMenamin
@ 2008-02-11  0:22 ` Mike Frysinger
  2008-02-11 14:20   ` Adrian McMenamin
  2008-02-11 16:13 ` Dmitry Torokhov
  2 siblings, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2008-02-11  0:22 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: dtor, Paul Mundt, linux-sh, LKML

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sunday 10 February 2008, Adrian McMenamin wrote:
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> + ...
> +		if (data&(1<<i) && abs_bit[i] >= 0)

could use a few spaces in that first expression

> +/* allow the controller to be used */
> +static int probe_maple_controller(struct device *dev)
> +{
> +	struct maple_device *mdev = to_maple_dev(dev);
> +	struct maple_driver *mdrv = to_maple_driver(dev->driver);
> +	int error;
> +
> +	error = dc_pad_connect(mdev);
> +	if (error)
> +		return error;
> +
> +	mdev->driver = mdrv;
> +
> +	return 0;
> +}
> +
> +static struct maple_driver dc_pad_driver = {
> +	.function =	MAPLE_FUNC_CONTROLLER,
> +	.connect =	dc_pad_connect,
> +	.disconnect =	dc_pad_disconnect,
> +	.drv = {
> +		.name = "Dreamcast_controller",
> +		.probe = probe_maple_controller,
> +	},
> +};

no remove function ?  looks like the probe() forces a connect, but there's no 
remove() to force a disconnect ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11  0:22 ` [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Mike Frysinger
@ 2008-02-11 14:20   ` Adrian McMenamin
  2008-02-11 15:58     ` Dmitry Torokhov
  2008-02-11 16:19     ` Mike Frysinger
  0 siblings, 2 replies; 10+ messages in thread
From: Adrian McMenamin @ 2008-02-11 14:20 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: dtor, Paul Mundt, linux-sh, LKML

On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
>
> no remove function ?  looks like the probe() forces a connect, but there's
> no
> remove() to force a disconnect ...


Removing these devices (or any other plugged directly into the maple
ports) is a quick way to destroy your Dreamcast: hence they were never
implemented I guess. But there is no convincing reason for the software
not doing so, I suppose. I can just put in comments about it.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11 14:20   ` Adrian McMenamin
@ 2008-02-11 15:58     ` Dmitry Torokhov
  2008-02-11 16:19     ` Mike Frysinger
  1 sibling, 0 replies; 10+ messages in thread
From: Dmitry Torokhov @ 2008-02-11 15:58 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: Mike Frysinger, Paul Mundt, linux-sh, LKML

Hi Adrian,

On Mon, Feb 11, 2008 at 02:20:03PM +0000, Adrian McMenamin wrote:
> On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> >
> > no remove function ?  looks like the probe() forces a connect, but there's
> > no
> > remove() to force a disconnect ...
> 
> 
> Removing these devices (or any other plugged directly into the maple
> ports) is a quick way to destroy your Dreamcast: hence they were never
> implemented I guess. But there is no convincing reason for the software
> not doing so, I suppose. I can just put in comments about it.

But what will happen if the driver gets unloaded by user?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-10 22:57 [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Adrian McMenamin
  2008-02-10 23:05 ` [PATCH 2/2] SH/Dreamcast - joystick (controlpad) Adrian McMenamin
  2008-02-11  0:22 ` [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Mike Frysinger
@ 2008-02-11 16:13 ` Dmitry Torokhov
  2 siblings, 0 replies; 10+ messages in thread
From: Dmitry Torokhov @ 2008-02-11 16:13 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: Paul Mundt, linux-sh, LKML

Hi Adrian,

On Sun, Feb 10, 2008 at 10:57:01PM +0000, Adrian McMenamin wrote:
> +
> +static int dc_pad_open(struct input_dev *dev)
> +{
> +	struct dc_pad *pad = dev->private;
> +	pad->open++;
> +	return 0;
> +}
> +
> +static void dc_pad_close(struct input_dev *dev)
> +{
> +	struct dc_pad *pad = dev->private;
> +	pad->open--;
> +}

What is the point of the above 2 functions?

> +
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> +	int i, error;
> +	unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
> +	struct dc_pad *pad;
> +	struct input_dev *dev;
> +
> +	const short btn_bit[32] = {
> +		BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
> +		BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
> +		-1, -1, -1, -1, -1, -1, -1, -1,
> +		-1, -1, -1, -1, -1, -1, -1, -1,
> +	};
> +
> +	const short abs_bit[32] = {
> +		-1, -1, -1, -1, ABS_HAT0Y, ABS_HAT0Y, ABS_HAT0X, ABS_HAT0X,
> +		-1, -1, -1, -1, ABS_HAT1Y, ABS_HAT1Y, ABS_HAT1X, ABS_HAT1X,
> +		ABS_GAS, ABS_BRAKE, ABS_X, ABS_Y, ABS_RX, ABS_RY, -1, -1,
> +		-1, -1, -1, -1, -1, -1, -1, -1,
> +	};
> +
> +	pad = kzalloc(sizeof(struct dc_pad), GFP_KERNEL);
> +	if (!pad)
> +		return -ENOMEM;
> +
> +	dev = input_allocate_device();
> +	if (!dev) {
> +		kfree(pad);
> +		return -ENOMEM;
> +	}
> +
> +	pad->dev = dev;
> +
> +	mdev->private_data = pad;
> +
> +	for (i = 0; i < 32; i++)
> +		if (data & (1<<i) && btn_bit[i] >= 0)
> +			pad->dev->keybit[BTN_JOYSTICK/32] |= BIT(btn_bit[i]);
> +
> +	if (pad->dev->keybit[BTN_JOYSTICK/32])
> +		pad->dev->evbit[0] |= BIT(EV_KEY);
> +
> +	for (i = 0; i < 32; i++)
> +		if (data&(1<<i) && abs_bit[i] >= 0)
> +			pad->dev->absbit[0] |= BIT(abs_bit[i]);
> +
> +	if (pad->dev->absbit[0])
> +		pad->dev->evbit[0] |= BIT(EV_ABS);
> +
> +	for (i = ABS_X; i <= ABS_BRAKE; i++) {
> +		pad->dev->absmax[i] = 255;
> +		pad->dev->absmin[i] = 0;
> +		pad->dev->absfuzz[i] = 0;
> +		pad->dev->absflat[i] = 0;
> +	}
> +
> +	for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++) {
> +		pad->dev->absmax[i] = 1;
> +		pad->dev->absmin[i] = -1;
> +		pad->dev->absfuzz[i] = 0;
> +		pad->dev->absflat[i] = 0;
> +	}
> +
> +	pad->dev->private = pad;

input_set_drvdata().. Oh, wait, you are doing it below...

> +	pad->dev->open = dc_pad_open;
> +	pad->dev->close = dc_pad_close;
> +	pad->dev->event = NULL;

input_dev is zeroes upon initialization, no need to set unused methods
to NULL. Also please consider using a temp for input_dev, it should
reduce generated code a bit.

> +	pad->dev->dev.parent = &mdev->dev;
> +	pad->dev->name = mdev->product_name;
> +	pad->dev->id.bustype = BUS_HOST;
> +	input_set_capability(pad->dev, EV_ABS, MSC_SCAN);

I did not see the driver reporting MSC_SCAN events. Also, MSC_SCAN is
usually reprted as EV_MSC, not EV_ABS.

> +	input_set_drvdata(dev, pad);
> +
> +	error = input_register_device(pad->dev);
> +	if (error) {
> +		input_free_device(pad->dev);
> +		kfree(pad);
> +		return -ENODEV;

		return error;

There is no reason to "hide" real error reported by input_register_device.

> +	}
> +
> +	maple_getcond_callback(mdev, dc_pad_callback, HZ/50,
> +		MAPLE_FUNC_CONTROLLER);

Hmm, this could probably go into dc_pad_open so we dont poll hardware
if there are no users.

> +
> +	return 0;
> +}
> +
> +static void dc_pad_disconnect(struct maple_device *mdev)
> +{
> +	struct dc_pad *pad = mdev->private_data;
> +

Don't you need to stop polling callback? Either here ot in dc_pad_stop,
depending on where maple_getcond_callback() is.

> +	input_unregister_device(pad->dev);
> +	kfree(pad);
> +}
> +

-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11 14:20   ` Adrian McMenamin
  2008-02-11 15:58     ` Dmitry Torokhov
@ 2008-02-11 16:19     ` Mike Frysinger
  2008-02-11 16:25       ` Dmitry Torokhov
  1 sibling, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2008-02-11 16:19 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: dtor, Paul Mundt, linux-sh, LKML

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Monday 11 February 2008, Adrian McMenamin wrote:
> On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> > no remove function ?  looks like the probe() forces a connect, but
> > there's no remove() to force a disconnect ...
>
> Removing these devices (or any other plugged directly into the maple
> ports) is a quick way to destroy your Dreamcast: hence they were never
> implemented I guess. But there is no convincing reason for the software
> not doing so, I suppose. I can just put in comments about it.

and not allow the driver to be built as a module until the comments become 
code ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11 16:19     ` Mike Frysinger
@ 2008-02-11 16:25       ` Dmitry Torokhov
  2008-02-11 16:29         ` Adrian McMenamin
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Torokhov @ 2008-02-11 16:25 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: Adrian McMenamin, Paul Mundt, linux-sh, LKML

On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
> On Monday 11 February 2008, Adrian McMenamin wrote:
> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> > > no remove function ?  looks like the probe() forces a connect, but
> > > there's no remove() to force a disconnect ...
> >
> > Removing these devices (or any other plugged directly into the maple
> > ports) is a quick way to destroy your Dreamcast: hence they were never
> > implemented I guess. But there is no convincing reason for the software
> > not doing so, I suppose. I can just put in comments about it.
> 
> and not allow the driver to be built as a module until the comments become 
> code ...
> -mike

Normally drivers can be unbound from devices via sysfs even if they are
built-in, not modules.


-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11 16:25       ` Dmitry Torokhov
@ 2008-02-11 16:29         ` Adrian McMenamin
  2008-02-11 16:45           ` Mike Frysinger
  0 siblings, 1 reply; 10+ messages in thread
From: Adrian McMenamin @ 2008-02-11 16:29 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Mike Frysinger, Paul Mundt, linux-sh, LKML

On Mon, February 11, 2008 4:25 pm, Dmitry Torokhov wrote:
> On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
>> On Monday 11 February 2008, Adrian McMenamin wrote:
>> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
>> > > no remove function ?  looks like the probe() forces a connect, but
>> > > there's no remove() to force a disconnect ...
>> >
>> > Removing these devices (or any other plugged directly into the maple
>> > ports) is a quick way to destroy your Dreamcast: hence they were never
>> > implemented I guess. But there is no convincing reason for the
>> software
>> > not doing so, I suppose. I can just put in comments about it.
>>
>> and not allow the driver to be built as a module until the comments
>> become
>> code ...
>> -mike
>
> Normally drivers can be unbound from devices via sysfs even if they are
> built-in, not modules.
>
>
I meant comments about not being so silly as to start plugging maple
devices in and out of the ports on the DC. I understand the point about
the code and will rework appropriately.

All I wanted to do is take somebody's old code and get it to work on 2.6.
But nothing is that simple :-/


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
  2008-02-11 16:29         ` Adrian McMenamin
@ 2008-02-11 16:45           ` Mike Frysinger
  0 siblings, 0 replies; 10+ messages in thread
From: Mike Frysinger @ 2008-02-11 16:45 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: Dmitry Torokhov, Paul Mundt, linux-sh, LKML

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Monday 11 February 2008, Adrian McMenamin wrote:
> On Mon, February 11, 2008 4:25 pm, Dmitry Torokhov wrote:
> > On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
> >> On Monday 11 February 2008, Adrian McMenamin wrote:
> >> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> >> > > no remove function ?  looks like the probe() forces a connect, but
> >> > > there's no remove() to force a disconnect ...
> >> >
> >> > Removing these devices (or any other plugged directly into the maple
> >> > ports) is a quick way to destroy your Dreamcast: hence they were never
> >> > implemented I guess. But there is no convincing reason for the
> >>
> >> software
> >>
> >> > not doing so, I suppose. I can just put in comments about it.
> >>
> >> and not allow the driver to be built as a module until the comments
> >> become code ...
> >
> > Normally drivers can be unbound from devices via sysfs even if they are
> > built-in, not modules.
>
> I meant comments about not being so silly as to start plugging maple
> devices in and out of the ports on the DC. I understand the point about
> the code and will rework appropriately.

is that a maple bus limitation or a joystick issue ?  if maple, then there 
really isnt much holding back this driver ...

> All I wanted to do is take somebody's old code and get it to work on 2.6.
> But nothing is that simple :-/

better than nothing.  if someone doesnt like the lack of functionality, they 
know where the source is ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-02-11 16:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-10 22:57 [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Adrian McMenamin
2008-02-10 23:05 ` [PATCH 2/2] SH/Dreamcast - joystick (controlpad) Adrian McMenamin
2008-02-11  0:22 ` [PATCH 1/2] SH/Dreamcast - joystick (Control pad) Mike Frysinger
2008-02-11 14:20   ` Adrian McMenamin
2008-02-11 15:58     ` Dmitry Torokhov
2008-02-11 16:19     ` Mike Frysinger
2008-02-11 16:25       ` Dmitry Torokhov
2008-02-11 16:29         ` Adrian McMenamin
2008-02-11 16:45           ` Mike Frysinger
2008-02-11 16:13 ` Dmitry Torokhov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).