KANN ICH DEPONIEREN 18.000.000,00 GBP IN IHREM KONTO ?

2014-06-25 Thread Frau Jacqueline Benett-Baggs Murchie 
Guten Tag ,


  Bitte nehmen Sie meine aufrichtigen Entschuldigungen an, wenn meine E-mail 
Ihre
 pers?nliche Ethik nicht trifft.


  F?r ich wei?, dass dies wie ein vollst?ndiges Eindringen zu Ihrer Ruhe 
scheinen
 kann, aber zurzeit ,dies ist meine Option f?r Kommunikation zu Ihnen.
  Dies k?nnte fremd oder wahrscheinlich unwahr scheinen,wegen der Hoehe von
 Ausschuss E-mail,die wir t?glich empfangen, aber ich glaube, dass dies noch der
 echteste Weg ist, einen wahren Charakter zu kontaktieren.Ich heisse Frau
 Jacqueline Benett-Baggs Murchie {Eine Vereinigten Staaten von amerikanischer
 Frau},eine Witwe zu Sp?tem Herrn Benett-Baggs Murchie {Mein Ehemann hat mit
 einem ?l refinary Lukoil in Russland f?r 31 Jahre gearbeitet} Vor seinem
 tragischen Tod in Japan 11. M?rz. 2011.


  Mein Ehemann war auf einer Gesch?ftsreise nach Japan Wenn der h?ssliche
 Vorfall, der ihn von mir weggenommen hat, gestreikt hat. Hier ist eine
 Verbindung f?r Fotos der Katastrophe 
{http://www.boston.com/bigpicture/2011/03/massive_earthquake_hits_japan.h
 tml}Ich
 bin 74years alt und leide an lange Zeit Krebs von der Speiser?hre. Ich bin 
jetzt
 im Krankenhaus {NCI Hospital PT 13717, Jalan BBN 2/1, Putra Nilai, Negeri
 Sembilan, 71800], Malaysia.


  Von allen Anzeigen verschlechtert sich meine Bedingung wirklich und es ist
 ziemlich offensichtlich, dass ich mehr als zwei Monate {gem?? medizinischen
 Berichten von einem Arzt}nicht leben werde.Dies ist, weil die Krebsphase zu
 einer sehr schlechten Phase erreichen hat.Mein sp?ter Ehemann war sehr
 wohlhabend und reich und nach seinem Tod,ich habe alle sein Gesch?ft und
 Reichtum geerbt.


  Mein Ehemann hat die Summe von ?18.000.000,00 GBP mit einer Bank in Schottland
 deponiert, Mein Ehemann und ich haben geplant, dieses Geld Zu Benutzen, Und
 ?ffnungs-h?he Eine Gewebefirma Vor Dem Japan Tsunami Krise. Mein Ehemann hat
 mich der Nutznie?er des Treuhandverm?gens genannt, weil wir keine Kinder gehabt
 haben.
  Da ich nichts habe, f?r mehr zu leben.Der Arzt hat mir geraten,dass ich f?r
 mehr als zwei Monate nicht leben kann,so habe ich mich jetzt entschieden, Teil
 von diesem Reichtum zu teilen,zur Entwicklung von dem wenigen privilegierten
 Leute in Europa beizutragen,da dies die Wunsch von meinem Ehemann Herrn
 Benett-Baggs Murchie bevor seinem Tod ist.


  Ich habe Behandlung f?r meinen ?sophagealen Krebs erlebt. Ich habe, da meine
 F?higkeit verloren hat, zu reden, und meine ?rzte haben mir erz?hlt, dass ich
 nur ein paar Wochen habe, zu leben.Des meines Ehemanns Familienwunsch mich
 Verstorbene Um diesen Reichtum zu erlangen. Ich kann mit der Qual nicht leben,
 von dieser riesigen Verantwortung zu welchem des meines sp?ten Ehemanns
 Familienmitglieds anzuvertrauen Weil sie Ungl?ubigen sind. Ich will diesen
 Fonds, zu WOHLT?TIGKEITEN ORGANISATIONEN verteilt zu werden. Bitte, Ich will
 Sie, mir Vertreter zu helfen, als der Nutznie?er, die Fonds von der Bank zu
 sammeln und verteilen Sie zu Wohlt?tigkeit.


  Ich bete ehrlich,dass dieses Geld,wenn es zu Ihnen ?berweist ist,sollen Sie
 versichern,dass es f?r den gesagten Zweck benutzt werden muss.Weil ich darauf
 gekommen bin,dass jene Reichtumerwerbung ohne Christus zu erfahren, ist
 Eitelkeit auf Eitelkeit.F?r Ihre Hilfe,habe ich 30% von diesem gesamten Geld
 {?18.000.000,00}f?r Sie gelegt, auf Grund Ihrer pers?nlichen Bem?hung, die Sie
 f?r Ihren pers?nlichen Gebrauch sofort das Geld auf Sie ?berweist ist,
 abziehenwerden.Zuletzt,ich bete und hoffe, dass wenn das Geld schlie?lich auf
 Sie ?berweisen ist, werden Sie es umsichtig gem?? meinem Willen und Gott
 benutzen {der 70% vom Geld zum wenigen privilegierten in Europa zu spenden}.




 Ihres in Christus.


 Frau Jacqueline Benett-Baggs Murchie
 E-MAIL : mrsjacquelinemur...@gmail.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/4] Staging: unisys: remove buildDate and buildTime arguments from BusDeviceInfo_Init

2014-06-25 Thread Greg KH 
On Wed, Jun 25, 2014 at 11:48:24AM -0500, Ken Cox wrote:
> The unisys drivers no longer need to record the build date and time since the
> same info is already in the kernel elsewhere.

This should be done instead of the first patch.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/4] Staging: unisys: Remove build_date and build_time from virtpci_driver structure

2014-06-25 Thread Greg KH 
On Wed, Jun 25, 2014 at 11:48:25AM -0500, Ken Cox wrote:
> The drivers do not need to keep track of these fields since the same
> information is present elsewhere in the kernel.
> 
> Signed-off-by: Ken Cox 

Again, just do this, not the first one at all.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] Staging: unisys: remove references to __DATE__ and __TIME__

2014-06-25 Thread Greg KH 
On Wed, Jun 25, 2014 at 11:48:23AM -0500, Ken Cox wrote:
> The use of __DATE__ and __TIME__ is no longer allowed in the kernel so this
> commit removes those.  They were once useful when the drivers were being
> built externally, but now that the drivers are in the kernel the use of the
> macros is redundant since the kernel already has the same information
> elsewhere.
> 
> In addition, using these macros breaks the build if using gcc 4.9.0
> 
> Reported-by: Greg Kroah-Hartman 
> Signed-off-by: Ken Cox 
> ---
>  drivers/staging/unisys/uislib/uisutils.c|  8 +++-
>  drivers/staging/unisys/virthba/virthba.c|  7 ++-
>  drivers/staging/unisys/virtpci/virtpci.c| 11 ++-
>  drivers/staging/unisys/visorchipset/visorchipset_main.c |  4 ++--
>  4 files changed, 9 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/unisys/uislib/uisutils.c 
> b/drivers/staging/unisys/uislib/uisutils.c
> index 0f1bb73..6c58637 100644
> --- a/drivers/staging/unisys/uislib/uisutils.c
> +++ b/drivers/staging/unisys/uislib/uisutils.c
> @@ -96,9 +96,8 @@ uisctrl_register_req_handler(int type, void *fptr,
>   return 0;
>   }
>   if (chipset_DriverInfo)
> - BusDeviceInfo_Init(chipset_DriverInfo,
> -"chipset", "uislib",
> -VERSION, NULL, __DATE__, __TIME__);
> + BusDeviceInfo_Init(chipset_DriverInfo, "chipset", "uislib",
> +VERSION, NULL, NULL, NULL);

Why not change the function to not need these last 2 values at all?

