linux-kernel - Re: staging/dream: add gpio and pmem support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091027232521.GA16782@elf.ucw.cz>
Date:	Wed, 28 Oct 2009 00:25:22 +0100
From:	Pavel Machek <pavel@....cz>
To:	Greg KH <greg@...ah.com>
Cc:	Arve Hj?nnev?g <arve@...roid.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Brian Swetland <swetland@...gle.com>
Subject: Re: staging/dream: add gpio and pmem support

Hi!

> > What is so wrong with wakelocks? They are just nops in this case.
> 
> Are they really?  Then why is the whole large file needed?

It is probably not, I went to "submit vendor code, then clean it up"
mode. CONFIG_HAS_WAKELOCK should be disabled, so it basically stubs
itself out.

> > 2) you submit it
> 
> Wait, it has to BUILD!  This code has never been able to be built.  Only
> after I disabled it from the CONFIG_ANDROID have I noticed this, which
> is my fault.  But it needs to get fixed, and taking a bunch of code in
> addition to the mess we have now, seems like the wrong way to do it.

It seems to be the only reasonable way. gpio is used from all the
other stuff, and removing it is not really an option.

> > Now, I see that wakelocks are show-stopper for merging into kernel
> > proper, but what is the problem for staging? We merged drivers with
> > OS_MEMORY_ALLOCATE(); wakelocks are just nops in this case.
> > 
> > Could we please clean this driver in-tree? (Wakelocks are already nops
> > due to #ifdef magic, cleaning them incrementally is easy.)
> 
> With this patch, will it build properly?

Its certainly way closer to building... it builds for me, with
something like below; platform devices really are initialized from
board-* files and get passed parameters.

I should get some sleep now, I'll take closer look tommorow.

									Pavel

diff --git a/arch/arm/mach-msm/include/mach/board.h b/arch/arm/mach-msm/include/mach/board.h
index 264d62e..9e68db2 100644
--- a/arch/arm/mach-msm/include/mach/board.h
+++ b/arch/arm/mach-msm/include/mach/board.h
@@ -35,4 +61,50 @@ void __init msm_init_irq(void);
 void __init msm_init_gpio(void);
 void __init msm_clock_init(void);
 
+struct msm_camera_io_ext {
+	uint32_t mdcphy;
+	uint32_t mdcsz;
+	uint32_t appphy;
+	uint32_t appsz;
+};
+
+struct msm_camera_device_platform_data {
+	void (*camera_gpio_on) (void);
+	void (*camera_gpio_off)(void);
+	struct msm_camera_io_ext ioext;
+};
+
+#ifdef CONFIG_SENSORS_MT9T013
+struct msm_camera_legacy_device_platform_data {
+	int sensor_reset;
+	int sensor_pwd;
+	int vcm_pwd;
+	void (*config_gpio_on) (void);
+	void (*config_gpio_off)(void);
+};
+#endif
+
+#define MSM_CAMERA_FLASH_NONE 0
+#define MSM_CAMERA_FLASH_LED  1
+
+struct msm_camera_sensor_info {
+	const char *sensor_name;
+	int sensor_reset;
+	int sensor_pwd;
+	int vcm_pwd;
+	int mclk;
+	int flash_type;
+	struct msm_camera_device_platform_data *pdata;
+};
+
+struct snd_endpoint {
+	int id;
+	const char *name;
+};
+
+struct msm_snd_endpoints {
+	struct snd_endpoint *endpoints;
+	unsigned num;
+};
+
 #endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
index 2f7b4c8..8b88e4a 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
@@ -116,6 +116,7 @@
 
 #define MSM_AD5_PHYS          0xAC000000
 #define MSM_AD5_SIZE          (SZ_1M*13)
+#define MSM_AD5_BASE          IOMEM(0xE0300000)
 
 
 #endif


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/