Re: [PATCH v10 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel wrote: > > > On 14/11/14 11:08, Andy Yan wrote: >> >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote: >>> >>> On 14/11/14 10:53, Andy Yan wrote: Hi ZubairLK: Thanks for your review. On 2014年11月14日 18:19, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > Nice work on this patch series. Its getting better and better :). > > On 14/11/14 03:27, Andy Yan wrote: >> hdmi phy clock symbol and transmission termination value >> can adjust platform specific to get the best SI > ^Is this signal integrity? yes , SI is signal integrity, such as eye diagram measurement > Are these two disjoint features in separate patches? > >> also add mode_valid interface for some platform may not support >> all the display mode > Sounds like another separate patch to me. :) they can seperate > Also, This series is becoming quite large. With major changes and fixes > mixed together. > > Patch 3 splits imx-drm. > Patch 4 moves dw-drm out of imx-drm folder. > Patch 7 adds binding > Patch 9 converts to drm bridge. > > Can these be placed together easily? > And in the start. i.e. patch 1, 2, 3, 4, > > Then all fixes etc can come afterwards? > > It helps when checking histories later as to how a driver was made and > how fixes happened. > > Especially when file moves happen.. Do you mean we can rearrange the patch series? put patch 3, 4 ,7, 9 together one bye one than followed by the fixes patches 5 ,6, 8, 11 ? >>> Yes. Rearrange so that the split imx-drm/imx-hdmi and conversion to >>> drm-bridge is at the start of the series. >>> Then the rest are bug fixes and feature additions. >> Can I put patch#1(make checkpatch happy) and patch#2 (defer probe) as the >> first two patch. >> Daniel from Google chromium think it's better to put the two slightly >> changes in the front for easy review. Sorry, I didn't see this conversation before my earlier emails. I was suggesting to Andy to arrange his patches like this: (1) fixes that directly apply to imx-drm as it is today. (2) split out the "generic dw_hdmi" parts from imx-hdmi into dw_hdmi.c (3) convert dw_hdmi.c to a drm_bridge (4) move the dw_hdmi.c bridge implementation to drm/bridge (5) modifications to dw_hdmi.c required to support hdmi on rk3288 (5) add rk3288-hdmi.c to drm/rockchip (at least whenever drm/rockchip lands) The idea being that we can start landing the patches for (1) even while we are still debating / reviewing (2)+ upstream. > Sure. > > I am not the maintainer. They have to make the final decision. imx-drm is still in staging. I do not see anyone listed explicitly under MAINTAINERS for drivers/staging/imx-drm, so by default I guess it falls back to gregkh (drivers/staging/)? The "Commit" field in git log seems to back this up. Although, based on Author, I think we also want the opinions of Philipp Zabel and Russel King. Thanks, -djk > > ZubairLK ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Sat, Nov 15, 2014 at 06:07:50PM +0800, Daniel Kurtz wrote: > On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel > wrote: > > > > > > On 14/11/14 11:08, Andy Yan wrote: > >> > >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote: > >>> > >>> On 14/11/14 10:53, Andy Yan wrote: > Hi ZubairLK: > Thanks for your review. > On 2014年11月14日 18:19, Zubair Lutfullah Kakakhel wrote: > > Hi Andy, > > > > Nice work on this patch series. Its getting better and better :). > > > > On 14/11/14 03:27, Andy Yan wrote: > >> hdmi phy clock symbol and transmission termination value > >> can adjust platform specific to get the best SI > > ^Is this signal integrity? > yes , SI is signal integrity, such as eye diagram measurement > > Are these two disjoint features in separate patches? > > > >> also add mode_valid interface for some platform may not support > >> all the display mode > > Sounds like another separate patch to me. :) > they can seperate > > Also, This series is becoming quite large. With major changes and fixes > > mixed together. > > > > Patch 3 splits imx-drm. > > Patch 4 moves dw-drm out of imx-drm folder. > > Patch 7 adds binding > > Patch 9 converts to drm bridge. > > > > Can these be placed together easily? > > And in the start. i.e. patch 1, 2, 3, 4, > > > > Then all fixes etc can come afterwards? > > > > It helps when checking histories later as to how a driver was made and > > how fixes happened. > > > > Especially when file moves happen.. > Do you mean we can rearrange the patch series? > put patch 3, 4 ,7, 9 together one bye one > than followed by the fixes patches 5 ,6, 8, 11 ? > >>> Yes. Rearrange so that the split imx-drm/imx-hdmi and conversion to > >>> drm-bridge is at the start of the series. > >>> Then the rest are bug fixes and feature additions. > >> Can I put patch#1(make checkpatch happy) and patch#2 (defer probe) as > >> the first two patch. > >> Daniel from Google chromium think it's better to put the two slightly > >> changes in the front for easy review. > > Sorry, I didn't see this conversation before my earlier emails. > > I was suggesting to Andy to arrange his patches like this: > (1) fixes that directly apply to imx-drm as it is today. > (2) split out the "generic dw_hdmi" parts from imx-hdmi into dw_hdmi.c > (3) convert dw_hdmi.c to a drm_bridge > (4) move the dw_hdmi.c bridge implementation to drm/bridge > (5) modifications to dw_hdmi.c required to support hdmi on rk3288 > (5) add rk3288-hdmi.c to drm/rockchip (at least whenever drm/rockchip lands) > > The idea being that we can start landing the patches for (1) even > while we are still debating / reviewing (2)+ upstream. > > > Sure. > > > > I am not the maintainer. They have to make the final decision. > > imx-drm is still in staging. I do not see anyone listed explicitly > under MAINTAINERS for drivers/staging/imx-drm, so by default I guess > it falls back to gregkh (drivers/staging/)? > The "Commit" field in git log seems to back this up. > > Although, based on Author, I think we also want the opinions of > Philipp Zabel and Russel King. Once the wranglings on the patch series are complete, I do intend to test it on the platforms I have - and remember that I do have the ALSA based audio and CEC bits as well, some of which will probably need a little bit of re-work. All in all, I welcome the renaming of this to include a reference to DesignWare - I've always thought it's a mistake that the HDMI interface in iMX6 was not named with a "dw" prefix as the docs contain references to it being a DesignWare IP module. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Sat, Nov 15, 2014 at 10:12:18AM +, Russell King - ARM Linux wrote: > Once the wranglings on the patch series are complete, I do intend to test > it on the platforms I have - and remember that I do have the ALSA based > audio and CEC bits as well, some of which will probably need a little bit > of re-work. > > All in all, I welcome the renaming of this to include a reference to > DesignWare - I've always thought it's a mistake that the HDMI interface > in iMX6 was not named with a "dw" prefix as the docs contain references > to it being a DesignWare IP module. One thing I would ask is that the subsequent submissions do not thread onto the previous submission. It may seem a good idea (people claim that it allows the previous reviews to be trivially found) but these people forget an important side effect from this behaviour - when looking at the message index in a threaded mail reader (like mutt), each reply to a thread moves the subject line by three characters to the right. What this means is that after about five or six iterations of the submission, there is no longer any subject line visible. Moreover, it means that with lesser iterations, it becomes much more difficult to see /any/ of the review thread structure. I would suggest that if you do want to "connect" the subsequent submissions, please use the same reference message for each submission. In other words, rather than: v1 0/2 +-> v1 1/2 +-> v1 2/2 +-> v2 0/2 +-> v2 1/2 +-> v2 2/2 +-> v3 0/2 +-> v3 1/2 +-> v3 2/2 ... This is done instead: v1 0/2 +-> v1 1/2 +-> v1 2/2 +-> v2 0/2 | +-> v2 1/2 | +-> v2 2/2 +-> v3 0/2 | +-> v3 1/2 | +-> v3 2/2 ... which is a compromise between threading the messages together, and keeping stopping the thread pushing the subject line completely off the right hand side of the screen. In this case, I'd suggest a reference of: 1415793593-5075-1-git-send-email-andy@rock-chips.com which is the v8 covering message which started this big thread. Thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: fix coding style warning
Simple style fix ("else is not generally useful after a break or return").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index c653ad6..cc3a446 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -126,26 +126,24 @@ static void crc32_init(void)
{
if (bcrc32initialized == 1)
return;
- else {
- sint i, j;
- u32 c;
- u8 *p = (u8 *)&c, *p1;
- u8 k;
-
- c = 0x1234;
- for (i = 0; i < 256; ++i) {
- k = crc32_reverseBit((u8)i);
- for (c = ((u32)k) << 24, j = 8; j > 0; --j)
- c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
- (c << 1);
- p1 = (u8 *)&crc32_table[i];
- p1[0] = crc32_reverseBit(p[3]);
- p1[1] = crc32_reverseBit(p[2]);
- p1[2] = crc32_reverseBit(p[1]);
- p1[3] = crc32_reverseBit(p[0]);
- }
- bcrc32initialized = 1;
+ sint i, j;
+ u32 c;
+ u8 *p = (u8 *)&c, *p1;
+ u8 k;
+
+ c = 0x1234;
+ for (i = 0; i < 256; ++i) {
+ k = crc32_reverseBit((u8)i);
+ for (c = ((u32)k) << 24, j = 8; j > 0; --j)
+ c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
+ (c << 1);
+ p1 = (u8 *)&crc32_table[i];
+ p1[0] = crc32_reverseBit(p[3]);
+ p1[1] = crc32_reverseBit(p[2]);
+ p1[2] = crc32_reverseBit(p[1]);
+ p1[3] = crc32_reverseBit(p[0]);
}
+ bcrc32initialized = 1;
}
static u32 getcrc32(u8 *buf, u32 len)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: fix coding style warning
On 11/15/2014 08:25 AM, Christian Resell wrote:
Simple style fix ("else is not generally useful after a break or return").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
This patch leads to the following build warnings:
CC [M] drivers/staging/rtl8712/rtl871x_security.o
In file included from drivers/staging/rtl8712/osdep_service.h:43:0,
from drivers/staging/rtl8712/rtl871x_security.c:45:
drivers/staging/rtl8712/rtl871x_security.c: In function ‘crc32_init’:
drivers/staging/rtl8712/basic_types.h:35:14: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
#define sint signed int
^
drivers/staging/rtl8712/rtl871x_security.c:129:2: note: in expansion of macro
‘sint’
sint i, j;
^
The previous code had braces around the code in question. Either you need to
leave those braces, or you need to move the declarations.
Please compile test your patches!
Larry
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index c653ad6..cc3a446 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -126,26 +126,24 @@ static void crc32_init(void)
{
if (bcrc32initialized == 1)
return;
- else {
- sint i, j;
- u32 c;
- u8 *p = (u8 *)&c, *p1;
- u8 k;
-
- c = 0x1234;
- for (i = 0; i < 256; ++i) {
- k = crc32_reverseBit((u8)i);
- for (c = ((u32)k) << 24, j = 8; j > 0; --j)
- c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
- (c << 1);
- p1 = (u8 *)&crc32_table[i];
- p1[0] = crc32_reverseBit(p[3]);
- p1[1] = crc32_reverseBit(p[2]);
- p1[2] = crc32_reverseBit(p[1]);
- p1[3] = crc32_reverseBit(p[0]);
- }
- bcrc32initialized = 1;
+ sint i, j;
+ u32 c;
+ u8 *p = (u8 *)&c, *p1;
+ u8 k;
+
+ c = 0x1234;
+ for (i = 0; i < 256; ++i) {
+ k = crc32_reverseBit((u8)i);
+ for (c = ((u32)k) << 24, j = 8; j > 0; --j)
+ c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
+ (c << 1);
+ p1 = (u8 *)&crc32_table[i];
+ p1[0] = crc32_reverseBit(p[3]);
+ p1[1] = crc32_reverseBit(p[2]);
+ p1[2] = crc32_reverseBit(p[1]);
+ p1[3] = crc32_reverseBit(p[0]);
}
+ bcrc32initialized = 1;
}
static u32 getcrc32(u8 *buf, u32 len)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: me4000: Fixed code style issue
Fixed checkpatch.pl error message. Space prohibited before that ',' Signed-off-by: Marcus Hufvudsson --- drivers/staging/comedi/drivers/me4000.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/me4000.c b/drivers/staging/comedi/drivers/me4000.c index ae6ac49..fc67419 100644 --- a/drivers/staging/comedi/drivers/me4000.c +++ b/drivers/staging/comedi/drivers/me4000.c @@ -416,7 +416,7 @@ static void me4000_reset(struct comedi_device *dev) val |= PLX9052_CNTRL_PCI_RESET; outl(val, info->plx_regbase + PLX9052_CNTRL); val &= ~PLX9052_CNTRL_PCI_RESET; - outl(val , info->plx_regbase + PLX9052_CNTRL); + outl(val, info->plx_regbase + PLX9052_CNTRL); /* 0x8000 to the DACs means an output voltage of 0V */ for (chan = 0; chan < 4; chan++) -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: bcm2048: fix coding style error
Simple style fix (checkpatch.pl: "space prohibited before that ','").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { "bcm2048" , 0 },
+ { "bcm2048", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: bcm2048: fix coding style error
On 11/15, Christian Resell wrote:
> Simple style fix (checkpatch.pl: "space prohibited before that ','").
> For the eudyptula challenge (http://eudyptula-challenge.org/).
Nice, however we do not need the information about the 'eudyptula
challenge' in the commit message.
If you want to include extra information please do it after the '---'
line (just below the signed-off). You will find more details in the
SubmittingPatches (chapter 15) of the kernel documentation.
Thanks,
Konrad
> Signed-off-by: Christian F. Resell
> ---
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 2bba370..bdc6854 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> i2c_client *client)
> * bcm2048_i2c_driver - i2c driver interface
> */
> static const struct i2c_device_id bcm2048_id[] = {
> - { "bcm2048" , 0 },
> + { "bcm2048", 0 },
> { },
> };
> MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: bcm2048: fix coding style error
On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> On 11/15, Christian Resell wrote:
> > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > For the eudyptula challenge (http://eudyptula-challenge.org/).
>
> Nice, however we do not need the information about the 'eudyptula
> challenge' in the commit message.
>
> If you want to include extra information please do it after the '---'
> line (just below the signed-off). You will find more details in the
> SubmittingPatches (chapter 15) of the kernel documentation.
Greg is staging tree maintainer... And if single extra space is all
you can fix in the driver, perhaps it is not worth the patch?
Pavel
> Thanks,
> Konrad
>
> > Signed-off-by: Christian F. Resell
> > ---
> > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > index 2bba370..bdc6854 100644
> > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> > i2c_client *client)
> > * bcm2048_i2c_driver - i2c driver interface
> > */
> > static const struct i2c_device_id bcm2048_id[] = {
> > - { "bcm2048" , 0 },
> > + { "bcm2048", 0 },
> > { },
> > };
> > MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > ___
> > devel mailing list
> > de...@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: bcm2048: fix coding style error
On Sat, Nov 15, 2014 at 09:59:34PM +0100, Pavel Machek wrote: > On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote: > > On 11/15, Christian Resell wrote: > > > Simple style fix (checkpatch.pl: "space prohibited before that ','"). > > > For the eudyptula challenge (http://eudyptula-challenge.org/). > > > > Nice, however we do not need the information about the 'eudyptula > > challenge' in the commit message. > > > > If you want to include extra information please do it after the '---' > > line (just below the signed-off). You will find more details in the > > SubmittingPatches (chapter 15) of the kernel documentation. > > Greg is staging tree maintainer... And if single extra space is all > you can fix in the driver, perhaps it is not worth the patch? I am not the maintainer of drivers/staging/media/ please look at MAINTAINERS before you make statements like that. And yes, one space fixes is just fine, that's why the code is in staging. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
On Fri, 14 Nov 2014, Sean O. Stalley wrote: > To summarize the spec: > MA USB groups a host & connected devices into MA service sets (MSS). > The architectural limit is 254 MA devices per MSS. > > If the host needs to connect more devices than that, It can start a > new MSS and connect to 254 more MA devices. > > > > Is supporting up to 254 devices on one machine sufficient? It's probably more than enough. > Would it make sense (and does the usb stack support) having 254 root > ports on one host controller? If so, we could make our host > controller instance have 254 ports. I'm guessing the hub driver may have > a problem with this (especially for superspeed). The USB stack is likely to have problems if there are more than 31 ports on any hub. > If that doesn't make sense (or isn't supported), we can have 1 host > controller instance per MA device. Would that be preferred? It doesn't make much difference. Whatever you think will be easier to support. You might check and see how usbip does it. > > Also, I noticed that your patch adds a new bus type for these MA host > > controllers. It really seems like overkill to have a whole new bus > > type if there's only going to be one device on it. > > The bus was added when we were quickly trying to replace the platform > device code. It's probably not the right thing to do. > > I'm still not sure why we can't make our hcd a platform device, > especially since dummy_hcd & the usbip's hcd are both platform devices. A platform device is the right way to go. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: bcm2048: fix coding style error
On 11/15, Pavel Machek wrote:
> On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> > On 11/15, Christian Resell wrote:
> > > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > > For the eudyptula challenge (http://eudyptula-challenge.org/).
> >
> > Nice, however we do not need the information about the 'eudyptula
> > challenge' in the commit message.
> >
> > If you want to include extra information please do it after the '---'
> > line (just below the signed-off). You will find more details in the
> > SubmittingPatches (chapter 15) of the kernel documentation.
>
> Greg is staging tree maintainer... And if single extra space is all
> you can fix in the driver, perhaps it is not worth the patch?
I think that every contribution, as long as it acctually fixes
something, is worth the patch. The beauty of the open source community
is that we do when we have time as much as we are able to do - totally
no stress.
You, Pavel, are more experienced however those who are not have to learn
somehow and one of the options is to start with something very simple.
Sometimes the 'simple' means oneliner however as long as it compiles, is
inline with the coding standard and in general is an improvement then it
is good.
Regards,
Konrad
> Pavel
>
> > Thanks,
> > Konrad
> >
> > > Signed-off-by: Christian F. Resell
> > > ---
> > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > index 2bba370..bdc6854 100644
> > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> > > i2c_client *client)
> > > * bcm2048_i2c_driver - i2c driver interface
> > > */
> > > static const struct i2c_device_id bcm2048_id[] = {
> > > - { "bcm2048" , 0 },
> > > + { "bcm2048", 0 },
> > > { },
> > > };
> > > MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > > ___
> > > devel mailing list
> > > de...@linuxdriverproject.org
> > > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
From Mrs. Amanda.
I am Mrs. Amanda Madison a foreign investor from western part (England) I have been looking forward to come to your country and invest but I don't have any one in their because i will need to buy a house where I will live till I make the survie of land to sit up my Industry, then in return You will be entitled of 9.5% of the monthly income generated from the company. Reply me to know the next step Thanks yours Mrs. Amanda Madison Email: amandamadiso...@outlook.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