>  
>   return 1;
>  }
> @@ -151,8 +150,7 @@ Away:
>   if (chipset_DriverInfo)
>   BusDeviceInfo_Init(chipset_DriverInfo,
>  "chipset", "uislib",
> -VERSION, NULL,
> -__DATE__, __TIME__);
> +VERSION, NULL, NULL, NULL);
>   } else
>   LOGERR("failed to register type %pUL.\n", &switchTypeGuid);
>  
> diff --git a/drivers/staging/unisys/virthba/virthba.c 
> b/drivers/staging/unisys/virthba/virthba.c
> index 5c5aa70..e58f3b8 100644
> --- a/drivers/staging/unisys/virthba/virthba.c
> +++ b/drivers/staging/unisys/virthba/virthba.c
> @@ -139,8 +139,8 @@ static struct virtpci_driver virthba_driver = {
>   .name = "uisvirthba",
>   .version = VERSION,
>   .vertag = NULL,
> - .build_date = __DATE__,
> - .build_time = __TIME__,
> + .build_date = NULL,
> + .build_time = NULL,

Just remove these fields entirely, why set them to NULL, they aren't
needed at all.

>   .id_table = virthba_id_table,
>   .probe = virthba_probe,
>   .remove = virthba_remove,
> @@ -1413,9 +1413,6 @@ info_proc_read(struct file *file, char __user *buf, 
> size_t len, loff_t *offset)
>   length += sprintf(vbuf + length, "\nvirthba result queue poll 
> wait:%d usecs.\n",
> rsltq_wait_usecs);
>  
> - length += sprintf(vbuf + length,
> -   "\nModule build: Date:%s Time:%s\n",
> -   __DATE__, __TIME__);
>   length += sprintf(vbuf + length, "\ninterrupts_rcvd = %llu, 
> interrupts_disabled = %llu\n",
> virthbainfo->interrupts_rcvd,
> virthbainfo->interrupts_disabled);

Why not just delete this proc file entirely?  You'll have to do that
eventually anyway :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Patch v3 2/4] Staging: unisys: Fix sparse warnings in uislib

2014-06-25 Thread Greg KH 
On Wed, Jun 25, 2014 at 02:01:03PM -0500, Ken Cox wrote:
> 
> On 06/17/2014 06:01 PM, Greg KH wrote:
> >On Thu, Jun 05, 2014 at 01:56:16PM -0500, Ken Cox wrote:
> >>Added I/O version for the function ultra_vbus_init_channel() to get rid
> >>of noderef sparse warnings when accessing I/O space.
> >>
> >>Signed-off-by: Ken Cox 
> >>---
> >>  .../common-spar/include/channels/vbuschannel.h | 40 
> >> --
> >>  drivers/staging/unisys/uislib/uislib.c |  2 +-
> >>  2 files changed, 38 insertions(+), 4 deletions(-)
> >>
> >>diff --git 
> >>a/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h 
> >>b/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
> >>index 000182c..af5a1ff 100644
> >>--- a/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
> >>+++ b/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
> >>@@ -95,12 +95,46 @@ typedef struct _ULTRA_VBUS_CHANNEL_PROTOCOL {
> >>  #define VBUS_CH_SIZE(MAXDEVICES) COVER(VBUS_CH_SIZE_EXACT(MAXDEVICES), 
> >> 4096)
> >>  static inline void
> >>-ultra_vbus_init_channel(ULTRA_VBUS_CHANNEL_PROTOCOL __iomem *x,
> >>-   int bytesAllocated)
> >>+ultra_vbus_init_channel(ULTRA_VBUS_CHANNEL_PROTOCOL *x,
> >>+   int bytes)
> >>  {
> >>/* Please note that the memory at  does NOT necessarily have space
> >>* for DevInfo structs allocated at the end, which is why we do NOT use
> >>-   *  to clear. */
> >>+   *  to clear. */
> >>+   memset(x, 0, sizeof(ULTRA_VBUS_CHANNEL_PROTOCOL));
> >>+   if (bytes < (int) sizeof(ULTRA_VBUS_CHANNEL_PROTOCOL))
> >>+   return;
> >>+
> >>+   x->ChannelHeader.VersionId = ULTRA_VBUS_CHANNEL_PROTOCOL_VERSIONID;
> >>+   x->ChannelHeader.Signature = ULTRA_VBUS_CHANNEL_PROTOCOL_SIGNATURE;
> >>+   x->ChannelHeader.SrvState = CHANNELSRV_READY;
> >>+   x->ChannelHeader.HeaderSize = sizeof(x->ChannelHeader);
> >>+   x->ChannelHeader.Size = bytes;
> >>+   memcpy(&x->ChannelHeader.Type, &UltraVbusChannelProtocolGuid,
> >>+   sizeof(x->ChannelHeader.Type));
> >>+   memcpy(&x->ChannelHeader.ZoneGuid, &NULL_UUID_LE, sizeof(uuid_le));
> >>+   x->HdrInfo.structBytes = sizeof(ULTRA_VBUS_HEADERINFO);
> >>+   x->HdrInfo.chpInfoByteOffset = sizeof(ULTRA_VBUS_HEADERINFO);
> >>+   x->HdrInfo.busInfoByteOffset += sizeof(ULTRA_VBUS_DEVICEINFO);
> >>+   x->HdrInfo.devInfoByteOffset += sizeof(ULTRA_VBUS_DEVICEINFO);
> >>+   x->HdrInfo.deviceInfoStructBytes = sizeof(ULTRA_VBUS_DEVICEINFO);
> >>+   bytes -= (sizeof(ULTRA_CHANNEL_PROTOCOL) +
> >>+ x->HdrInfo.devInfoByteOffset);
> >>+   x->HdrInfo.devInfoCount = bytes / x->HdrInfo.deviceInfoStructBytes;
> >>+}
> >That's a _huge_ inline function, why is it inline?  Shouldn't it just be
> >a "real" function instead?
> >
> >And given that you are duplicating most of the logic in
> >ULTRA_VBUS_init_channel(), isn't there some other way to share the logic
> >here?  Hm, no, I see why you did this, that's crazy.  The same logic to
> >write to a structure or a iomemory-based structure?  Something feels
> >really wrong here with what you are doing.  It's as if you init the
> >channel, then write it all out to memory, right?
> >
> >No, wait, no one calls this function ever now.  Why is it even needed?
> Originally, this function was here in preparation for an additional driver
> that has not been submitted.  After thinking about your comments and
> reviewing the code, I can make some changes to the calling functions and
> remove both versions of the function completely.

Sounds great.  Never add code to the kernel for "drivers that have not
been submitted", that's not ok as it's not how the kernel is developed.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic

2014-06-25 Thread Greg KH 
On Tue, Jun 24, 2014 at 09:44:14PM +, Dexuan Cui wrote:
> >On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote:
> >> Currently the VSC has no chance to notify the VSP of the dirty rectangle 
> >> on VM
> >> panic because the notification work is done in a workqueue, and in panic() 
> >> the
> >> kernel typically ends up in an infinite loop, and a typical kernel config 
> >> has
> >> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context 
> >> switch
> >> can't happen in panic() and the workqueue won't have a chance to run. As a
> >> result, the VM Connection window can't refresh until it's closed and we
> >> re-connect to the VM.
> >> 
> >> We can register a handler on panic_notifier_list: the handler can notify
> >> the VSC and switch the framebuffer driver to a "synchronous mode", meaning
> >> the VSC flushes any future framebuffer change to the VSP immediately.
> >> 
> >> MS-TFS: 157532
> 
> > What is this line for?
> 
> Hi Greg,
> This line is for our internal bug repository.
> We have an automated system to correlate bugs with fixes so that our test
> team knows when a bug fix has been accepted upstream and they need to
> write a new test case for it. 
> 
> The MS-TFS line has appeared in the commit description for a while if you
> search for it in 'git log'  of linux-next.
> 
> Please let us know if you have further comments.

Please don't add marker lines like this that provide no relevancy to
anyone else.  I don't allow gerrit ids for the same reason.  If you want
to refer to a public bug tracker, that's great, otherwise, don't
include it.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations

2014-06-25 Thread Joe Perches 
On Thu, 2014-06-26 at 09:55 +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: Missing a blank line after declarations

This time you've got the right subject, and right type of content,
but unfortunately, the content is wrapped and can't be applied.

Please read Documentation/email-clients.txt
and resubmit.

> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> b/drivers/staging/wlan-ng/hfa384x_usb.c
> index 98343ff7..07cee56 100644
> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
> @@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
> case -EPIPE:
> {
> hfa384x_t *hw = wlandev->priv;
> +
> netdev_warn(hw->wlandev->netdev,
> "%s tx pipe stalled:
> requesting reset\n",
> wlandev->netdev->name);
> --


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations

2014-06-25 Thread Cheng-Wei Lee 
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: Missing a blank line after declarations

Signed-off-by: Quentin Lee 
---
 drivers/staging/wlan-ng/hfa384x_usb.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 98343ff7..07cee56 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
case -EPIPE:
{
hfa384x_t *hw = wlandev->priv;
+
netdev_warn(hw->wlandev->netdev,
"%s tx pipe stalled:
requesting reset\n",
wlandev->netdev->name);
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Cheng-Wei Lee 
Hi Joe,

Thanks for your kindly reply.
I'll submit patch again.

Many thanks,
Quentin

2014-06-26 8:09 GMT+08:00, Joe Perches :
> On Wed, 2014-06-25 at 23:35 +0800, Cheng-Wei Lee wrote:
>> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
>> WARNING: Missing a blank line after declarations
>
> Still has a mismatch between subject and code
>
>> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> []
>> @@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
>> *wlandev, struct sk_buff *skb)
>>  }
>>
>>  done:
>> -return;
>> +pr_debug("hfa384x_usbin_rx: done\n");
>
> I suggest you just leave the return,
>
> Any checkpatch suggestion this was needed was a false
> positive that should be resolved by this patch:
>
> http://article.gmane.org/gmane.linux.kernel/1728891
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic

2014-06-25 Thread Dexuan Cui 
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
can't happen in panic() and the workqueue won't have a chance to run. As a
result, the VM Connection window can't refresh until it's closed and we
re-connect to the VM.

We can register a handler on panic_notifier_list: the handler can notify
the VSC and switch the framebuffer driver to a "synchronous mode", meaning
the VSC flushes any future framebuffer change to the VSP immediately.
MS-TFS: 157532

Signed-off-by: Dexuan Cui 
Reviewed-by: Haiyang Zhang 
---
 drivers/video/fbdev/hyperv_fb.c | 58 ++---
 1 file changed, 55 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e23392e..291d171 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -226,11 +226,16 @@ struct hvfb_par {
u8 recv_buf[MAX_VMBUS_PKT_SIZE];
 };
 
+static struct fb_info *hvfb_info;
+
 static uint screen_width = HVFB_WIDTH;
 static uint screen_height = HVFB_HEIGHT;
 static uint screen_depth;
 static uint screen_fb_size;
 
+/* If true, the VSC notifies the VSP on every framebuffer change */
+static bool synchronous_fb;
+
 /* Send message to Hyper-V host */
 static inline int synthvid_send(struct hv_device *hdev,
struct synthvid_msg *msg)
@@ -532,6 +537,20 @@ static void hvfb_update_work(struct work_struct *w)
schedule_delayed_work(&par->dwork, HVFB_UPDATE_DELAY);
 }
 
+static int hvfb_on_panic(struct notifier_block *nb,
+   unsigned long e, void *p)
+{
+   if (hvfb_info)
+   synthvid_update(hvfb_info);
+
+   synchronous_fb = true;
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hvfb_panic_nb = {
+   .notifier_call = hvfb_on_panic,
+};
 
 /* Framebuffer operation handlers */
 
@@ -582,14 +601,41 @@ static int hvfb_blank(int blank, struct fb_info *info)
return 1;   /* get fb_blank to set the colormap to all black */
 }
 
+static void hvfb_cfb_fillrect(struct fb_info *p,
+   const struct fb_fillrect *rect)
+{
+   cfb_fillrect(p, rect);
+
+   if (unlikely(synchronous_fb))
+   synthvid_update(p);
+}
+
+static void hvfb_cfb_copyarea(struct fb_info *p,
+   const struct fb_copyarea *area)
+{
+   cfb_copyarea(p, area);
+
+   if (unlikely(synchronous_fb))
+   synthvid_update(p);
+}
+
+static void hvfb_cfb_imageblit(struct fb_info *p,
+   const struct fb_image *image)
+{
+   cfb_imageblit(p, image);
+
+   if (unlikely(synchronous_fb))
+   synthvid_update(p);
+}
+
 static struct fb_ops hvfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = hvfb_check_var,
.fb_set_par = hvfb_set_par,
.fb_setcolreg = hvfb_setcolreg,
-   .fb_fillrect = cfb_fillrect,
-   .fb_copyarea = cfb_copyarea,
-   .fb_imageblit = cfb_imageblit,
+   .fb_fillrect = hvfb_cfb_fillrect,
+   .fb_copyarea = hvfb_cfb_copyarea,
+   .fb_imageblit = hvfb_cfb_imageblit,
.fb_blank = hvfb_blank,
 };
 
@@ -801,6 +847,9 @@ static int hvfb_probe(struct hv_device *hdev,
 
par->fb_ready = true;
 
+   hvfb_info = info;
+   atomic_notifier_chain_register(&panic_notifier_list, &hvfb_panic_nb);
+
return 0;
 
 error:
@@ -820,6 +869,9 @@ static int hvfb_remove(struct hv_device *hdev)
struct fb_info *info = hv_get_drvdata(hdev);
struct hvfb_par *par = info->par;
 
+   atomic_notifier_chain_unregister(&panic_notifier_list, &hvfb_panic_nb);
+   hvfb_info = NULL;
+
par->update = false;
par->fb_ready = false;
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Joe Perches 
On Wed, 2014-06-25 at 23:35 +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: Missing a blank line after declarations

Still has a mismatch between subject and code

> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
[]
> @@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
> *wlandev, struct sk_buff *skb)
>   }
> 
>  done:
> - return;
> + pr_debug("hfa384x_usbin_rx: done\n");

I suggest you just leave the return,

Any checkpatch suggestion this was needed was a false
positive that should be resolved by this patch:

http://article.gmane.org/gmane.linux.kernel/1728891


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/22] Add and use pci_zalloc_consistent

2014-06-25 Thread John W. Linville 
On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> Adding the helper reduces object code size as well as overall
> source size line count.
> 
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
> 
> Done with a simple cocci script and some typing.
> 
> Joe Perches (22):

>   ipw2100: Use pci_zalloc_consistent
>   mwl8k: Use pci_zalloc_consistent
>   rtl818x: Use pci_zalloc_consistent
>   rtlwifi: Use pci_zalloc_consistent

Sure, fine by me.

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Patch v3 2/4] Staging: unisys: Fix sparse warnings in uislib

2014-06-25 Thread Ken Cox 


On 06/17/2014 06:01 PM, Greg KH wrote:

On Thu, Jun 05, 2014 at 01:56:16PM -0500, Ken Cox wrote:

Added I/O version for the function ultra_vbus_init_channel() to get rid
of noderef sparse warnings when accessing I/O space.

Signed-off-by: Ken Cox 
---
  .../common-spar/include/channels/vbuschannel.h | 40 --
  drivers/staging/unisys/uislib/uislib.c |  2 +-
  2 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h 
b/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
index 000182c..af5a1ff 100644
--- a/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
+++ b/drivers/staging/unisys/common-spar/include/channels/vbuschannel.h
@@ -95,12 +95,46 @@ typedef struct _ULTRA_VBUS_CHANNEL_PROTOCOL {
  #define VBUS_CH_SIZE(MAXDEVICES) COVER(VBUS_CH_SIZE_EXACT(MAXDEVICES), 4096)
  
  static inline void

-ultra_vbus_init_channel(ULTRA_VBUS_CHANNEL_PROTOCOL __iomem *x,
-   int bytesAllocated)
+ultra_vbus_init_channel(ULTRA_VBUS_CHANNEL_PROTOCOL *x,
+   int bytes)
  {
/* Please note that the memory at  does NOT necessarily have space
* for DevInfo structs allocated at the end, which is why we do NOT use
-   *  to clear. */
+   *  to clear. */
+   memset(x, 0, sizeof(ULTRA_VBUS_CHANNEL_PROTOCOL));
+   if (bytes < (int) sizeof(ULTRA_VBUS_CHANNEL_PROTOCOL))
+   return;
+
+   x->ChannelHeader.VersionId = ULTRA_VBUS_CHANNEL_PROTOCOL_VERSIONID;
+   x->ChannelHeader.Signature = ULTRA_VBUS_CHANNEL_PROTOCOL_SIGNATURE;
+   x->ChannelHeader.SrvState = CHANNELSRV_READY;
+   x->ChannelHeader.HeaderSize = sizeof(x->ChannelHeader);
+   x->ChannelHeader.Size = bytes;
+   memcpy(&x->ChannelHeader.Type, &UltraVbusChannelProtocolGuid,
+   sizeof(x->ChannelHeader.Type));
+   memcpy(&x->ChannelHeader.ZoneGuid, &NULL_UUID_LE, sizeof(uuid_le));
+   x->HdrInfo.structBytes = sizeof(ULTRA_VBUS_HEADERINFO);
+   x->HdrInfo.chpInfoByteOffset = sizeof(ULTRA_VBUS_HEADERINFO);
+   x->HdrInfo.busInfoByteOffset += sizeof(ULTRA_VBUS_DEVICEINFO);
+   x->HdrInfo.devInfoByteOffset += sizeof(ULTRA_VBUS_DEVICEINFO);
+   x->HdrInfo.deviceInfoStructBytes = sizeof(ULTRA_VBUS_DEVICEINFO);
+   bytes -= (sizeof(ULTRA_CHANNEL_PROTOCOL) +
+ x->HdrInfo.devInfoByteOffset);
+   x->HdrInfo.devInfoCount = bytes / x->HdrInfo.deviceInfoStructBytes;
+}

That's a _huge_ inline function, why is it inline?  Shouldn't it just be
a "real" function instead?

And given that you are duplicating most of the logic in
ULTRA_VBUS_init_channel(), isn't there some other way to share the logic
here?  Hm, no, I see why you did this, that's crazy.  The same logic to
write to a structure or a iomemory-based structure?  Something feels
really wrong here with what you are doing.  It's as if you init the
channel, then write it all out to memory, right?

No, wait, no one calls this function ever now.  Why is it even needed?
Originally, this function was here in preparation for an additional 
driver that has not been submitted.  After thinking about your comments 
and reviewing the code, I can make some changes to the calling functions 
and remove both versions of the function completely.


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Joe Perches 
On Wed, 2014-06-25 at 23:24 +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: void function return statements are not generally useful

subject/code mismatch.

> Signed-off-by: Quentin Lee 
> ---
>  drivers/staging/wlan-ng/hfa384x_usb.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> b/drivers/staging/wlan-ng/hfa384x_usb.c
> index 98343ff7..07cee56 100644
> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
> @@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
>   case -EPIPE:
>   {
>   hfa384x_t *hw = wlandev->priv;
> +
>   netdev_warn(hw->wlandev->netdev,
>   "%s tx pipe stalled: requesting 
> reset\n",
>   wlandev->netdev->name);



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/4] Staging: unisys Remove BROKEN from Kconfig to allow compilation

2014-06-25 Thread Ken Cox 
The unisys drivers now properly check to make sure they are running
on the s-Par platform before they will initialize.  This was fixed in
commit fcd0157ece so it is safe to allow the unisys drivers to be built.

This has been tested in the same qemu environment that originally
produced the panic and the kernel now runs as expected.

Reported-by: Fengguang Wu 
Reported-by: Sasha Levin 
Tested-by: Benjamin Romer 
Tested-by: Ken Cox 
Signed-off-by: Ken Cox 
---
 drivers/staging/unisys/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig
index 6bae2af..ac080c9 100644
--- a/drivers/staging/unisys/Kconfig
+++ b/drivers/staging/unisys/Kconfig
@@ -3,7 +3,7 @@
 #
 menuconfig UNISYSSPAR
bool "Unisys SPAR driver support"
-   depends on X86_64 && BROKEN
+   depends on X86_64
---help---
Support for the Unisys SPAR drivers
 
-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/4] Staging: unisys: remove references to __DATE__ and __TIME__

2014-06-25 Thread Ken Cox 
The use of __DATE__ and __TIME__ is no longer allowed in the kernel so this
commit removes those.  They were once useful when the drivers were being
built externally, but now that the drivers are in the kernel the use of the
macros is redundant since the kernel already has the same information
elsewhere.

In addition, using these macros breaks the build if using gcc 4.9.0

Reported-by: Greg Kroah-Hartman 
Signed-off-by: Ken Cox 
---
 drivers/staging/unisys/uislib/uisutils.c|  8 +++-
 drivers/staging/unisys/virthba/virthba.c|  7 ++-
 drivers/staging/unisys/virtpci/virtpci.c| 11 ++-
 drivers/staging/unisys/visorchipset/visorchipset_main.c |  4 ++--
 4 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/unisys/uislib/uisutils.c 
b/drivers/staging/unisys/uislib/uisutils.c
index 0f1bb73..6c58637 100644
--- a/drivers/staging/unisys/uislib/uisutils.c
+++ b/drivers/staging/unisys/uislib/uisutils.c
@@ -96,9 +96,8 @@ uisctrl_register_req_handler(int type, void *fptr,
return 0;
}
if (chipset_DriverInfo)
-   BusDeviceInfo_Init(chipset_DriverInfo,
-  "chipset", "uislib",
-  VERSION, NULL, __DATE__, __TIME__);
+   BusDeviceInfo_Init(chipset_DriverInfo, "chipset", "uislib",
+  VERSION, NULL, NULL, NULL);
 
return 1;
 }
@@ -151,8 +150,7 @@ Away:
if (chipset_DriverInfo)
BusDeviceInfo_Init(chipset_DriverInfo,
   "chipset", "uislib",
-  VERSION, NULL,
-  __DATE__, __TIME__);
+  VERSION, NULL, NULL, NULL);
} else
LOGERR("failed to register type %pUL.\n", &switchTypeGuid);
 
diff --git a/drivers/staging/unisys/virthba/virthba.c 
b/drivers/staging/unisys/virthba/virthba.c
index 5c5aa70..e58f3b8 100644
--- a/drivers/staging/unisys/virthba/virthba.c
+++ b/drivers/staging/unisys/virthba/virthba.c
@@ -139,8 +139,8 @@ static struct virtpci_driver virthba_driver = {
.name = "uisvirthba",
.version = VERSION,
.vertag = NULL,
-   .build_date = __DATE__,
-   .build_time = __TIME__,
+   .build_date = NULL,
+   .build_time = NULL,
.id_table = virthba_id_table,
.probe = virthba_probe,
.remove = virthba_remove,
@@ -1413,9 +1413,6 @@ info_proc_read(struct file *file, char __user *buf, 
size_t len, loff_t *offset)
length += sprintf(vbuf + length, "\nvirthba result queue poll 
wait:%d usecs.\n",
  rsltq_wait_usecs);
 
-   length += sprintf(vbuf + length,
- "\nModule build: Date:%s Time:%s\n",
- __DATE__, __TIME__);
length += sprintf(vbuf + length, "\ninterrupts_rcvd = %llu, 
interrupts_disabled = %llu\n",
  virthbainfo->interrupts_rcvd,
  virthbainfo->interrupts_disabled);
diff --git a/drivers/staging/unisys/virtpci/virtpci.c 
b/drivers/staging/unisys/virtpci/virtpci.c
index 71246fe..35df6cd 100644
--- a/drivers/staging/unisys/virtpci/virtpci.c
+++ b/drivers/staging/unisys/virtpci/virtpci.c
@@ -1480,10 +1480,6 @@ static ssize_t info_proc_read(struct file *file, char 
__user *buf,
}
read_unlock_irqrestore(&VpcidevListLock, flags);
 
-   length +=
-   sprintf(vbuf + length, "\nModule build: Date:%s Time:%s\n", 
__DATE__,
-   __TIME__);
-
length += sprintf(vbuf + length, "\n");
if (copy_to_user(buf, vbuf, length)) {
kfree(vbuf);
@@ -1686,8 +1682,6 @@ static int __init virtpci_mod_init(void)
if (!unisys_spar_platform)
return -ENODEV;
 
-   LOGINF("Module build: Date:%s Time:%s...\n", __DATE__, __TIME__);
-
POSTCODE_LINUX_2(VPCI_CREATE_ENTRY_PC, POSTCODE_SEVERITY_INFO);
 
ret = bus_register(&virtpci_bus_type);
@@ -1701,9 +1695,8 @@ static int __init virtpci_mod_init(void)
return ret;
}
DBGINF("bus_register successful\n");
-   BusDeviceInfo_Init(&Bus_DriverInfo,
-  "clientbus", "virtpci",
-  VERSION, NULL, __DATE__, __TIME__);
+   BusDeviceInfo_Init(&Bus_DriverInfo, "clientbus", "virtpci",
+  VERSION, NULL, NULL, NULL);
 
/* create a root bus used to parent all the virtpci buses. */
ret = device_register(&virtpci_rootbus_device);
diff --git a/drivers/staging/unisys/visorchipset/visorchipset_main.c 
b/drivers/staging/unisys/visorchipset/visorchipset_main.c
index 0a602b9..689e7d1 100644
--- a/drivers/staging/unisys/visorchipset/visorchipset_main.c
+++ b/drivers/staging/unisys/visor

[PATCH 3/4] Staging: unisys: Remove build_date and build_time from virtpci_driver structure

2014-06-25 Thread Ken Cox 
The drivers do not need to keep track of these fields since the same
information is present elsewhere in the kernel.

Signed-off-by: Ken Cox 
---
 drivers/staging/unisys/virthba/virthba.c | 2 --
 drivers/staging/unisys/virtpci/virtpci.h | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/staging/unisys/virthba/virthba.c 
b/drivers/staging/unisys/virthba/virthba.c
index e58f3b8..4d1347a 100644
--- a/drivers/staging/unisys/virthba/virthba.c
+++ b/drivers/staging/unisys/virthba/virthba.c
@@ -139,8 +139,6 @@ static struct virtpci_driver virthba_driver = {
.name = "uisvirthba",
.version = VERSION,
.vertag = NULL,
-   .build_date = NULL,
-   .build_time = NULL,
.id_table = virthba_id_table,
.probe = virthba_probe,
.remove = virthba_remove,
diff --git a/drivers/staging/unisys/virtpci/virtpci.h 
b/drivers/staging/unisys/virtpci/virtpci.h
index f7be17b..7539fcb 100644
--- a/drivers/staging/unisys/virtpci/virtpci.h
+++ b/drivers/staging/unisys/virtpci/virtpci.h
@@ -77,8 +77,6 @@ struct virtpci_driver {
const char *name;   /* the name of the driver in sysfs */
const char *version;
const char *vertag;
-   const char *build_date;
-   const char *build_time;
const struct pci_device_id *id_table;   /* must be non-NULL for probe
 * to be called */
int (*probe)(struct virtpci_dev *dev,
-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/4] Staging: unisys: Remove references to __DATE__ and __TIME__

2014-06-25 Thread Ken Cox 
This series removes all references to __DATE__ and __TIME__ from the
unisys drivers and also removes BROKEN from the Kconfig so the drivers
can be built.

PATCH 1: Gets rid of references to __DATE__ and __TIME__
PATCH 2: Removes buildDate and buildTime arguments from BusDeviceInfo_Init()
PATCH 3: Removes build_date and build_time from virtpci_driver structure
PATCH 4: Removes BROKEN from the Kconfig

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/4] Staging: unisys: remove buildDate and buildTime arguments from BusDeviceInfo_Init

2014-06-25 Thread Ken Cox 
The unisys drivers no longer need to record the build date and time since the
same info is already in the kernel elsewhere.

Signed-off-by: Ken Cox 
---
 drivers/staging/unisys/include/vbushelper.h | 8 +++-
 drivers/staging/unisys/uislib/uisutils.c| 7 +++
 drivers/staging/unisys/virtpci/virtpci.c| 5 ++---
 drivers/staging/unisys/visorchipset/visorchipset_main.c | 4 ++--
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/unisys/include/vbushelper.h 
b/drivers/staging/unisys/include/vbushelper.h
index 93e35f0..ed94375 100644
--- a/drivers/staging/unisys/include/vbushelper.h
+++ b/drivers/staging/unisys/include/vbushelper.h
@@ -28,8 +28,7 @@
 static inline void
 BusDeviceInfo_Init(ULTRA_VBUS_DEVICEINFO *pBusDeviceInfo,
   const char *deviceType, const char *driverName,
-  const char *ver, const char *verTag,
-  const char *buildDate, const char *buildTime)
+  const char *ver, const char *verTag)
 {
memset(pBusDeviceInfo, 0, sizeof(ULTRA_VBUS_DEVICEINFO));
snprintf(pBusDeviceInfo->devType, sizeof(pBusDeviceInfo->devType),
@@ -37,11 +36,10 @@ BusDeviceInfo_Init(ULTRA_VBUS_DEVICEINFO *pBusDeviceInfo,
snprintf(pBusDeviceInfo->drvName, sizeof(pBusDeviceInfo->drvName),
 "%s", (driverName) ? driverName : "unknownDriver");
snprintf(pBusDeviceInfo->infoStrings,
-sizeof(pBusDeviceInfo->infoStrings), "%s\t%s\t%s %s\t%s",
+sizeof(pBusDeviceInfo->infoStrings), "%s\t%s\t%s",
 (ver) ? ver : "unknownVer",
 (verTag) ? verTag : "unknownVerTag",
-(buildDate) ? buildDate : "noBuildDate",
-(buildTime) ? buildTime : "nobuildTime", TARGET_HOSTNAME);
+TARGET_HOSTNAME);
 }
 
 #endif
diff --git a/drivers/staging/unisys/uislib/uisutils.c 
b/drivers/staging/unisys/uislib/uisutils.c
index 6c58637..07e5535 100644
--- a/drivers/staging/unisys/uislib/uisutils.c
+++ b/drivers/staging/unisys/uislib/uisutils.c
@@ -97,7 +97,7 @@ uisctrl_register_req_handler(int type, void *fptr,
}
if (chipset_DriverInfo)
BusDeviceInfo_Init(chipset_DriverInfo, "chipset", "uislib",
-  VERSION, NULL, NULL, NULL);
+  VERSION, NULL);
 
return 1;
 }
@@ -148,9 +148,8 @@ uisctrl_register_req_handler_ex(uuid_le switchTypeGuid,
 Away:
if (rc) {
if (chipset_DriverInfo)
-   BusDeviceInfo_Init(chipset_DriverInfo,
-  "chipset", "uislib",
-  VERSION, NULL, NULL, NULL);
+   BusDeviceInfo_Init(chipset_DriverInfo, "chipset",
+  "uislib", VERSION, NULL);
} else
LOGERR("failed to register type %pUL.\n", &switchTypeGuid);
 
diff --git a/drivers/staging/unisys/virtpci/virtpci.c 
b/drivers/staging/unisys/virtpci/virtpci.c
index 35df6cd..5ab17e7 100644
--- a/drivers/staging/unisys/virtpci/virtpci.c
+++ b/drivers/staging/unisys/virtpci/virtpci.c
@@ -794,8 +794,7 @@ static void fix_vbus_devInfo(struct device *dev, int devNo, 
int devType,
BusDeviceInfo_Init(&devInfo, stype,
   virtpcidrv->name,
   virtpcidrv->version,
-  virtpcidrv->vertag,
-  virtpcidrv->build_date, virtpcidrv->build_time);
+  virtpcidrv->vertag);
write_vbus_devInfo(pChan, &devInfo, devNo);
 
/* Re-write bus+chipset info, because it is possible that this
@@ -1696,7 +1695,7 @@ static int __init virtpci_mod_init(void)
}
DBGINF("bus_register successful\n");
BusDeviceInfo_Init(&Bus_DriverInfo, "clientbus", "virtpci",
-  VERSION, NULL, NULL, NULL);
+  VERSION, NULL);
 
/* create a root bus used to parent all the virtpci buses. */
ret = device_register(&virtpci_rootbus_device);
diff --git a/drivers/staging/unisys/visorchipset/visorchipset_main.c 
b/drivers/staging/unisys/visorchipset/visorchipset_main.c
index 689e7d1..f897128 100644
--- a/drivers/staging/unisys/visorchipset/visorchipset_main.c
+++ b/drivers/staging/unisys/visorchipset/visorchipset_main.c
@@ -569,7 +569,7 @@ 
visorchipset_register_busdev_server(VISORCHIPSET_BUSDEV_NOTIFIERS *notifiers,
*responders = BusDev_Responders;
if (driverInfo)
BusDeviceInfo_Init(driverInfo, "chipset", "visorchipset",
-  VERSION, NULL, NULL, NULL);
+  VERSION, NULL);
 
UNLOCKSEM(&NotifierLock);
 }
@@ -593,7 +593,7 @@ 
visorchipset_register_busdev_client(VISORCHIPSET_BUSDEV_NOTIFIERS *notifiers,
*responders = BusDev_Responders;

Re: [PATCH 6/6] Staging: bcm: Lines shortened in download_ddr_settings()

2014-06-25 Thread josh 
On Wed, Jun 25, 2014 at 04:50:31PM +0200, Matthias Beyer wrote:
> On 23-06-2014 13:44:22, j...@joshtriplett.org wrote:
> > On Mon, Jun 23, 2014 at 11:42:33AM +0200, Matthias Beyer wrote:
> > > Signed-off-by: Matthias Beyer 
> > 
> > As with the previous line-wrapping patch, this doesn't seem like a net
> > improvement; the lines seem far more readable un-wrapped.
> 
> I don't know. Previous patches which were similar were added.
> Readability is really much opinion-based.
> 
> So should I rebase this patchset and remove the line-length patches?
> 
> Are there more opinions on this?

I'm not the arbiter of kernel formatting; it's up to Greg (as the
maintainer of the staging tree) if he accepts the patches or not.

However, I've submitted a patch to checkpatch that would silence this
warning by default when not running with --strict, which should
de-emphasize it in favor of other, more objectively clear cleanups.

> > >  drivers/staging/bcm/DDRInit.c | 31 +--
> > >  1 file changed, 21 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
> > > index 423bfd9..4564f40 100644
> > > --- a/drivers/staging/bcm/DDRInit.c
> > > +++ b/drivers/staging/bcm/DDRInit.c
> > > @@ -1159,7 +1159,8 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > > *Adapter)
> > >  {
> > >   struct bcm_ddr_setting *psDDRSetting = NULL;
> > >   ULONG RegCount = 0;
> > > - unsigned long ul_ddr_setting_load_addr = 
> > > DDR_DUMP_INTERNAL_DEVICE_MEMORY;
> > > + unsigned long ul_ddr_setting_load_addr =
> > > + DDR_DUMP_INTERNAL_DEVICE_MEMORY;
> > >   UINT value = 0;
> > >   int retval = STATUS_SUCCESS;
> > >   bool bOverrideSelfRefresh = false;
> > > @@ -1283,18 +1284,22 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > > *Adapter)
> > >   }
> > >   /* total number of Register that has to be dumped */
> > >   value = RegCount;
> > > - retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > > sizeof(value));
> > > + retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > > + sizeof(value));
> > >   if (retval) {
> > > - BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "%s:%d\n", 
> > > __func__, __LINE__);
> > > + BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > > + "%s:%d\n", __func__, __LINE__);
> > >  
> > >   return retval;
> > >   }
> > >   ul_ddr_setting_load_addr += sizeof(ULONG);
> > >   /* signature */
> > >   value = (0x1d1e0dd0);
> > > - retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > > sizeof(value));
> > > + retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > > + sizeof(value));
> > >   if (retval) {
> > > - BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "%s:%d\n", 
> > > __func__, __LINE__);
> > > + BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > > + "%s:%d\n", __func__, __LINE__);
> > >   return retval;
> > >   }
> > >  
> > > @@ -1303,17 +1308,23 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > > *Adapter)
> > >  
> > >   while (RegCount && !retval) {
> > >   value = psDDRSetting->ulRegAddress;
> > > - retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > > sizeof(value));
> > > + retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > > + sizeof(value));
> > >   ul_ddr_setting_load_addr += sizeof(ULONG);
> > >   if (!retval) {
> > > - if (bOverrideSelfRefresh && (psDDRSetting->ulRegAddress 
> > > == 0x0F007018))
> > > + if (bOverrideSelfRefresh
> > > + && (psDDRSetting->ulRegAddress
> > > + == 0x0F007018))
> > >   value = (psDDRSetting->ulRegValue | (1<<8));
> > >   else
> > >   value = psDDRSetting->ulRegValue;
> > >  
> > > - if (STATUS_SUCCESS != wrmalt(Adapter, 
> > > ul_ddr_setting_load_addr,
> > > - &value, sizeof(value))) {
> > > - BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, 
> > > "%s:%d\n", __func__, __LINE__);
> > > + if (STATUS_SUCCESS != wrmalt(Adapter,
> > > +  ul_ddr_setting_load_addr,
> > > +  &value,
> > > +  sizeof(value))) {
> > > + BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > > + "%s:%d\n", __func__, __LINE__);
> > >   break;
> > >   }
> > >   }
> > > -- 
> > > 2.0.0
> > > 
> 
> -- 
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
> 
> Proudly sent with mutt.
> Happily signed with gnupg.


__

Re: [PATCH 1/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Cheng-Wei Lee 
Dear all,

Thanks Joe's reminder. I've resent patch.

Sincerely,
Quentin

2014-06-25 23:28 GMT+08:00, Joe Perches :
> On Wed, 2014-06-25 at 23:24 +0800, Cheng-Wei Lee wrote:
>> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
>> WARNING: void function return statements are not generally useful
>
> subject/code mismatch.
>
>> Signed-off-by: Quentin Lee 
>> ---
>>  drivers/staging/wlan-ng/hfa384x_usb.c |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
>> b/drivers/staging/wlan-ng/hfa384x_usb.c
>> index 98343ff7..07cee56 100644
>> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
>> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
>> @@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb
>> *urb)
>>  case -EPIPE:
>>  {
>>  hfa384x_t *hw = wlandev->priv;
>> +
>>  netdev_warn(hw->wlandev->netdev,
>>  "%s tx pipe stalled: requesting 
>> reset\n",
>>  wlandev->netdev->name);
>
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Cheng-Wei Lee 
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: Missing a blank line after declarations

Signed-off-by: Quentin Lee 
---
 drivers/staging/wlan-ng/hfa384x_usb.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 07cee56..99e2f2d 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
*wlandev, struct sk_buff *skb)
}

 done:
-   return;
+   pr_debug("hfa384x_usbin_rx: done\n");
 }

 /*
@@ -3643,8 +3643,6 @@ static void hfa384x_int_rxmonitor(wlandevice_t *wlandev,

/* pass it back up */
prism2sta_ev_rx(wlandev, skb);
-
-   return;
 }

 /*
-- 
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations

2014-06-25 Thread Cheng-Wei Lee 
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: void function return statements are not generally useful

Signed-off-by: Quentin Lee 
---
 drivers/staging/wlan-ng/hfa384x_usb.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 98343ff7..07cee56 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
case -EPIPE:
{
hfa384x_t *hw = wlandev->priv;
+
netdev_warn(hw->wlandev->netdev,
"%s tx pipe stalled: requesting 
reset\n",
wlandev->netdev->name);
-- 
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations

2014-06-25 Thread Cheng-Wei Lee 
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: Missing a blank line after declarations

Signed-off-by: Quentin Lee 
---
 drivers/staging/wlan-ng/hfa384x_usb.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 07cee56..99e2f2d 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
*wlandev, struct sk_buff *skb)
}

 done:
-   return;
+   pr_debug("hfa384x_usbin_rx: done\n");
 }

 /*
@@ -3643,8 +3643,6 @@ static void hfa384x_int_rxmonitor(wlandevice_t *wlandev,

/* pass it back up */
prism2sta_ev_rx(wlandev, skb);
-
-   return;
 }

 /*
-- 
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function

2014-06-25 Thread Cheng-Wei Lee 
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: void function return statements are not generally useful

Signed-off-by: Quentin Lee 
---
 drivers/staging/wlan-ng/hfa384x_usb.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 98343ff7..07cee56 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
case -EPIPE:
{
hfa384x_t *hw = wlandev->priv;
+
netdev_warn(hw->wlandev->netdev,
"%s tx pipe stalled: requesting 
reset\n",
wlandev->netdev->name);
-- 
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 6/6] Staging: bcm: Lines shortened in download_ddr_settings()

2014-06-25 Thread Matthias Beyer 
On 23-06-2014 13:44:22, j...@joshtriplett.org wrote:
> On Mon, Jun 23, 2014 at 11:42:33AM +0200, Matthias Beyer wrote:
> > Signed-off-by: Matthias Beyer 
> 
> As with the previous line-wrapping patch, this doesn't seem like a net
> improvement; the lines seem far more readable un-wrapped.

I don't know. Previous patches which were similar were added.
Readability is really much opinion-based.

So should I rebase this patchset and remove the line-length patches?

Are there more opinions on this?

> 
> >  drivers/staging/bcm/DDRInit.c | 31 +--
> >  1 file changed, 21 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
> > index 423bfd9..4564f40 100644
> > --- a/drivers/staging/bcm/DDRInit.c
> > +++ b/drivers/staging/bcm/DDRInit.c
> > @@ -1159,7 +1159,8 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > *Adapter)
> >  {
> > struct bcm_ddr_setting *psDDRSetting = NULL;
> > ULONG RegCount = 0;
> > -   unsigned long ul_ddr_setting_load_addr = 
> > DDR_DUMP_INTERNAL_DEVICE_MEMORY;
> > +   unsigned long ul_ddr_setting_load_addr =
> > +   DDR_DUMP_INTERNAL_DEVICE_MEMORY;
> > UINT value = 0;
> > int retval = STATUS_SUCCESS;
> > bool bOverrideSelfRefresh = false;
> > @@ -1283,18 +1284,22 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > *Adapter)
> > }
> > /* total number of Register that has to be dumped */
> > value = RegCount;
> > -   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > sizeof(value));
> > +   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > +   sizeof(value));
> > if (retval) {
> > -   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "%s:%d\n", 
> > __func__, __LINE__);
> > +   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > +   "%s:%d\n", __func__, __LINE__);
> >  
> > return retval;
> > }
> > ul_ddr_setting_load_addr += sizeof(ULONG);
> > /* signature */
> > value = (0x1d1e0dd0);
> > -   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > sizeof(value));
> > +   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > +   sizeof(value));
> > if (retval) {
> > -   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "%s:%d\n", 
> > __func__, __LINE__);
> > +   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > +   "%s:%d\n", __func__, __LINE__);
> > return retval;
> > }
> >  
> > @@ -1303,17 +1308,23 @@ int download_ddr_settings(struct bcm_mini_adapter 
> > *Adapter)
> >  
> > while (RegCount && !retval) {
> > value = psDDRSetting->ulRegAddress;
> > -   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value, 
> > sizeof(value));
> > +   retval = wrmalt(Adapter, ul_ddr_setting_load_addr, &value,
> > +   sizeof(value));
> > ul_ddr_setting_load_addr += sizeof(ULONG);
> > if (!retval) {
> > -   if (bOverrideSelfRefresh && (psDDRSetting->ulRegAddress 
> > == 0x0F007018))
> > +   if (bOverrideSelfRefresh
> > +   && (psDDRSetting->ulRegAddress
> > +   == 0x0F007018))
> > value = (psDDRSetting->ulRegValue | (1<<8));
> > else
> > value = psDDRSetting->ulRegValue;
> >  
> > -   if (STATUS_SUCCESS != wrmalt(Adapter, 
> > ul_ddr_setting_load_addr,
> > -   &value, sizeof(value))) {
> > -   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, 
> > "%s:%d\n", __func__, __LINE__);
> > +   if (STATUS_SUCCESS != wrmalt(Adapter,
> > +ul_ddr_setting_load_addr,
> > +&value,
> > +sizeof(value))) {
> > +   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
> > +   "%s:%d\n", __func__, __LINE__);
> > break;
> > }
> > }
> > -- 
> > 2.0.0
> > 

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpqKs0Oapa3k.pgp
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: bcm: nvm.c: Cleaning up check unsigned is less than zero

2014-06-25 Thread Rickard Strandqvist 
Remove checking if a unsigned int is less than zero

This was found using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 drivers/staging/bcm/nvm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm/nvm.c b/drivers/staging/bcm/nvm.c
index 63be3be..0061968 100644
--- a/drivers/staging/bcm/nvm.c
+++ b/drivers/staging/bcm/nvm.c
@@ -3321,7 +3321,7 @@ int BcmSetActiveSection(struct bcm_mini_adapter *Adapter, 
enum bcm_flash2x_secti
 
SectImagePriority = ReadISOPriority(Adapter, 
HighestPriISO) + 1;
 
-   if ((SectImagePriority <= 0) && 
IsSectionWritable(Adapter, HighestPriISO)) {
+   if ((SectImagePriority == 0) && 
IsSectionWritable(Adapter, HighestPriISO)) {
/* This is a SPECIAL Case which will only 
happen if the current highest priority ISO has priority value = 0x7FFF.
 * We will write 1 to the current Highest 
priority ISO And then shall increase the priority of the requested ISO
 * by user
@@ -3381,7 +3381,7 @@ int BcmSetActiveSection(struct bcm_mini_adapter *Adapter, 
enum bcm_flash2x_secti
}
 
SectImagePriority = ReadDSDPriority(Adapter, 
HighestPriDSD) + 1;
-   if (SectImagePriority <= 0) {
+   if (SectImagePriority == 0) {
/* This is a SPECIAL Case which will only 
happen if the current highest priority DSD has priority value = 0x7FFF.
 * We will write 1 to the current Highest 
priority DSD And then shall increase the priority of the requested DSD
 * by user
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: r8192U_core.c: Cleaning up variable is set more than once

2014-06-25 Thread Rickard Strandqvist 
A struct member variable is set to the same value more than once

This was found using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 drivers/staging/rtl8192u/r8192U_core.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 24272c5..b2b4cd0 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2355,7 +2355,6 @@ static void rtl8192_init_priv_variable(struct net_device 
*dev)
 
priv->ieee80211->FwRWRF = 0;//we don't use FW read/write RF until 
stable firmware is available.
priv->ieee80211->current_network.beacon_interval = 
DEFAULT_BEACONINTERVAL;
-   priv->ieee80211->iw_mode = IW_MODE_INFRA;
priv->ieee80211->softmac_features  = IEEE_SOFTMAC_SCAN |
IEEE_SOFTMAC_ASSOCIATE | IEEE_SOFTMAC_PROBERQ |
IEEE_SOFTMAC_PROBERS | IEEE_SOFTMAC_TX_QUEUE |
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Anybody working on gdm72xx?

2014-06-25 Thread Michalis Pappas 
On 06/24/2014 08:12 AM, Ben Chan wrote:
> Thanks Kristina.  checkpatch reports 1 errors and 17 warnings on the
> current driver.
> 
> I guess I need to first submit patches to staging-next to address
> these issues, and then submit another patch to move it out of staging,
> right?
>

Hi everyone,

I've been working on a driver review for gdm72xx and I think there are some 
more issues to be fixed except from stuff reported by checkpatch.pl. Here's 
what I've come up with so far:

First of all, during a patch review, Dan Carpenter (cced) mentioned some 
issues. I quote his message:

--- 8< --- snip snip --- 8< ---

Also why is returning a u32?  Kernel style is int.  But this doesn't
return errors and the callers don't check so it should be void.  This
driver suffers from prefering u32 over int in many places.

...

In gdm_usb_send(), the "BUG_ON(len > TX_BUF_SIZE - padding - 1);" should
be proper error handling."

--- 8< --- snip snip --- 8< ---

Additionally, wm_ioctl.h defines its own netlink address. FWIK netlink 
addresses should be defined in uapi/linux/netlink.h and given the scarcity of 
netlink addresses, I think netlink_generic should be used instead. Please 
correct me if I'm wrong.

Now regarding some of the checkpatch errors:

> WARNING: unchecked sscanf return value
> #2662: FILE: drivers/net/wimax/gdm72xx/gdm_wimax.c:294:
> +   sscanf(e->dev->name, "wm%d", &idx);
> 

I know Ben has submitted a patch for this already, but from my understanding 
this check is not really needed. The value stored in e->dev>name is generated 
by __dev_alloc_name which does all the necessary checks for user supplied input 
etc, so it should be considered as a trusted value.

> ERROR: Macros with complex values should be enclosed in parenthesis
> #4429: FILE: drivers/net/wimax/gdm72xx/usb_ids.h:34:
> +#define USB_DEVICE_BOOTLOADER(vid, pid)\
> +   {USB_DEVICE((vid), ((pid)&BL_PID_MASK)|B_DOWNLOAD)},\
> +   {USB_DEVICE((vid), ((pid)&BL_PID_MASK)|B_DOWNLOAD|B_DIFF_DL_DRV)}

This a false positive indeed

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

2014-06-25 Thread Sascha Hauer 
On Wed, Jun 25, 2014 at 09:43:27AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> > On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > > +
> > >  /*
> > >   * Bitfield of Display Interface signal polarities.
> > >   */
> > > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > >   unsigned clksel_en:1;
> > >   unsigned clkidle_en:1;
> > >   unsigned data_pol:1;/* true = inverted */
> > > - unsigned clk_pol:1; /* true = rising edge */
> > > + unsigned clk_pol:1;
> > >   unsigned enable_pol:1;
> > >   unsigned Hsync_pol:1;   /* true = active high */
> > >   unsigned Vsync_pol:1;
> > 
> > ...can we rename the flags to more meaningful names instead?
> > 
> > unsigned clk_pol_rising_edge:1;
> > unsigned enable_pol_high:1;
> > unsigned hsync_active_high:1;
> > unsigned vsync_active_high:1;
> 
> Now look at patch 7, where these become tri-state:
> - don't change
> - rising edge/active high
> - falling edge/active low
> 
> So your suggestion is not a good idea.

Hm, you're right.

Still I think we should add a prefix to make the context of the flags
clear.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

2014-06-25 Thread Denis Carikli 

On 06/25/2014 06:48 AM, Sascha Hauer wrote:

+#define ENABLE_POL_LOW 0
+#define ENABLE_POL_HIGH1


Adding defines without a proper namespace (IPU_) outside a driver
private header file is not nice. Anyway, instead of adding the
defines ...
Fixed in "imx-drm: use defines for clock polarity settings" and in 
"imx-drm: Use drm_display_mode timings flags.".


Denis.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

2014-06-25 Thread Denis Carikli 

On 06/24/2014 05:06 PM, Russell King - ARM Linux wrote:
> It would be better if you separate the

binding documentation updates from the other functional changes too.

Fixed.

Denis.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v14 07/10] imx-drm: Use drm_display_mode timings flags.

2014-06-25 Thread Russell King - ARM Linux 
On Mon, Jun 16, 2014 at 12:11:21PM +0200, Denis Carikli wrote:
> The previous hardware behaviour was kept if the
> flags are not set.

I'd like to throw in a patch that I've been carrying for a bit now.
It conflicts with your patches, but I'm happy to fix that conflict
locally (and have been doing so for a while now.)

This is related to a slightly different issue - knowing which types
of bridges are bound to a particualar DI.  This matters in part for
selecting the clock routing - as things currently stand, the last
bridge to call imx_drm_panel_format*() gets its way with this.  With
this change, we can see which bridges are bound, and make the
appropriate decision.  At the moment, we are saved from things going
awry as we don't support cloning outputs.

The relevence to your patch set is that some bridges require clk_pol
to be configured appropriately - HDMI requires clk_pol = 0 in order to
work correctly (with the opposite edge, the image is noisy.)

While this approach only allows us to identify the types of bridges
connected to a DI rather than uniquely identifing the bridges themselves,
I think this is not only an improvement, but also a simplification of
the current code, and allows better decisions about things like clk_pol
to be made.

I'm sending it here because it is relevent to Denis' patch set - I will
also send it out separately if people want it separately, though that
will go to a reduced Cc list.

From: Russell King 
Subject: [PATCH] imx-drm: core: handling of DI clock flags to
 ipu_crtc_mode_set()

We do not need to track the state of the IPU DI's clock flags by having
each display bridge calling back into imx-drm-core, and then back out
into ipuv3-crtc.c.

ipuv3-crtc can instead just scan the list of encoders to retrieve their
type, and build up a picture of which types of encoders are attached.
We can then use this information to configure the IPU DI clocking mode
without any uncertainty - if we have multiple bridges connected to the
same DI, if one of them requires a synchronous DI clock, that's what we
must use.

Signed-off-by: Russell King 
---
 drivers/staging/imx-drm/imx-drm-core.c |  3 +--
 drivers/staging/imx-drm/imx-drm.h  |  2 +-
 drivers/staging/imx-drm/ipuv3-crtc.c   | 40 +++---
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index def8280d7ee6..6d9376c760ad 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -115,8 +115,7 @@ int imx_drm_panel_format_pins(struct drm_encoder *encoder,
helper = &imx_crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return helper->set_interface_pix_fmt(encoder->crtc,
-   encoder->encoder_type, interface_pix_fmt,
-   hsync_pin, vsync_pin);
+   interface_pix_fmt, hsync_pin, vsync_pin);
return 0;
 }
 EXPORT_SYMBOL_GPL(imx_drm_panel_format_pins);
diff --git a/drivers/staging/imx-drm/imx-drm.h 
b/drivers/staging/imx-drm/imx-drm.h
index 7453ae00c412..3c559ccd6af0 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -17,7 +17,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
 struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
-   int (*set_interface_pix_fmt)(struct drm_crtc *crtc, u32 encoder_type,
+   int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
u32 pix_fmt, int hsync_pin, int vsync_pin);
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 7fec438d8c54..af09032aedb0 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -51,7 +51,6 @@ struct ipu_crtc {
struct drm_framebuffer  *newfb;
int irq;
u32 interface_pix_fmt;
-   unsigned long   di_clkflags;
int di_hsync_pin;
int di_vsync_pin;
 };
@@ -146,10 +145,13 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
   int x, int y,
   struct drm_framebuffer *old_fb)
 {
+   struct drm_device *dev = crtc->dev;
+   struct drm_encoder *encoder;
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
-   int ret;
struct ipu_di_signal_cfg sig_cfg = {};
+   unsigned long encoder_types = 0;
u32 out_pixel_fmt;
+   int ret;
 
dev_dbg(ipu_crtc->dev, "%s: mode->hdisplay: %d\n", __func__,
mode->hdisplay);
@@ -165,6 +167,24 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flag

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

2014-06-25 Thread Russell King - ARM Linux 
On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > +
> >  /*
> >   * Bitfield of Display Interface signal polarities.
> >   */
> > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > unsigned clksel_en:1;
> > unsigned clkidle_en:1;
> > unsigned data_pol:1;/* true = inverted */
> > -   unsigned clk_pol:1; /* true = rising edge */
> > +   unsigned clk_pol:1;
> > unsigned enable_pol:1;
> > unsigned Hsync_pol:1;   /* true = active high */
> > unsigned Vsync_pol:1;
> 
> ...can we rename the flags to more meaningful names instead?
> 
>   unsigned clk_pol_rising_edge:1;
>   unsigned enable_pol_high:1;
>   unsigned hsync_active_high:1;
>   unsigned vsync_active_high:1;

Now look at patch 7, where these become tri-state:
- don't change
- rising edge/active high
- falling edge/active low

So your suggestion is not a good idea.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

2014-06-25 Thread Denis Carikli 

On 06/25/2014 12:04 AM, Thierry Reding wrote:

because on this very simple display board, we only have DVI LVDS signals
without the I2C to detect the display.


That's unfortunate. In that case perhaps a better approach would be to
add a video timings node to the device that provides the DVI output?

I've just done that.

Should I resend now? The goal is to avoid as much as possible extra 
versions.


Also, as I said before in a response to "[PATCH v14 09/10] ARM: dts: 
mbimx51sd: Add display support.", the LCD regulator was inverted, it 
worked while inverted because of a bug which is now fixed by:

"imx-drm: parallel-display: Fix DPMS default state."

Right now, I don't have any other changes for this serie beside a simple 
rebase of "dts: imx5*, imx6*: correct display-timings rebased".


Denis.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel