Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it

[Greg KH]

On Tue, Aug 29, 2017 at 11:32:58PM +0200, Ondrej Zary wrote:
> On Tuesday 29 August 2017 01:42:08 David Miller wrote:
> > From: Greg Kroah-Hartman 
> > Date: Sun, 27 Aug 2017 17:03:30 +0200
> >
> > > The IRDA code has long been obsolete and broken.  So, to keep people
> > > from trying to use it, and to prevent people from having to maintain it,
> > > let's move it to drivers/staging/ so that we can delete it entirely from
> > > the kernel in a few releases.
> >
> > No objection, I'll apply this to net-next, thanks Greg.
> 
> IRDA works fine in Debian 9 (kernel 4.9) and I use it for simple file 
> transfer. Hope I'm not the only one...
> 
> # irattach /dev/ttyS0 -d tekram -s
> # irdadump
> 21:28:52.830350 xid:cmd aed8eb79 >  S=6 s=0 (14)
> 21:28:52.922368 xid:cmd aed8eb79 >  S=6 s=1 (14)
> 21:28:53.014350 xid:cmd aed8eb79 >  S=6 s=2 (14)
> 21:28:53.106338 xid:cmd aed8eb79 >  S=6 s=3 (14)
> 21:28:53.190276 xid:rsp aed8eb79 < 35d1 S=6 s=3 Nokia 6230i hint=b125 [ 
> PnP Modem Fax Telephony IrCOMM IrOBEX ] (28)
> 21:28:53.198384 xid:cmd aed8eb79 >  S=6 s=4 (14)
> 21:28:53.290382 xid:cmd aed8eb79 >  S=6 s=5 (14)
> 21:28:53.382341 xid:cmd aed8eb79 >  S=6 s=* pentium hint=0400 [ 
> Computer ] (23)
> ^C
> 8 packets received by filter
> 
> $ obexftp -i -l MMC
> Connecting..\done
> Receiving "MMC".../
>   [  ]>
> 
> 
>  user-perm="RWD"/>
>  user-perm="RWD"/>
>  user-perm="RWD"/>
> 
> $ obexftp -i -c MMC -g Image004.jpg
> Connecting..\done
> Sending "MMC"...|done
> Receiving "Image004.jpg"...-done
> Disconnecting..\done

Odd, and is this just a ir device connected to a "real" serial port, or
a specific IRDA device?

thanks,

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

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

[Greg Kroah-Hartman]

On Wed, Aug 30, 2017 at 12:46:38PM -0700, Sherry Yang wrote:
> On Tue, Aug 29, 2017 at 11:07 PM, Greg Kroah-Hartman
>  wrote:
> > On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote:
> >> Use helper functions buffer_next and buffer_prev instead
> >> of list_entry to get the next and previous buffers.
> >>
> >> Signed-off-by: Sherry Yang 
> >> ---
> >>  drivers/android/binder_alloc.c | 24 +++-
> >>  1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > What changed from the previous version?
> 
> This specific patch didn't change. The change is only in [patch v3
> 3/6] (crash fix) and in [patch v3 6/6] (new patch that add stats).

I need to know that :)

> > Always put the changes below the --- line.  Like the documentation says
> > to do so.
> 
> Do you mean I should use --annotate to git send-email to specify what
> has changed across versions for each patch? I used --compose and put
> what changed from v2 to v3 in the introductory message [patch 0/6].

I never got a patch 0/6 here, and honestly, almost always ignore them as
patches should be self-obvious :)

> > Also, don't I already have these patches in my tree?  Do you want me to
> > revert the existing ones and use the new ones, or what about a fixup
> > patch for any differences?
> 
> I got a message saying a test failed on [patch 3/5]. I resubmitted the
> entire thread because I wasn't sure if you would drop the failing
> patch set. If the entire failing patch set is dropped, then v3 can be
> used as a replacement.

Do you want me to revert all of these?  I can not "drop" them as my tree
can not rebase.  If it's just a simple fix, I'll gladly take that
instead.

> If you prefer a fixup patch, I can post another patch set (the crash
> fix and the new patch) on top of what you already applied, but it
> might be easier to do what's described in the previous paragraph (drop
> v2 and apply v3).

Ok, exactly what git commit ids should I revert from the tree?  But
really, a fix would be easier at this point :)

thanks,

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

[PATCH v3] staging: ks7010: Fix coding style and remove checkpatch.pl warnings.

[Jonathan Whitaker]

Removed printk statements for debugging. The same information can be
acquired via ftrace, so these print statements are uneccessary.

Signed-off-by: Jonathan Whitaker 

---
Changes in v2:
  - Wrapped the changelog text to 72 columns.
  - Fixed the commit subject to be more clear.

Changes in v3:
  - Removed the printk statements altogether. This information is available
via ftrace.
  - Updated commit message.
---
 drivers/staging/ks7010/ks7010_sdio.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index 9b28ee1..8cfdff1 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -834,8 +834,6 @@ static int ks7010_sdio_probe(struct sdio_func *func,
unsigned char byte;
int ret;
 
-   DPRINTK(5, "ks7010_sdio_probe()\n");
-
priv = NULL;
netdev = NULL;
 
@@ -1008,8 +1006,6 @@ static void ks7010_sdio_remove(struct sdio_func *func)
struct ks_sdio_card *card;
struct ks_wlan_private *priv;
 
-   DPRINTK(1, "ks7010_sdio_remove()\n");
-
card = sdio_get_drvdata(func);
 
if (!card)
-- 
2.7.4

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

RE: [PATCH] storvsc: fix memory leak on ring buffer busy

[Long Li]

> Long,
> 
> >> Which kernel version is this patch aimed at?
> >
> > Martin, thanks for pointing this out. This should also go to stable
> > trees.
> 
> The reason I asked is that it didn't apply to neither fixes, nor for-next.
> 
> I applied it to 4.13/scsi-fixes by hand and added a stable tag.

Thank you. I'm sorry I misunderstood your question. I just realized I was 
working on an experimental branch. Sorry about that.

> 
> --
> Martin K. PetersenOracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] storvsc: fix memory leak on ring buffer busy

[Martin K. Petersen]

Long,

>> Which kernel version is this patch aimed at?
>
> Martin, thanks for pointing this out. This should also go to stable
> trees.

The reason I asked is that it didn't apply to neither fixes, nor
for-next.

I applied it to 4.13/scsi-fixes by hand and added a stable tag.

-- 
Martin K. Petersen  Oracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared with user space

[Todd Kjos]

I just went back through it -- turns out my email bounced back from
linux-ker...@vger.kernel.org (reason was "may contain a virus"). Sorry
I didn't notice that and resend.

On Wed, Aug 30, 2017 at 1:20 PM, Dan Carpenter  wrote:
> On Wed, Aug 30, 2017 at 01:04:31PM -0700, Arve Hjønnevåg wrote:
>> On Wed, Aug 30, 2017 at 2:29 AM, Dan Carpenter  
>> wrote:
>> > On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote:
>> >> Binder driver allocates buffer meta data in a region that is mapped
>> >> in user space. These meta data contain pointers in the kernel.
>> >>
>> >> This patch allocates buffer meta data on the kernel heap that is
>> >> not mapped in user space, and uses a pointer to refer to the data mapped.
>> >>
>> >> Also move alloc->buffers initialization from mmap to init since it's
>> >> now used even when mmap failed or was not called.
>> >>
>> >> Signed-off-by: Sherry Yang 
>> >> ---
>> >
>> > The difference between v2 and v3 is that we've shifted some
>> > initialization around to fix the crashing bug that kbuild found.  You
>> > should not that difference here under the --- cut off.
>> >
>> >>  drivers/android/binder_alloc.c  | 146 
>> >> +++-
>> >>  drivers/android/binder_alloc.h  |   2 +-
>> >>  drivers/android/binder_alloc_selftest.c |  11 ++-
>> >>  3 files changed, 91 insertions(+), 68 deletions(-)
>> >
>> > But really we still need to have some answers or discussion about the
>> > questions that Greg and I raised.  Greg asked if the other Android devs
>> > had Acked this.  Please ping Arve to Ack this.
>> >
>> tk...@google.com replied and ack'ed v2. The changes have been reviewed
>> on android-review.googlesource.com. Do you want and ack or review tag
>> included in the patchset or do you want separate ack emails on each
>> patchset (or on each patch)?
>
> Just acking it once is fine.  I don't see that email from Todd in my
> inbox and can't find it on the web archive either...  Something must
> have gone wrong but I don't know what.
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/14] vme: tsi148: Improve 17 size determinations

[SF Markus Elfring]

 @@ -2363,5 +2364,5 @@ static int tsi148_probe(struct pci_dev *pdev, const 
 struct pci_device_id *id)
  master_num--;

  tsi148_device->flush_image =
 -kmalloc(sizeof(struct vme_master_resource), 
 GFP_KERNEL);
 +kmalloc(sizeof(*tsi148_device->flush_image), 
 GFP_KERNEL);
>>>
>>> This line is now a tiny bit too long
>>
>> Can you eventually tolerate a line length of 81 characters at such a source 
>> code place?
>>
> 
> I think there's some irony here. On the one hand you are submitting
> patches that correct coding style issues, on the other you are asking
> whether we can ignore the coding style...

I test somehow how strict you would like to handle the length limit there.

I imagine that the affected source code formatting could also become different
if the involved variable name would be shorter.


>> * It seems that you would not like to perform such a tweak yourself.
> 
> To be honest, it is quicker and easier in this instance to do just that.

Interesting …


> So that's now done.

Thanks that you picked some of my ideas up.


> Patches now in my testing branch:
> 
> https://gitlab.collabora.com/martyn/linux/commits/vme-testing

I am curious on how the shown change possibilities will evolve from
this repository.


>> * Do you expect a resend for the complete patch series?
>>
> 
> Unless the maintainer has commented that they have accepted patches x,
> y and z, then sending the entire series again is generally the right
> thing to do.

Would you like to respond further to Greg's comments (from 2017-08-26)
for this patch series?

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

Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared with user space

[Dan Carpenter]

On Wed, Aug 30, 2017 at 01:04:31PM -0700, Arve Hjønnevåg wrote:
> On Wed, Aug 30, 2017 at 2:29 AM, Dan Carpenter  
> wrote:
> > On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote:
> >> Binder driver allocates buffer meta data in a region that is mapped
> >> in user space. These meta data contain pointers in the kernel.
> >>
> >> This patch allocates buffer meta data on the kernel heap that is
> >> not mapped in user space, and uses a pointer to refer to the data mapped.
> >>
> >> Also move alloc->buffers initialization from mmap to init since it's
> >> now used even when mmap failed or was not called.
> >>
> >> Signed-off-by: Sherry Yang 
> >> ---
> >
> > The difference between v2 and v3 is that we've shifted some
> > initialization around to fix the crashing bug that kbuild found.  You
> > should not that difference here under the --- cut off.
> >
> >>  drivers/android/binder_alloc.c  | 146 
> >> +++-
> >>  drivers/android/binder_alloc.h  |   2 +-
> >>  drivers/android/binder_alloc_selftest.c |  11 ++-
> >>  3 files changed, 91 insertions(+), 68 deletions(-)
> >
> > But really we still need to have some answers or discussion about the
> > questions that Greg and I raised.  Greg asked if the other Android devs
> > had Acked this.  Please ping Arve to Ack this.
> >
> tk...@google.com replied and ack'ed v2. The changes have been reviewed
> on android-review.googlesource.com. Do you want and ack or review tag
> included in the patchset or do you want separate ack emails on each
> patchset (or on each patch)?

Just acking it once is fine.  I don't see that email from Todd in my
inbox and can't find it on the web archive either...  Something must
have gone wrong but I don't know what.

regards,
dan carpenter

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

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

[Dan Carpenter]

On Wed, Aug 30, 2017 at 12:46:38PM -0700, Sherry Yang wrote:
> I used --compose and put what changed from v2 to v3 in the
> introductory message [patch 0/6].

Hm...  I never got [patch 0/6] (I'm on de...@driverdev.osuosl.org).

regards,
dan carpenter

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

Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared with user space

[Arve Hjønnevåg]

On Wed, Aug 30, 2017 at 2:29 AM, Dan Carpenter  wrote:
> On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote:
>> Binder driver allocates buffer meta data in a region that is mapped
>> in user space. These meta data contain pointers in the kernel.
>>
>> This patch allocates buffer meta data on the kernel heap that is
>> not mapped in user space, and uses a pointer to refer to the data mapped.
>>
>> Also move alloc->buffers initialization from mmap to init since it's
>> now used even when mmap failed or was not called.
>>
>> Signed-off-by: Sherry Yang 
>> ---
>
> The difference between v2 and v3 is that we've shifted some
> initialization around to fix the crashing bug that kbuild found.  You
> should not that difference here under the --- cut off.
>
>>  drivers/android/binder_alloc.c  | 146 
>> +++-
>>  drivers/android/binder_alloc.h  |   2 +-
>>  drivers/android/binder_alloc_selftest.c |  11 ++-
>>  3 files changed, 91 insertions(+), 68 deletions(-)
>
> But really we still need to have some answers or discussion about the
> questions that Greg and I raised.  Greg asked if the other Android devs
> had Acked this.  Please ping Arve to Ack this.
>
tk...@google.com replied and ack'ed v2. The changes have been reviewed
on android-review.googlesource.com. Do you want and ack or review tag
included in the patchset or do you want separate ack emails on each
patchset (or on each patch)?

> I was curious about the security impact or why we were writing this
> patch 3/6.  It seems we are fixing an information disclosure bug.  Or is
> it something worse than that?  Or have I misunderstood entirely.
>
> We probably original put the buffers in userspace for accounting reasons
> so we could kill programs that used too much RAM.  This patch doesn't
> create a problem with that hopefully?  We're just moving the metadata to
> kernel space?
>

The buffer headers have never been used by user-space. They are
readable by user-space because the content after the header has to be
readable from user-space (and only whole pages can be mapped). It was
simpler to have the header in the same shared region as well. At the
time this code was written the content of kernel pointers where not
considered secret and available elsewhere anyway (e.g. kernel log,
/proc/kallsyms).

-- 
Arve Hjønnevåg
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/14] vme: tsi148: Improve 17 size determinations

[Martyn Welch]

On 26 August 2017 at 08:00, SF Markus Elfring
 wrote:
>>> @@ -2363,5 +2364,5 @@ static int tsi148_probe(struct pci_dev *pdev, const 
>>> struct pci_device_id *id)
>>>  master_num--;
>>>
>>>  tsi148_device->flush_image =
>>> -kmalloc(sizeof(struct vme_master_resource), 
>>> GFP_KERNEL);
>>> +kmalloc(sizeof(*tsi148_device->flush_image), 
>>> GFP_KERNEL);
>>
>> This line is now a tiny bit too long
>
> Can you eventually tolerate a line length of 81 characters at such a source 
> code place?
>

I think there's some irony here. On the one hand you are submitting
patches that correct coding style issues, on the other you are asking
whether we can ignore the coding style...

>
>> and needs to be broken over two lines.
>
> How would like to achieve this?
>
> * It seems that you would not like to perform such a tweak yourself.
>

To be honest, it is quicker and easier in this instance to do just
that. So that's now done.

Patches now in my testing branch:

https://gitlab.collabora.com/martyn/linux/commits/vme-testing

For future reference:

> * Do you expect a resend for the complete patch series?
>

Unless the maintainer has commented that they have accepted patches x,
y and z, then sending the entire series again is generally the right
thing to do.

> * Will it be sufficient to send another patch only for the requested 
> reformatting
>   of a single line?
>

No, unless the patches have been accepted as-is.

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

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

[Sherry Yang]

On Tue, Aug 29, 2017 at 11:07 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote:
>> Use helper functions buffer_next and buffer_prev instead
>> of list_entry to get the next and previous buffers.
>>
>> Signed-off-by: Sherry Yang 
>> ---
>>  drivers/android/binder_alloc.c | 24 +++-
>>  1 file changed, 15 insertions(+), 9 deletions(-)
>
> What changed from the previous version?

This specific patch didn't change. The change is only in [patch v3
3/6] (crash fix) and in [patch v3 6/6] (new patch that add stats).

> Always put the changes below the --- line.  Like the documentation says
> to do so.

Do you mean I should use --annotate to git send-email to specify what
has changed across versions for each patch? I used --compose and put
what changed from v2 to v3 in the introductory message [patch 0/6].

> Also, don't I already have these patches in my tree?  Do you want me to
> revert the existing ones and use the new ones, or what about a fixup
> patch for any differences?

I got a message saying a test failed on [patch 3/5]. I resubmitted the
entire thread because I wasn't sure if you would drop the failing
patch set. If the entire failing patch set is dropped, then v3 can be
used as a replacement.

If you prefer a fixup patch, I can post another patch set (the crash
fix and the new patch) on top of what you already applied, but it
might be easier to do what's described in the previous paragraph (drop
v2 and apply v3).

Sherry Yang

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

[PATCH 2/2] staging: r8822be: Simplify deinit_priv()

[Larry Finger]

Now that the extraneous debugging code is removed, routine deinit_priv()
clearly contains code that serves no useful purpose.

A null test before a call to kfree() and a spurious cast are also removed.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c 
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 2b1c5fae64ef..6448a8bfc14b 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -382,13 +382,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
 
indicator = halmac->indicator;
halmac->indicator = NULL;
-   if (indicator) {
-   u32 count, size;
-
-   count = HALMAC_FEATURE_ALL + 1;
-   size = sizeof(*indicator) * count;
-   kfree((u8 *)indicator);
-   }
+   kfree(indicator);
 }
 
 int rtl_halmac_init_adapter(struct rtl_priv *rtlpriv)
-- 
2.12.3

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

[PATCH 0/2] staging: r8822be: Remove some left-over debug code

[Larry Finger]

Some useless debugging code from the initial writing of the driver was not
removed before it was submitted. That oversight is now fixed and the
remaining code in routine deinit_priv() is simplified.

Larry

Larry Finger (2):
  staging: r8822be: Remove some dead code
  staging: r8822be: Simplify deinit_priv()

 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

-- 
2.12.3

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

[PATCH 1/2] staging: r8822be: Remove some dead code

[Larry Finger]

The code found inside an #ifdef CONFIG_RTL_DEBUG ... #endif section
is left over from debugging of the original driver, and should be
deleted.

Reported by: Andreas Ziegler 
Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c 
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c6078f..2b1c5fae64ef 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,26 +386,6 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
 
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
-   {
-   struct submit_ctx *sctx;
-   u32 i;
-
-   for (i = 0; i < count; i++) {
-   if (!indicator[i].sctx)
-   continue;
-
-   RT_TRACE(
-   rtlpriv, COMP_HALMAC, DBG_LOUD,
-   "%s:  %s id(%d) sctx still 
exist!!\n",
-   __func__, RTL_HALMAC_FEATURE_NAME[i],
-   i);
-   sctx = indicator[i].sctx;
-   indicator[i].sctx = NULL;
-   rtl_mfree((u8 *)sctx, sizeof(*sctx));
-   }
-   }
-#endif /* !CONFIG_RTL_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
-- 
2.12.3

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

[PATCH 25/28] staging: unisys: visorbus: just check for GUID

[David Kershner]

Every channel_type must have a valid GUID, checking for the name was just
redundant.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 0957eaa..a95901c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -151,9 +151,7 @@ static int visorbus_match(struct device *xdev, struct 
device_driver *xdrv)
if (!drv->channel_types)
return 0;
 
-   for (i = 0;
-!guid_is_null(>channel_types[i].guid) || 
drv->channel_types[i].name;
-i++)
+   for (i = 0; !guid_is_null(>channel_types[i].guid); i++)
if (guid_equal(>channel_types[i].guid, channel_type))
return i + 1;
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 24/28] staging: unisys: Use size of channel defined in the channel.

[David Kershner]

The size of the channel should be pulled from the channel header, not
from the message. All channels must be at least the size of the
channel_header.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 10 +--
 drivers/staging/unisys/visorbus/visorchannel.c | 56 ---
 drivers/staging/unisys/visorbus/visorchipset.c |  6 +--
 3 files changed, 22 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 8651c87..e878d65 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -38,12 +38,10 @@ int visorbus_init(void);
 void visorbus_exit(void);
 
 /* visorchannel access functions */
-struct visorchannel *visorchannel_create(u64 physaddr,
-unsigned long channel_bytes,
-gfp_t gfp, const guid_t *guid);
-struct visorchannel *visorchannel_create_with_lock(u64 physaddr,
-  unsigned long channel_bytes,
-  gfp_t gfp, const guid_t 
*guid);
+struct visorchannel *visorchannel_create(u64 physaddr, gfp_t gfp,
+const guid_t *guid);
+struct visorchannel *visorchannel_create_with_lock(u64 physaddr, gfp_t gfp,
+  const guid_t *guid);
 void visorchannel_destroy(struct visorchannel *channel);
 int visorchannel_read(struct visorchannel *channel, ulong offset,
  void *dest, ulong nbytes);
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 81e428a..49d1f5f 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -363,17 +363,8 @@ static int signalinsert_inner(struct visorchannel 
*channel, u32 queue,
  *  for a data area in memory, but does NOT modify
  *  this data area
  * @physaddr:  physical address of start of channel
- * @channel_bytes: size of the channel in bytes; this may 0 if the channel has
- * already been initialized in memory (which is true for all
- * channels provided to guest environments by the s-Par
- * back-end), in which case the actual channel size will be
- * read from the channel header in memory
  * @gfp:   gfp_t to use when allocating memory for the data struct
- * @guid:  GUID that identifies channel type; this may 0 if the channel
- * has already been initialized in memory (which is true for 
all
- * channels provided to guest environments by the s-Par
- * back-end), in which case the actual channel guid will be
- * read from the channel header in memory
+ * @guid:  GUID that identifies channel type;
  * @needs_lock:must specify true if you have multiple threads of execution
  * that will be calling visorchannel methods of this
  * visorchannel at the same time
@@ -381,11 +372,9 @@ static int signalinsert_inner(struct visorchannel 
*channel, u32 queue,
  * Return: pointer to visorchannel that was created if successful,
  * otherwise NULL
  */
-static struct visorchannel *visorchannel_create_guts(
-   u64 physaddr,
-   unsigned long channel_bytes,
-   gfp_t gfp, const guid_t *guid,
-   bool needs_lock)
+static struct visorchannel *visorchannel_create_guts(u64 physaddr, gfp_t gfp,
+const guid_t *guid,
+bool needs_lock)
 {
struct visorchannel *channel;
int err;
@@ -423,35 +412,28 @@ static struct visorchannel *visorchannel_create_guts(
channel->physaddr = physaddr;
channel->nbytes = size;
 
-   err = visorchannel_read(channel, 0, >chan_hdr,
-   sizeof(struct channel_header));
+   err = visorchannel_read(channel, 0, >chan_hdr, size);
if (err)
goto err_destroy_channel;
-
-   /* we had better be a CLIENT of this channel */
-   if (channel_bytes == 0)
-   channel_bytes = (ulong)channel->chan_hdr.size;
-   if (guid_is_null(guid))
-   guid = >chan_hdr.chtype;
+   size = (ulong)channel->chan_hdr.size;
 
memunmap(channel->mapped);
if (channel->requested)
release_mem_region(channel->physaddr, channel->nbytes);
channel->mapped = 

[PATCH 21/28] staging: unisys: visorchipset: Shorten parser_init_byte_stream.

[David Kershner]

Shorten the name of the function parser_init_byte_stream to just
parser_init_stream.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index b30e3a1..1f7c6bf 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1449,8 +1449,8 @@ static void parser_done(struct parser_context *ctx)
kfree(ctx);
 }
 
-static struct parser_context *parser_init_byte_stream(u64 addr, u32 bytes,
- bool *retry)
+static struct parser_context *parser_init_stream(u64 addr, u32 bytes,
+bool *retry)
 {
int allocbytes;
struct parser_context *ctx;
@@ -1523,8 +1523,7 @@ static int handle_command(struct controlvm_message inmsg, 
u64 channel_addr)
if (parm_bytes) {
bool retry = false;
 
-   parser_ctx =
-   parser_init_byte_stream(parm_addr, parm_bytes, );
+   parser_ctx = parser_init_stream(parm_addr, parm_bytes, );
if (!parser_ctx && retry)
return -EAGAIN;
}
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 28/28] staging: unisys: change pr_err to dev_err in visor_check_channel

[David Kershner]

From: Sameer Wadgaonkar 

Changing pr_err to dev_err in visor_check_channel. Added device
as an argument to visor_check_channel to pass into dev_err.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   |  7 ++--
 drivers/staging/unisys/visorbus/visorbus_main.c | 33 +-
 drivers/staging/unisys/visorbus/visorchipset.c  |  1 +-
 3 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index d7fa27b..e4ee38c 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -166,9 +166,10 @@ struct visor_device {
 
 #define to_visor_device(x) container_of(x, struct visor_device, device)
 
-int visor_check_channel(struct channel_header *ch, const guid_t *expected_guid,
-   char *chname, u64 expected_min_bytes,
-   u32 expected_version, u64 expected_signature);
+int visor_check_channel(struct channel_header *ch, struct device *dev,
+   const guid_t *expected_uuid, char *chname,
+   u64 expected_min_bytes, u32 expected_version,
+   u64 expected_signature);
 
 int visorbus_register_visor_driver(struct visor_driver *drv);
 void visorbus_unregister_visor_driver(struct visor_driver *drv);
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index ab47bbc..2bc7ff7 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -70,6 +70,7 @@ static LIST_HEAD(list_all_device_instances);
  * is used to pass the EFI_DIAG_CAPTURE_PROTOCOL needed to log messages.
  */
 int visor_check_channel(struct channel_header *ch,
+   struct device *dev,
const guid_t *expected_guid,
char *chname,
u64 expected_min_bytes,
@@ -79,38 +80,38 @@ int visor_check_channel(struct channel_header *ch,
if (!guid_is_null(expected_guid)) {
/* caller wants us to verify type GUID */
if (!guid_equal(>chtype, expected_guid)) {
-   pr_err("Channel mismatch on channel=%s(%pUL) field=type 
expected=%pUL actual=%pUL\n",
-  chname, expected_guid,
-  expected_guid, >chtype);
+   dev_err(dev, "Channel mismatch on channel=%s(%pUL) 
field=type expected=%pUL actual=%pUL\n",
+   chname, expected_guid, expected_guid,
+   >chtype);
return 0;
}
}
/* verify channel size */
if (expected_min_bytes > 0) {
if (ch->size < expected_min_bytes) {
-   pr_err("Channel mismatch on channel=%s(%pUL) field=size 
expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
-  chname, expected_guid,
-  (unsigned long long)expected_min_bytes,
-  ch->size);
+   dev_err(dev, "Channel mismatch on channel=%s(%pUL) 
field=size expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
+   chname, expected_guid,
+   (unsigned long long)expected_min_bytes,
+   ch->size);
return 0;
}
}
/* verify channel version */
if (expected_version > 0) {
if (ch->version_id != expected_version) {
-   pr_err("Channel mismatch on channel=%s(%pUL) 
field=version expected=0x%-8.8lx actual=0x%-8.8x\n",
-  chname, expected_guid,
-  (unsigned long)expected_version,
-  ch->version_id);
+   dev_err(dev, "Channel mismatch on channel=%s(%pUL) 
field=version expected=0x%-8.8lx actual=0x%-8.8x\n",
+   chname, expected_guid,
+   (unsigned long)expected_version,
+   ch->version_id);
return 0;
}
}
/* verify channel signature */
if (expected_signature > 0) {
if (ch->signature != expected_signature) {
-   pr_err("Channel mismatch on channel=%s(%pUL) 
field=signature expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
-  chname, expected_guid,
-  expected_signature, ch->signature);
+   dev_err(dev, "Channel mismatch on channel=%s(%pUL) 
field=signature expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
+  

[PATCH 14/28] staging: unisys: visorbus: Remove useless initialization.

[David Kershner]

The variable ctx was allocated with kzalloc, so all the data inside is
zero, no need to reset it to 0.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 88cefa5..98c991b 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1477,9 +1477,6 @@ static struct parser_context *parser_init_byte_stream(u64 
addr, u32 bytes,
 
ctx->allocbytes = allocbytes;
ctx->param_bytes = bytes;
-   ctx->curr = NULL;
-   ctx->bytes_remaining = 0;
-   ctx->byte_stream = false;
mapping = memremap(addr, bytes, MEMREMAP_WB);
if (!mapping)
goto err_finish_ctx;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 23/28] staging: unisys: visornic: Remove unnecessary return values

[David Kershner]

From: David Binder 

Removes unnecessary return value in send_rcv_posts_if_needed(), since
NAPI polling functions do not return errors.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 0ca8666..dc390ea 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -1585,10 +1585,8 @@ static const struct file_operations debugfs_info_fops = {
 
 /* send_rcv_posts_if_needed - send receive buffers to the IO Partition.
  * @devdata: Visornic device.
- *
- * Return: 0.
  */
-static int send_rcv_posts_if_needed(struct visornic_devdata *devdata)
+static void send_rcv_posts_if_needed(struct visornic_devdata *devdata)
 {
int i;
struct net_device *netdev;
@@ -1598,7 +1596,7 @@ static int send_rcv_posts_if_needed(struct 
visornic_devdata *devdata)
 
/* don't do this until vnic is marked ready */
if (!(devdata->enabled && devdata->enab_dis_acked))
-   return 0;
+   return;
 
netdev = devdata->netdev;
rcv_bufs_allocated = 0;
@@ -1627,7 +1625,6 @@ static int send_rcv_posts_if_needed(struct 
visornic_devdata *devdata)
}
}
devdata->num_rcv_bufs_could_not_alloc -= rcv_bufs_allocated;
-   return 0;
 }
 
 /* drain_resp_queue - drains and ignores all messages from the resp queue
@@ -1750,12 +1747,8 @@ static int visornic_poll(struct napi_struct *napi, int 
budget)
struct visornic_devdata,
napi);
int rx_count = 0;
-   int err;
-
-   err = send_rcv_posts_if_needed(devdata);
-   if (err)
-   return err;
 
+   send_rcv_posts_if_needed(devdata);
service_resp_queue(devdata->cmdrsp, devdata, _count, budget);
 
/* If there aren't any more packets to receive stop the poll */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 13/28] staging: unisys: visorbus: Remove useless comment.

[David Kershner]

Currently setting it in the right location, so no longer not sure.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index dca936b..88cefa5 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -792,8 +792,6 @@ static int visorbus_device_create(struct controlvm_message 
*inmsg)
dev_info->chipset_bus_no = bus_no;
dev_info->chipset_dev_no = dev_no;
guid_copy(_info->inst, >create_device.dev_inst_guid);
-
-   /* not sure where the best place to set the 'parent' */
dev_info->device.parent = _info->device;
 
visorchannel =
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 20/28] staging: unisys: visorbus: Move parser functions location in file.

[David Kershner]

The parser functions were defined at the top of the file even though they
were not referenced until later in the file. This patch moves them closer
to where they are defined so they can be easily referenced.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 116 +-
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 090818f..b30e3a1 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -297,64 +297,6 @@ static ssize_t remaining_steps_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(remaining_steps);
 
-static const guid_t *parser_id_get(struct parser_context *ctx)
-{
-   return >data.id;
-}
-
-static void parser_done(struct parser_context *ctx)
-{
-   chipset_dev->controlvm_payload_bytes_buffered -= ctx->param_bytes;
-   kfree(ctx);
-}
-
-static void *parser_string_get(struct parser_context *ctx)
-{
-   u8 *pscan;
-   unsigned long nscan;
-   int value_length;
-   void *value;
-   int i;
-
-   pscan = ctx->curr;
-   if (!pscan)
-   return NULL;
-   nscan = ctx->bytes_remaining;
-   if (nscan == 0)
-   return NULL;
-
-   for (i = 0, value_length = -1; i < nscan; i++)
-   if (pscan[i] == '\0') {
-   value_length = i;
-   break;
-   }
-   /* '\0' was not included in the length */
-   if (value_length < 0)
-   value_length = nscan;
-
-   value = kmalloc(value_length + 1, GFP_KERNEL);
-   if (!value)
-   return NULL;
-   if (value_length > 0)
-   memcpy(value, pscan, value_length);
-   ((u8 *)(value))[value_length] = '\0';
-   return value;
-}
-
-static void *parser_name_get(struct parser_context *ctx)
-{
-   struct visor_controlvm_parameters_header *phdr = NULL;
-
-   phdr = >data;
-
-   if (phdr->name_offset + phdr->name_length > ctx->param_bytes)
-   return NULL;
-
-   ctx->curr = (char *) + phdr->name_offset;
-   ctx->bytes_remaining = phdr->name_length;
-   return parser_string_get(ctx);
-}
-
 struct visor_busdev {
u32 bus_no;
u32 dev_no;
@@ -701,6 +643,58 @@ static int visorbus_destroy(struct controlvm_message 
*inmsg)
return err;
 }
 
+static const guid_t *parser_id_get(struct parser_context *ctx)
+{
+   return >data.id;
+}
+
+static void *parser_string_get(struct parser_context *ctx)
+{
+   u8 *pscan;
+   unsigned long nscan;
+   int value_length;
+   void *value;
+   int i;
+
+   pscan = ctx->curr;
+   if (!pscan)
+   return NULL;
+   nscan = ctx->bytes_remaining;
+   if (nscan == 0)
+   return NULL;
+
+   for (i = 0, value_length = -1; i < nscan; i++)
+   if (pscan[i] == '\0') {
+   value_length = i;
+   break;
+   }
+   /* '\0' was not included in the length */
+   if (value_length < 0)
+   value_length = nscan;
+
+   value = kmalloc(value_length + 1, GFP_KERNEL);
+   if (!value)
+   return NULL;
+   if (value_length > 0)
+   memcpy(value, pscan, value_length);
+   ((u8 *)(value))[value_length] = '\0';
+   return value;
+}
+
+static void *parser_name_get(struct parser_context *ctx)
+{
+   struct visor_controlvm_parameters_header *phdr = NULL;
+
+   phdr = >data;
+
+   if (phdr->name_offset + phdr->name_length > ctx->param_bytes)
+   return NULL;
+
+   ctx->curr = (char *) + phdr->name_offset;
+   ctx->bytes_remaining = phdr->name_length;
+   return parser_string_get(ctx);
+}
+
 static int visorbus_configure(struct controlvm_message *inmsg,
  struct parser_context *parser_ctx)
 {
@@ -1449,6 +1443,12 @@ void visorbus_device_changestate_response(struct 
visor_device *dev_info,
dev_info->pending_msg_hdr = NULL;
 }
 
+static void parser_done(struct parser_context *ctx)
+{
+   chipset_dev->controlvm_payload_bytes_buffered -= ctx->param_bytes;
+   kfree(ctx);
+}
+
 static struct parser_context *parser_init_byte_stream(u64 addr, u32 bytes,
  bool *retry)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 27/28] staging: unisys: visorbus: remove EXPORT_SYMBOL_GPL for visor_check_channel

[David Kershner]

From: Sameer Wadgaonkar 

Removing EXPORT_SYMBOL_GPU from visor_check_channel since it is
used only in visorbus.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index a95901c..ab47bbc 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -116,7 +116,6 @@ int visor_check_channel(struct channel_header *ch,
}
return 1;
 }
-EXPORT_SYMBOL_GPL(visor_check_channel);
 
 static int visorbus_uevent(struct device *xdev, struct kobj_uevent_env *env)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 26/28] staging: unisys: visorbus: Fix up GUID definition

[David Kershner]

Fix up the GUID definition to remove some checkpatch warnings as well as
using the whole width of the screen.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 5bafadc..82b3bf7 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -20,9 +20,8 @@
 #include "visorbus_private.h"
 
 /* {72120008-4AAB-11DC-8530-444553544200} */
-#define VISOR_SIOVM_GUID \
-GUID_INIT(0x72120008, 0x4AAB, 0x11DC, \
-  0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
+#define VISOR_SIOVM_GUID GUID_INIT(0x72120008, 0x4AAB, 0x11DC, 0x85, 0x30, \
+  0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
 
 static const guid_t visor_vhba_channel_guid = VISOR_VHBA_CHANNEL_GUID;
 static const guid_t visor_siovm_guid = VISOR_SIOVM_GUID;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 07/28] staging: unisys: visorbus: Fix parameter alignment.

[David Kershner]

Fixed the following checkpatch warning:
visorchannel.c:443: CHECK: Alignment should match open parenthesis

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 6afc745..3969217 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -440,7 +440,7 @@ static struct visorchannel *visorchannel_create_guts(
goto err_destroy_channel;
 
channel->mapped = memremap(channel->physaddr, channel_bytes,
-   MEMREMAP_WB);
+  MEMREMAP_WB);
if (!channel->mapped) {
release_mem_region(channel->physaddr, channel_bytes);
goto err_destroy_channel;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 10/28] staging: unisys: Don't check for null before getting driver device.

[David Kershner]

The macro to convert to the driver object was giving a checkpatch warning
when it ateempted to check for a null driver. It would return NULL if it
found it, but only one location was checking to see if it was NULL.

Remove the check in the MACRO and do it prior to calling the macro if
required.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   | 3 +--
 drivers/staging/unisys/visorbus/visorbus_main.c | 8 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index e97bb5f..0af5477 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -104,8 +104,7 @@ struct visor_driver {
struct device_driver driver;
 };
 
-#define to_visor_driver(x) ((x) ? \
-   (container_of(x, struct visor_driver, driver)) : (NULL))
+#define to_visor_driver(x) (container_of(x, struct visor_driver, driver))
 
 /**
  * struct visor_device - A device type for things "plugged" into the visorbus
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 05b632e..0957eaa 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1158,13 +1158,13 @@ static int 
visorchipset_initiate_device_pause_resume(struct visor_device *dev,
int err;
struct visor_driver *drv = NULL;
 
-   drv = to_visor_driver(dev->device.driver);
-   if (!drv)
-   return -ENODEV;
-
+   /* If no driver associated with the device nothing to pause/resume */
+   if (!dev->device.driver)
+   return 0;
if (dev->pausing || dev->resuming)
return -EBUSY;
 
+   drv = to_visor_driver(dev->device.driver);
if (is_pause) {
dev->pausing = true;
err = drv->pause(dev, pause_state_change_complete);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 05/28] staging: unisys: visornic: Fix miscellaneous block comment format issues.

[David Kershner]

From: David Binder 

Fixes miscellaneous formatting issues with several block comments
throughout visornic_main.c.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index ca7971b..0ca8666 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -52,8 +52,7 @@ static struct visor_channeltype_descriptor 
visornic_channel_types[] = {
{}
 };
 MODULE_DEVICE_TABLE(visorbus, visornic_channel_types);
-/*
- * FIXME XXX: This next line of code must be fixed and removed before
+/* FIXME XXX: This next line of code must be fixed and removed before
  * acceptance into the 'normal' part of the kernel.  It is only here as a place
  * holder to get module autoloading functionality working for visorbus.  Code
  * must be added to scripts/mode/file2alias.c, etc., to get this working
@@ -76,7 +75,6 @@ struct chanstat {
 };
 
 /* struct visornic_devdata
- *
  * @enabled:0 disabled 1 enabled to receive.
  * @enab_dis_acked: NET_RCV_ENABLE/DISABLE acked by IOPART.
  * @struct *dev:
@@ -1387,8 +1385,7 @@ static int visornic_rx(struct uiscmdrsp *cmdrsp)
 */
 
skb = NULL;
-   /*
-* whether the packet got dropped or handled, the skb is freed by
+   /* whether the packet got dropped or handled, the skb is freed by
 * kernel code, so we shouldn't free it. but we should repost a
 * new rcv buffer.
 */
@@ -1863,9 +1860,10 @@ static int visornic_probe(struct visor_device *dev)
goto cleanup_netdev;
}
 
-   /* set the net_xmit outstanding threshold */
-   /* always leave two slots open but you should have 3 at a minimum */
-   /* note that max_outstanding_net_xmits must be > 0 */
+   /* set the net_xmit outstanding threshold
+* always leave two slots open but you should have 3 at a minimum
+* note that max_outstanding_net_xmits must be > 0
+*/
devdata->max_outstanding_net_xmits =
max_t(unsigned long, 3, ((devdata->num_rcv_bufs / 3) - 2));
devdata->upper_threshold_net_xmits =
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 22/28] staging: unisys: visorbus: use all 80 characters for multi-line messages

[David Kershner]

The file visorchipset had a bunch of comments that were not using the full
screen before they wrapped, update the comments to wrap at 80 characters
instead.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 1f7c6bf..0ea20bb 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -41,9 +41,9 @@ static const guid_t visor_controlvm_channel_guid = 
VISOR_CONTROLVM_CHANNEL_GUID;
 #define UNISYS_VISOR_ID_EDX 0x34367261
 
 /*
- * When the controlvm channel is idle for at least MIN_IDLE_SECONDS,
- * we switch to slow polling mode. As soon as we get a controlvm
- * message, we switch back to fast polling mode.
+ * When the controlvm channel is idle for at least MIN_IDLE_SECONDS, we switch
+ * to slow polling mode. As soon as we get a controlvm message, we switch back
+ * to fast polling mode.
  */
 #define MIN_IDLE_SECONDS 10
 
@@ -377,15 +377,15 @@ static int chipset_init(struct controlvm_message *inmsg)
chipset_inited = 1;
 
/*
-* Set features to indicate we support parahotplug (if Command
-* also supports it).
+* Set features to indicate we support parahotplug (if Command also
+* supports it).
 */
features = inmsg->cmd.init_chipset.features &
   VISOR_CHIPSET_FEATURE_PARA_HOTPLUG;
 
/*
-* Set the "reply" bit so Command knows this is a
-* features-aware driver.
+* Set the "reply" bit so Command knows this is a features-aware
+* driver.
 */
features |= VISOR_CHIPSET_FEATURE_REPLY;
 
@@ -1210,10 +1210,9 @@ static int parahotplug_process_message(struct 
controlvm_message *inmsg)
}
 
/*
-* For disable messages, add the request to the
-* request list before kicking off the udev script. It
-* won't get responded to until the script has
-* indicated it's done.
+* For disable messages, add the request to the request list before
+* kicking off the udev script. It won't get responded to until the
+* script has indicated it's done.
 */
spin_lock(_request_list_lock);
list_add_tail(>list, _request_list);
@@ -1554,8 +1553,8 @@ static int handle_command(struct controlvm_message inmsg, 
u64 channel_addr)
err = parahotplug_process_message();
} else {
/*
-* save the hdr and cmd structures for later use
-* when sending back the response to Command
+* save the hdr and cmd structures for later use when
+* sending back the response to Command
 */
err = visorbus_device_changestate();
break;
@@ -1664,9 +1663,8 @@ static void controlvm_periodic_work(struct work_struct 
*work)
 
if (chipset_dev->controlvm_pending_msg_valid) {
/*
-* we throttled processing of a prior
-* msg, so try to process it again
-* rather than reading a new one
+* we throttled processing of a prior msg, so try to process
+* it again rather than reading a new one
 */
inmsg = chipset_dev->controlvm_pending_msg;
chipset_dev->controlvm_pending_msg_valid = false;
@@ -1701,9 +1699,8 @@ static void controlvm_periodic_work(struct work_struct 
*work)
if (time_after(jiffies, chipset_dev->most_recent_message_jiffies +
(HZ * MIN_IDLE_SECONDS))) {
/*
-* it's been longer than MIN_IDLE_SECONDS since we
-* processed our last controlvm message; slow down the
-* polling
+* it's been longer than MIN_IDLE_SECONDS since we processed
+* our last controlvm message; slow down the polling
 */
if (chipset_dev->poll_jiffies !=
  POLLJIFFIES_CONTROLVMCHANNEL_SLOW)
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 19/28] staging: unisys: visorbus: remove uneeded initializations

[David Kershner]

Several variables were initialized when not needed. Remove the extraneous
initializations.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index a602ba6..090818f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -312,8 +312,8 @@ static void *parser_string_get(struct parser_context *ctx)
 {
u8 *pscan;
unsigned long nscan;
-   int value_length = -1;
-   void *value = NULL;
+   int value_length;
+   void *value;
int i;
 
pscan = ctx->curr;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 09/28] staging: unisys: visorbus: Use __func__ instead of name.

[David Kershner]

The dev_err was using the hardcoded function name, as reported by
checkpatch, it should be using __func__.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 7423c9e..c7b4599 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -744,7 +744,7 @@ static int visorbus_configure(struct controlvm_message 
*inmsg,
 
 err_respond:
dev_err(_dev->acpi_device->dev,
-   "visorbus_configure exited with err: %d\n", err);
+   "%s exited with err: %d\n", __func__, err);
if (inmsg->hdr.flags.response_expected == 1)
controlvm_responder(inmsg->hdr.id, >hdr, err);
return err;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 11/28] staging: unisys: include: Add comment next to mutex.

[David Kershner]

Checkpatch reports an error that no comment was next to the mutex lock.
Add an appropriate message for the lock.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 0af5477..d7fa27b 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -119,8 +119,8 @@ struct visor_driver {
  * activity.
  * @being_removed: Indicates that the device is being removed from
  * the bus. Private bus driver use only.
- * @visordriver_callback_lock: Used by the bus driver to lock when handling
- * channel events.
+ * @visordriver_callback_lock: Used by the bus driver to lock when adding and
+ * removing devices.
  * @pausing:   Indicates that a change towards a paused state.
  * is in progress. Only modified by the bus driver.
  * @resuming:  Indicates that a change towards a running state
@@ -149,7 +149,7 @@ struct visor_device {
struct timer_list timer;
bool timer_active;
bool being_removed;
-   struct mutex visordriver_callback_lock;
+   struct mutex visordriver_callback_lock; /* synchronize probe/remove */
bool pausing;
bool resuming;
u32 chipset_bus_no;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 12/28] staging: unisys: visorbus: Consolidate controlvm channel creation.

[David Kershner]

The functions to create the controlvm channel were disjointed and ignoring
information that was available. This patch consolidates it so it clearer
what is happening.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 47 ++-
 1 file changed, 17 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index c7b4599..dca936b 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1332,34 +1332,27 @@ static int unisys_vmcall(unsigned long tuple, unsigned 
long param)
}
 }
 
-static unsigned int issue_vmcall_io_controlvm_addr(u64 *control_addr,
-  u32 *control_bytes)
+static int controlvm_channel_create(struct visorchipset_device *dev)
 {
-   u64 physaddr;
+   struct visorchannel *chan;
+   u64 addr;
+   u32 size;
int err;
 
-   physaddr = virt_to_phys(_dev->controlvm_params);
-   err = unisys_vmcall(VMCALL_CONTROLVM_ADDR, physaddr);
+   err = unisys_vmcall(VMCALL_CONTROLVM_ADDR,
+   virt_to_phys(>controlvm_params));
if (err)
return err;
-
-   *control_addr = chipset_dev->controlvm_params.address;
-   *control_bytes = chipset_dev->controlvm_params.channel_bytes;
-
+   addr = dev->controlvm_params.address;
+   size = dev->controlvm_params.channel_bytes;
+   chan = visorchannel_create_with_lock(addr, size, GFP_KERNEL,
+_controlvm_channel_guid);
+   if (!chan)
+   return -ENOMEM;
+   dev->controlvm_channel = chan;
return 0;
 }
 
-static u64 controlvm_get_channel_address(void)
-{
-   u64 addr = 0;
-   u32 size = 0;
-
-   if (issue_vmcall_io_controlvm_addr(, ))
-   return 0;
-
-   return addr;
-}
-
 static void setup_crash_devices_work_queue(struct work_struct *work)
 {
struct controlvm_message local_crash_bus_msg;
@@ -1739,32 +1732,26 @@ static void controlvm_periodic_work(struct work_struct 
*work)
 static int visorchipset_init(struct acpi_device *acpi_device)
 {
int err = -ENODEV;
-   u64 addr;
struct visorchannel *controlvm_channel;
 
chipset_dev = kzalloc(sizeof(*chipset_dev), GFP_KERNEL);
if (!chipset_dev)
goto error;
 
-   addr = controlvm_get_channel_address();
-   if (!addr)
-   goto error;
+   err = controlvm_channel_create(chipset_dev);
+   if (err)
+   goto error_free_chipset_dev;
 
acpi_device->driver_data = chipset_dev;
chipset_dev->acpi_device = acpi_device;
chipset_dev->poll_jiffies = POLLJIFFIES_CONTROLVMCHANNEL_FAST;
-   controlvm_channel = visorchannel_create_with_lock(addr, 0, GFP_KERNEL,
-   _controlvm_channel_guid);
-   if (!controlvm_channel)
-   goto error_free_chipset_dev;
-
-   chipset_dev->controlvm_channel = controlvm_channel;
 
err = sysfs_create_groups(_dev->acpi_device->dev.kobj,
  visorchipset_dev_groups);
if (err < 0)
goto error_destroy_channel;
 
+   controlvm_channel = chipset_dev->controlvm_channel;
if (!visor_check_channel(visorchannel_get_header(controlvm_channel),
 _controlvm_channel_guid,
 "controlvm",
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 18/28] staging: unisys: visorbus: Remove useless else clause in visorutil_spar_detect.

[David Kershner]

The function visorutil_spar_detect had an if clause that returns from the
function, no need to do the rest of the code in an else clause.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d27e0e8..a602ba6 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1830,9 +1830,8 @@ static __init int visorutil_spar_detect(void)
return  (ebx == UNISYS_VISOR_ID_EBX) &&
(ecx == UNISYS_VISOR_ID_ECX) &&
(edx == UNISYS_VISOR_ID_EDX);
-   } else {
-   return 0;
}
+   return 0;
 }
 
 static int init_unisys(void)
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 17/28] staging: unisys: Change data to point to visor_controlvm_parameters_header.

[David Kershner]

The data field was being defined as a character array and then casted into
a visor_controlvm_parameters_header structure. This patch converts it to
just point to the visor_controlvm_parameters_header structure. The data
following the header is still behind the header_info.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 23 +++
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 3a8357e..d27e0e8 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -53,7 +53,7 @@ struct parser_context {
u8 *curr;
unsigned long bytes_remaining;
bool byte_stream;
-   char data[0];
+   struct visor_controlvm_parameters_header data;
 };
 
 /* VMCALL_CONTROLVM_ADDR: Used by all guests, not just IO. */
@@ -299,10 +299,7 @@ static DEVICE_ATTR_RW(remaining_steps);
 
 static const guid_t *parser_id_get(struct parser_context *ctx)
 {
-   struct visor_controlvm_parameters_header *phdr = NULL;
-
-   phdr = (struct visor_controlvm_parameters_header *)(ctx->data);
-   return >id;
+   return >data.id;
 }
 
 static void parser_done(struct parser_context *ctx)
@@ -348,12 +345,12 @@ static void *parser_name_get(struct parser_context *ctx)
 {
struct visor_controlvm_parameters_header *phdr = NULL;
 
-   phdr = (struct visor_controlvm_parameters_header *)(ctx->data);
+   phdr = >data;
 
if (phdr->name_offset + phdr->name_length > ctx->param_bytes)
return NULL;
 
-   ctx->curr = ctx->data + phdr->name_offset;
+   ctx->curr = (char *) + phdr->name_offset;
ctx->bytes_remaining = phdr->name_length;
return parser_string_get(ctx);
 }
@@ -1455,17 +1452,15 @@ void visorbus_device_changestate_response(struct 
visor_device *dev_info,
 static struct parser_context *parser_init_byte_stream(u64 addr, u32 bytes,
  bool *retry)
 {
-   int allocbytes = sizeof(struct parser_context) + bytes;
+   int allocbytes;
struct parser_context *ctx;
void *mapping;
 
*retry = false;
 
-   /*
-* alloc an 0 extra byte to ensure payload is
-* '\0'-terminated
-*/
-   allocbytes++;
+   /* alloc an extra byte to ensure payload is \0 terminated */
+   allocbytes = bytes + 1 + (sizeof(struct parser_context) -
+sizeof(struct visor_controlvm_parameters_header));
if ((chipset_dev->controlvm_payload_bytes_buffered + bytes)
> MAX_CONTROLVM_PAYLOAD_BYTES) {
*retry = true;
@@ -1482,7 +1477,7 @@ static struct parser_context *parser_init_byte_stream(u64 
addr, u32 bytes,
mapping = memremap(addr, bytes, MEMREMAP_WB);
if (!mapping)
goto err_finish_ctx;
-   memcpy(ctx->data, mapping, bytes);
+   memcpy(>data, mapping, bytes);
memunmap(mapping);
ctx->byte_stream = true;
chipset_dev->controlvm_payload_bytes_buffered += ctx->param_bytes;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 16/28] staging: unisys: visorbus: Split else if blocks into multiple if.

[David Kershner]

Visorbus_configure had a block of "else if" clauses at the beginning of the
function. Simplify this to just being "if" clauses since each code block
ended with a goto.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index e5d051f..3a8357e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -717,10 +717,12 @@ static int visorbus_configure(struct controlvm_message 
*inmsg,
if (!bus_info) {
err = -EINVAL;
goto err_respond;
-   } else if (bus_info->state.created == 0) {
+   }
+   if (bus_info->state.created == 0) {
err = -EINVAL;
goto err_respond;
-   } else if (bus_info->pending_msg_hdr) {
+   }
+   if (bus_info->pending_msg_hdr) {
err = -EIO;
goto err_respond;
}
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 15/28] staging: unisys: visorbus: Remove check for valid parm_addr.

[David Kershner]

The variable parm_addr will never be null, so no need to check for it.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 98c991b..e5d051f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1523,7 +1523,7 @@ static int handle_command(struct controlvm_message inmsg, 
u64 channel_addr)
 * within our OS-controlled memory. We need to know that, because it
 * makes a difference in how we compute the virtual address.
 */
-   if (parm_addr && parm_bytes) {
+   if (parm_bytes) {
bool retry = false;
 
parser_ctx =
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 04/28] staging: unisys: visornic: Fix up existing function comments.

[David Kershner]

From: David Binder 

Refactors existing static function comments to increase code readability.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 417 +++--
 1 file changed, 190 insertions(+), 227 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 0c29d53..ca7971b 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -233,17 +233,15 @@ static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, 
u16 inp_len,
return index + i;
 }
 
-/*
- * visor_copy_fragsinfo_from_skb(
- * @skb_in: skbuff that we are pulling the frags from
- * @firstfraglen: length of first fragment in skb
- * @frags_max: max len of frags array
- * @frags: frags array filled in on output
+/* visor_copy_fragsinfo_from_skb - copy fragment list in the SKB to a phys_info
+ *array that the IOPART understands
+ * @skb: Skbuff that we are pulling the frags from.
+ * @firstfraglen: Length of first fragment in skb.
+ * @frags_max:   Max len of frags array.
+ * @frags:   Frags array filled in on output.
  *
- * Copy the fragment list in the SKB to a phys_info
- * array that the IOPART understands.
- * Return value indicates number of entries filled in frags
- * Negative values indicate an error.
+ * Return: Positive integer indicating number of entries filled in frags on
+ * success, negative integer on error.
  */
 static int visor_copy_fragsinfo_from_skb(struct sk_buff *skb,
 unsigned int firstfraglen,
@@ -341,14 +339,11 @@ static const struct file_operations 
debugfs_enable_ints_fops = {
.write = enable_ints_write,
 };
 
-/*
- * visornic_serverdown_complete - IOPART went down, pause device
- * @work: Work queue it was scheduled on
+/* visornic_serverdown_complete - pause device following IOPART going down
+ * @devdata: Device managed by IOPART.
  *
- * The IO partition has gone down and we need to do some cleanup
- * for when it comes back. Treat the IO partition as the link
- * being down.
- * Returns void.
+ * The IO partition has gone down, and we need to do some cleanup for when it
+ * comes back. Treat the IO partition as the link being down.
  */
 static void visornic_serverdown_complete(struct visornic_devdata *devdata)
 {
@@ -373,13 +368,14 @@ static void visornic_serverdown_complete(struct 
visornic_devdata *devdata)
devdata->server_down_complete_func = NULL;
 }
 
-/*
- * visornic_serverdown - Command has notified us that IOPART is down
- * @devdata: device that is being managed by IOPART
+/* visornic_serverdown - Command has notified us that IOPART is down
+ * @devdata:  Device managed by IOPART.
+ * @complete_func: Function to call when finished.
+ *
+ * Schedule the work needed to handle the server down request. Make sure we
+ * haven't already handled the server change state event.
  *
- * Schedule the work needed to handle the server down request. Make
- * sure we haven't already handled the server change state event.
- * Returns 0 if we scheduled the work, -EINVAL on error.
+ * Return: 0 if we scheduled the work, negative integer on error.
  */
 static int visornic_serverdown(struct visornic_devdata *devdata,
   visorbus_state_complete_func complete_func)
@@ -419,13 +415,13 @@ static int visornic_serverdown(struct visornic_devdata 
*devdata,
return err;
 }
 
-/*
- * alloc_rcv_buf   - alloc rcv buffer to be given to the IO Partition.
- * @netdev: network adapter the rcv bufs are attached too.
+/* alloc_rcv_buf - alloc rcv buffer to be given to the IO Partition
+ * @netdev: Network adapter the rcv bufs are attached too.
+ *
+ * Create an sk_buff (rcv_buf) that will be passed to the IO Partition
+ * so that it can write rcv data into our memory space.
  *
- * Create an sk_buff (rcv_buf) that will be passed to the IO Partition
- * so that it can write rcv data into our memory space.
- * Return pointer to sk_buff
+ * Return: Pointer to sk_buff.
  */
 static struct sk_buff *alloc_rcv_buf(struct net_device *netdev)
 {
@@ -449,14 +445,12 @@ static struct sk_buff *alloc_rcv_buf(struct net_device 
*netdev)
return skb;
 }
 
-/*
- * post_skb- post a skb to the IO Partition.
- * @cmdrsp: cmdrsp packet to be send to the IO Partition
- * @devdata: visornic_devdata to post the skb too
- * @skb: skb to give to the IO partition
+/* post_skb - post a skb to the IO Partition
+ * @cmdrsp:  Cmdrsp packet to be send to the IO Partition.
+ * @devdata: visornic_devdata to post the skb to.
+ * @skb: Skb to give to the IO partition.
 

[PATCH 08/28] staging: unisys: visorbus: Convert macros to functions.

[David Kershner]

Several macros in visorchannel.c were doing complex arithmetic, converted
them to functions so that valid type checking could be done.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 25 +++
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 3969217..81e428a 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -155,17 +155,22 @@ void *visorchannel_get_header(struct visorchannel 
*channel)
  * Return offset of a specific SIGNAL_QUEUE_HEADER from the beginning of a
  * channel header
  */
-#define SIG_QUEUE_OFFSET(chan_hdr, q) \
-   ((chan_hdr)->ch_space_offset + \
-((q) * sizeof(struct signal_queue_header)))
+int sig_queue_offset(struct channel_header *chan_hdr, int q)
+{
+   return ((chan_hdr)->ch_space_offset +
+  ((q) * sizeof(struct signal_queue_header)));
+}
 
 /*
  * Return offset of a specific queue entry (data) from the beginning of a
  * channel header
  */
-#define SIG_DATA_OFFSET(chan_hdr, q, sig_hdr, slot) \
-   (SIG_QUEUE_OFFSET(chan_hdr, q) + (sig_hdr)->sig_base_offset + \
-((slot) * (sig_hdr)->signal_size))
+int sig_data_offset(struct channel_header *chan_hdr, int q,
+   struct signal_queue_header *sig_hdr, int slot)
+{
+   return (sig_queue_offset(chan_hdr, q) + sig_hdr->sig_base_offset +
+  (slot * sig_hdr->signal_size));
+}
 
 /*
  * Write the contents of a specific field within a SIGNAL_QUEUE_HEADER back
@@ -173,7 +178,7 @@ void *visorchannel_get_header(struct visorchannel *channel)
  */
 #define SIG_WRITE_FIELD(channel, queue, sig_hdr, FIELD) \
visorchannel_write(channel, \
-  SIG_QUEUE_OFFSET(>chan_hdr, queue) + \
+  sig_queue_offset(>chan_hdr, queue) + \
   offsetof(struct signal_queue_header, FIELD), \
   &((sig_hdr)->FIELD), \
   sizeof((sig_hdr)->FIELD))
@@ -186,7 +191,7 @@ static int sig_read_header(struct visorchannel *channel, 
u32 queue,
 
/* Read the appropriate SIGNAL_QUEUE_HEADER into local memory. */
return visorchannel_read(channel,
-SIG_QUEUE_OFFSET(>chan_hdr, queue),
+sig_queue_offset(>chan_hdr, queue),
 sig_hdr, sizeof(struct signal_queue_header));
 }
 
@@ -194,7 +199,7 @@ static int sig_read_data(struct visorchannel *channel, u32 
queue,
 struct signal_queue_header *sig_hdr, u32 slot,
 void *data)
 {
-   int signal_data_offset = SIG_DATA_OFFSET(>chan_hdr, queue,
+   int signal_data_offset = sig_data_offset(>chan_hdr, queue,
 sig_hdr, slot);
 
return visorchannel_read(channel, signal_data_offset,
@@ -205,7 +210,7 @@ static int sig_write_data(struct visorchannel *channel, u32 
queue,
  struct signal_queue_header *sig_hdr, u32 slot,
  void *data)
 {
-   int signal_data_offset = SIG_DATA_OFFSET(>chan_hdr, queue,
+   int signal_data_offset = sig_data_offset(>chan_hdr, queue,
 sig_hdr, slot);
 
return visorchannel_write(channel, signal_data_offset,
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 00/28] staging: unisys: More updates to make the code more readable.

[David Kershner]

Checkpatch cleanups and other misc cleanups.

David Binder (3):
  staging: unisys: visornic: Fix up existing function comments.
  staging: unisys: visornic: Fix miscellaneous block comment format issues.
  staging: unisys: visornic: Remove unnecessary return values

David Kershner (21):
  staging: unisys: use the kernel min define
  staging: unisys: visorbus: Clean up vmcall address function.
  staging: unisys: visorbus: Fix parameter alignment.
  staging: unisys: visorbus: Convert macros to functions.
  staging: unisys: visorbus: Use __func__ instead of name.
  staging: unisys: Don't check for null before getting driver device.
  staging: unisys: include: Add comment next to mutex.
  staging: unisys: visorbus: Consolidate controlvm channel creation.
  staging: unisys: visorbus: Remove useless comment.
  staging: unisys: visorbus: Remove useless initialization.
  staging: unisys: visorbus: Remove check for valid parm_addr.
  staging: unisys: visorbus: Split else if blocks into multiple if.
  staging: unisys: Change data to point to visor_controlvm_parameters_header.
  staging: unisys: visorbus: Remove useless else clause in 
visorutil_spar_detect.
  staging: unisys: visorbus: remove uneeded initializations
  staging: unisys: visorbus: Move parser functions location in file.
  staging: unisys: visorchipset: Shorten parser_init_byte_stream.
  staging: unisys: visorbus: use all 80 characters for multi-line messages
  staging: unisys: Use size of channel defined in the channel.
  staging: unisys: visorbus: just check for GUID
  staging: unisys: visorbus: Fix up GUID definition

Sameer Wadgaonkar (4):
  staging: unisys: visorbus: visorchipset.c: Fix bug in parser_init_byte_stream.
  staging: unisys: visorbus: visorbus_main.c: Fix return values for checks in 
visorbus_register_visor_driver.
  staging: unisys: visorbus: remove EXPORT_SYMBOL_GPL for visor_check_channel
  staging: unisys: change pr_err to dev_err in visor_check_channel

 drivers/staging/unisys/include/iochannel.h |   3 +-
 drivers/staging/unisys/include/visorbus.h  |  16 +-
 drivers/staging/unisys/visorbus/visorbus_main.c|  54 +-
 drivers/staging/unisys/visorbus/visorbus_private.h |  10 +-
 drivers/staging/unisys/visorbus/visorchannel.c |  81 +--
 drivers/staging/unisys/visorbus/visorchipset.c | 261 +++-
 drivers/staging/unisys/visornic/visornic_main.c| 451 ++
 7 files changed, 386 insertions(+), 490 deletions(-)

base-commit: 423a8a6eac2432a50e7ca4e4342a41ad3cf951e7
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 06/28] staging: unisys: visorbus: Clean up vmcall address function.

[David Kershner]

The function vmcall address needed to be cleaned up. The structure
vmcall_controlvm_addr was not needed so it was removed and was replaced
with vmcall_io_controlvm_addr_params since it needs to be allocated on the
heap for DMA access.

With the structure removed and the fields as local variables, it helped
clean up the formatting of the function.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index e296df7..7423c9e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -86,12 +86,6 @@ struct vmcall_io_controlvm_addr_params {
u8 unused[4];
 } __packed;
 
-struct vmcall_controlvm_addr {
-   struct vmcall_io_controlvm_addr_params params;
-   int err;
-   u64 physaddr;
-};
-
 struct visorchipset_device {
struct acpi_device *acpi_device;
unsigned long poll_jiffies;
@@ -109,7 +103,7 @@ struct visorchipset_device {
 */
struct controlvm_message controlvm_pending_msg;
bool controlvm_pending_msg_valid;
-   struct vmcall_controlvm_addr controlvm_addr;
+   struct vmcall_io_controlvm_addr_params controlvm_params;
 };
 
 static struct visorchipset_device *chipset_dev;
@@ -1341,15 +1335,16 @@ static int unisys_vmcall(unsigned long tuple, unsigned 
long param)
 static unsigned int issue_vmcall_io_controlvm_addr(u64 *control_addr,
   u32 *control_bytes)
 {
-   chipset_dev->controlvm_addr.physaddr = virt_to_phys(
-  _dev->controlvm_addr.params);
-   chipset_dev->controlvm_addr.err = unisys_vmcall(VMCALL_CONTROLVM_ADDR,
- chipset_dev->controlvm_addr.physaddr);
-   if (chipset_dev->controlvm_addr.err)
-   return chipset_dev->controlvm_addr.err;
-
-   *control_addr = chipset_dev->controlvm_addr.params.address;
-   *control_bytes = chipset_dev->controlvm_addr.params.channel_bytes;
+   u64 physaddr;
+   int err;
+
+   physaddr = virt_to_phys(_dev->controlvm_params);
+   err = unisys_vmcall(VMCALL_CONTROLVM_ADDR, physaddr);
+   if (err)
+   return err;
+
+   *control_addr = chipset_dev->controlvm_params.address;
+   *control_bytes = chipset_dev->controlvm_params.channel_bytes;
 
return 0;
 }
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 03/28] staging: unisys: visorbus: visorbus_main.c: Fix return values for checks in visorbus_register_visor_driver.

[David Kershner]

From: Sameer Wadgaonkar 

The error return values for the drv->probe, drv->remove, drv->pause
and drv->resume checks should be -EINVAL instead of -ENODEV.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index d9b0a8b..05b632e 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -969,16 +969,16 @@ int visorbus_register_visor_driver(struct visor_driver 
*drv)
return -ENODEV;
 
if (!drv->probe)
-   return -ENODEV;
+   return -EINVAL;
 
if (!drv->remove)
-   return -ENODEV;
+   return -EINVAL;
 
if (!drv->pause)
-   return -ENODEV;
+   return -EINVAL;
 
if (!drv->resume)
-   return -ENODEV;
+   return -EINVAL;
 
drv->driver.name = drv->name;
drv->driver.bus = _type;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 02/28] staging: unisys: visorbus: visorchipset.c: Fix bug in parser_init_byte_stream.

[David Kershner]

From: Sameer Wadgaonkar 

This patch fixes a bug in the function parser_init_byte_stream()
by removing the call to parser_done from goto err_finish_ctx.
The function parser_done() decrements
chipset_dev->controlvm_payload_bytes_buffered which is not
incremented before this gets called.

Signed-off-by: Sameer Wadgaonkar 
Reported-by: Dan Carpenter 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 25a30a4..e296df7 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1505,7 +1505,7 @@ static struct parser_context *parser_init_byte_stream(u64 
addr, u32 bytes,
return ctx;
 
 err_finish_ctx:
-   parser_done(ctx);
+   kfree(ctx);
return NULL;
 }
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 01/28] staging: unisys: use the kernel min define

[David Kershner]

The kernel already provides a min function, we should be using that
instead of creating our own MINNUM.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h  |  3 ---
 drivers/staging/unisys/visornic/visornic_main.c |  9 -
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 9562947..a70760f 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -61,9 +61,6 @@
  * IO Partition is defined below.
  */
 
-/* Defines and enums. */
-#define MINNUM(a, b) (((a) < (b)) ? (a) : (b))
-
 /*
  * Define the two queues per data channel between iopart and ioguestparts.
  * IOCHAN_TO_IOPART -- used by guest to 'insert' signals to iopart.
diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 3db4148..0c29d53 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -198,12 +198,11 @@ struct visornic_devdata {
 };
 
 /* Returns next non-zero index on success or 0 on failure (i.e. out of room). 
*/
-static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, u32 inp_len,
+static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, u16 inp_len,
u16 index, u16 max_pi_arr_entries,
struct phys_info pi_arr[])
 {
-   u32 len;
-   u16 i, firstlen;
+   u16 i, len, firstlen;
 
firstlen = PI_PAGE_SIZE - inp_off;
if (inp_len <= firstlen) {
@@ -227,8 +226,8 @@ static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, 
u32 inp_len,
pi_arr[index].pi_len = firstlen;
} else {
pi_arr[index + i].pi_off = 0;
-   pi_arr[index + i].pi_len =
-   (u16)MINNUM(len, (u32)PI_PAGE_SIZE);
+   pi_arr[index + i].pi_len = min_t(u16, len,
+PI_PAGE_SIZE);
}
}
return index + i;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 net-next] staging: irda: fix init level for irda core

[David Miller]

From: Greg KH 
Date: Wed, 30 Aug 2017 13:16:49 +0200

> When moving the IRDA code out of net/ into drivers/staging/irda/net, the
> link order changes when IRDA is built into the kernel.  That causes a
> kernel crash at boot time as netfilter isn't initialized yet.
> 
> To fix this, move the init call level of the irda core to be
> device_initcall() as the link order keeps this being initialized at the
> correct time.
> 
> Reported-by: kernel test robot 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Greg Kroah-Hartman 
> ---
> 
> v3 - just change the initcall level, works so much simpler, thanks to
>  DaveM for the idea.
> v2 - don't force irda to be a module, make the Makefiles put irda back
>  where it was before in the link order.

Applied, thanks for following up on this Greg.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 09/11] power: supply: bq24190_charger: Get input_current_limit from our supplier

[Sebastian Reichel]

Hi,

On Wed, Aug 30, 2017 at 07:47:46AM -0700, Tony Lindgren wrote:
> * Hans de Goede  [170830 02:49]:
> > On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> > done by a separate port-controller IC, while the current limit is
> > controlled through another (charger) IC.
> > 
> > It has been decided to model this by modelling the external Type-C
> > power brick (adapter/charger) as a power-supply class device which
> > supplies the charger-IC, with its voltage-now and current-max representing
> > the negotiated voltage and max current draw.
> > 
> > This commit adds support for this to the bq24190_charger driver by adding
> > an external_power_changed callback and calling
> > power_supply_set_input_current_limit_from_supplier from this callback.
> > This callback will only get called if the bq24190 has a parent-supply.
> > 
> > Note this replaces the functionality to get the current-limit from an
> > extcon device, which will be removed in a follow-up commit.
> > 
> > Signed-off-by: Hans de Goede 
> 
> Acked-by: Tony Lindgren 

Thanks, queued.

-- Sebastian


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

Re: [PATCH v3 08/11] power: supply: bq24190_charger: Export 5V boost converter as regulator

[Sebastian Reichel]

Hi,

On Wed, Aug 30, 2017 at 07:46:50AM -0700, Tony Lindgren wrote:
> * Hans de Goede  [170830 02:49]:
> > Register the 5V boost converter as a regulator named "usb_otg_vbus".
> > 
> > This commit also adds support for bq24190_platform_data, through which
> > non device-tree platforms can pass the regulator_init_data (containing
> > mappings for the consumer amongst other things).
> > 
> > Signed-off-by: Hans de Goede 
> 
> This will make it easy for USB PHY drivers to implement USB host mode:
> 
> Acked-by: Tony Lindgren 

Thanks, queued.

-- Sebastian


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

Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG

[Larry Finger]

On 08/30/2017 02:58 AM, Andreas Ziegler wrote:

Indeed, sorry I missed that as well.

So what should we make of that #ifdef? The code inside it doesn't compile
(anymore? I didn't find any development history for that patch except the
original mail), as there is no definition of struct submit_ctx in the headers
(for other rtl drivers - 8188eu, 8723bs - that struct lives in
include/rtw_xmit.h). Is a comparable header simply missing?

Regards,

Andreas


Andreas,

I'm sorry that I did not have time yesterday to properly analyze the situation. 
All I knew is that your patch was not the correct one. It turns out that the 
extra code was left over from the original writing/testing of the driver and 
should have been deleted. I have prepared a patch that does that and will submit 
it soon.


When the extraneous code was deleted, addition simplifications of the code were 
apparent. I am currently testing that change, and will submit the two patches at 
the same time.


Larry


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

Re: [PATCH] storvsc: fix memory leak on ring buffer busy

[Stephen Hemminger]

On Tue, 29 Aug 2017 21:31:11 -0400
"Martin K. Petersen"  wrote:

> Long,
> 
> > When storvsc is sending I/O to Hyper-v, it may allocate a bigger
> > buffer descriptor for large data payload that can't fit into a
> > pre-allocated buffer descriptor. This bigger buffer is freed on return
> > path.
> >
> > If I/O request to Hyper-v fails due to ring buffer busy, the storvsc
> > allocated buffer descriptor should also be freed.  
> 
> Which kernel version is this patch aimed at?
> 

Looks like this an old issue. Probably should add

Fixes: be0cf6ca301c ("scsi: storvsc: Set the tablesize based on the information 
given by the host")
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 09/11] power: supply: bq24190_charger: Get input_current_limit from our supplier

[Tony Lindgren]

* Hans de Goede  [170830 02:49]:
> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> done by a separate port-controller IC, while the current limit is
> controlled through another (charger) IC.
> 
> It has been decided to model this by modelling the external Type-C
> power brick (adapter/charger) as a power-supply class device which
> supplies the charger-IC, with its voltage-now and current-max representing
> the negotiated voltage and max current draw.
> 
> This commit adds support for this to the bq24190_charger driver by adding
> an external_power_changed callback and calling
> power_supply_set_input_current_limit_from_supplier from this callback.
> This callback will only get called if the bq24190 has a parent-supply.
> 
> Note this replaces the functionality to get the current-limit from an
> extcon device, which will be removed in a follow-up commit.
> 
> Signed-off-by: Hans de Goede 

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

Re: [PATCH v3 08/11] power: supply: bq24190_charger: Export 5V boost converter as regulator

[Tony Lindgren]

* Hans de Goede  [170830 02:49]:
> Register the 5V boost converter as a regulator named "usb_otg_vbus".
> 
> This commit also adds support for bq24190_platform_data, through which
> non device-tree platforms can pass the regulator_init_data (containing
> mappings for the consumer amongst other things).
> 
> Signed-off-by: Hans de Goede 

This will make it easy for USB PHY drivers to implement USB host mode:

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

Re: [PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev

[Guenter Roeck]

On 08/30/2017 02:48 AM, Hans de Goede wrote:

The fusb302 Type-C port-controller cannot control the current-limit
directly, so we need to exported the limit so that another driver
(e.g. the charger driver) can pick the limit up and configure the
system accordingly.

The power-supply subsys already provides infrastructure for this,
power-supply devices have the notion of being supplied by another
power-supply and have properties through which we can export the
current-limit.

Register a power_supply and export the current-limit through the
power_supply's current-max property.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
Changes in v2:
-Put the psy class device code directly in fusb302.c rather then introducing
  helpers which are only used by fusb302.c
-Add an online property to the psy so that upower does not mistake it for a
  second battery in the system
---
  drivers/staging/typec/fusb302/Kconfig   |  2 +-
  drivers/staging/typec/fusb302/fusb302.c | 63 +++--
  2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/Kconfig 
b/drivers/staging/typec/fusb302/Kconfig
index fce099ff39fe..48a4f2fcee03 100644
--- a/drivers/staging/typec/fusb302/Kconfig
+++ b/drivers/staging/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
  config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C
+   depends on I2C && POWER_SUPPLY
help
  The Fairchild FUSB302 Type-C chip driver that works with
  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 6f007f66d597..cf6355f59cd9 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -108,6 +109,11 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
  
+	/* psy + psy status */

+   struct power_supply *psy;
+   u32 current_limit;
+   u32 supply_voltage;
+
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -876,11 +882,13 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
-   if (chip->charge_on == charge)
+   if (chip->charge_on == charge) {
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
-   else
+   } else {
chip->charge_on = charge;
+   power_supply_changed(chip->psy);
+   }
  
  done:

mutex_unlock(>lock);
@@ -896,6 +904,11 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
  
+	chip->supply_voltage = mv;

+   chip->current_limit = max_ma;
+
+   power_supply_changed(chip->psy);
+
return 0;
  }
  
@@ -1681,6 +1694,43 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)

return IRQ_HANDLED;
  }
  
+static int fusb302_psy_get_property(struct power_supply *psy,

+   enum power_supply_property psp,
+   union power_supply_propval *val)
+{
+   struct fusb302_chip *chip = power_supply_get_drvdata(psy);
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_ONLINE:
+   val->intval = chip->charge_on;
+   break;
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+   val->intval = chip->supply_voltage * 1000; /* mV -> µV */
+   break;
+   case POWER_SUPPLY_PROP_CURRENT_MAX:
+   val->intval = chip->current_limit * 1000; /* mA -> µA */
+   break;
+   default:
+   return -ENODATA;
+   }
+
+   return 0;
+}
+
+static enum power_supply_property fusb302_psy_properties[] = {
+   POWER_SUPPLY_PROP_ONLINE,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_MAX,
+};
+
+const struct power_supply_desc fusb302_psy_desc = {
+   .name   = "fusb302-typec-source",
+   .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
+   .properties = fusb302_psy_properties,
+   .num_properties = ARRAY_SIZE(fusb302_psy_properties),
+   .get_property   = fusb302_psy_get_property,
+};
+
  static int init_gpio(struct fusb302_chip *chip)
  {
struct device_node *node;
@@ -1720,6 +1770,7 @@ static int fusb302_probe(struct i2c_client *client,
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
struct device *dev = >dev;
+   struct power_supply_config cfg = 

Re: [PATCH v3 06/11] staging: typec: fusb302: Add support for USB2 charger detection through extcon

[Guenter Roeck]

On 08/30/2017 02:48 AM, Hans de Goede wrote:

The fusb302 port-controller relies on an external device doing USB2
charger-type detection.

The Intel Whiskey Cove PMIC with which the fusb302 is combined on some
X86/ACPI platforms already has a charger-type detection driver which
uses extcon to communicate the detected charger-type.

Rather then inventing a new API for USB2 charger-type detection
specifically for use with the tcpm code, this commit simply re-uses the
existing extcon API and uses that do USB2 charger detection.

Note that the "fcs,extcon-name" property name is only for kernel internal
use by X86/ACPI platform code and as such is NOT documented in
the fusb302 devicetree bindings.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
Changes in v2:
-Put extcon code directly in fusb302.c rather then introducing helpers
  which are only used by fusb302.c

Changes in v3:
-Improve commit message
---
  drivers/staging/typec/fusb302/fusb302.c | 49 +
  1 file changed, 49 insertions(+)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 675161cf4f3a..6f007f66d597 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -96,6 +97,7 @@ struct fusb302_chip {
  
  	int gpio_int_n;

int gpio_int_n_irq;
+   struct extcon_dev *extcon;
  
  	struct workqueue_struct *wq;

struct delayed_work bc_lvl_handler;
@@ -516,6 +518,38 @@ static int tcpm_get_vbus(struct tcpc_dev *dev)
return ret;
  }
  
+static int tcpm_get_current_limit(struct tcpc_dev *dev)

+{
+   struct fusb302_chip *chip = container_of(dev, struct fusb302_chip,
+tcpc_dev);
+   int current_limit = 0;
+   unsigned long timeout;
+
+   if (!chip->extcon)
+   return 0;
+
+   /*
+* USB2 Charger detection may still be in progress when we get here,
+* this can take upto 600ms, wait 800ms max.
+*/
+   timeout = jiffies + msecs_to_jiffies(800);
+   do {
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_SDP) == 1)
+   current_limit = 500;
+
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_CDP) == 1 ||
+   extcon_get_state(chip->extcon, EXTCON_CHG_USB_ACA) == 1)
+   current_limit = 1500;
+
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_DCP) == 1)
+   current_limit = 2000;
+
+   msleep(50);
+   } while (current_limit == 0 && time_before(jiffies, timeout));
+
+   return current_limit;
+}
+
  static int fusb302_set_cc_pull(struct fusb302_chip *chip,
   bool pull_up, bool pull_down)
  {
@@ -1201,6 +1235,7 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
  {
fusb302_tcpc_dev->init = tcpm_init;
fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
+   fusb302_tcpc_dev->get_current_limit = tcpm_get_current_limit;
fusb302_tcpc_dev->set_cc = tcpm_set_cc;
fusb302_tcpc_dev->get_cc = tcpm_get_cc;
fusb302_tcpc_dev->set_polarity = tcpm_set_polarity;
@@ -1685,6 +1720,7 @@ static int fusb302_probe(struct i2c_client *client,
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
struct device *dev = >dev;
+   const char *name;
int ret = 0;
u32 v;
  
@@ -1717,6 +1753,19 @@ static int fusb302_probe(struct i2c_client *client,

if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", ))
chip->tcpc_config.operating_snk_mw = v / 1000;
  
+	/*

+* Devicetree platforms should get extcon via phandle (not yet
+* supported). On ACPI platforms, we get the name from a device prop.
+* This device prop is for kernel internal use only and is expected
+* to be set by the platform code which also registers the i2c client
+* for the fusb302.
+*/
+   if (device_property_read_string(dev, "fcs,extcon-name", ) == 0) {
+   chip->extcon = extcon_get_extcon_dev(name);
+   if (!chip->extcon)
+   return -EPROBE_DEFER;
+   }
+
ret = fusb302_debugfs_init(chip);
if (ret < 0)
return ret;



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

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

[Christoph Hellwig]

On Wed, Aug 30, 2017 at 03:46:34PM +0200, Rafael J. Wysocki wrote:
> 3689d3d69072 ACPI: device property: Switch to use new generic UUID API
> 
> in my linux-next branch.  Isn't it this one?

Yes, that should be it.  Somehow my linux-next tree seems to be
a mess through or my git log skills aren't what they used to be
anymore.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set

[Guenter Roeck]

On 08/30/2017 02:48 AM, Hans de Goede wrote:

The fusb302 is also used on x86 systems where the platform code sets
the irq in client->irq and there is no gpio named fcs,int_n.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/staging/typec/fusb302/fusb302.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 1c1751c994db..675161cf4f3a 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1735,9 +1735,13 @@ static int fusb302_probe(struct i2c_client *client,
goto destroy_workqueue;
}
  
-	ret = init_gpio(chip);

-   if (ret < 0)
-   goto destroy_workqueue;
+   if (client->irq) {
+   chip->gpio_int_n_irq = client->irq;
+   } else {
+   ret = init_gpio(chip);
+   if (ret < 0)
+   goto destroy_workqueue;
+   }
  
  	chip->tcpm_port = tcpm_register_port(>dev, >tcpc_dev);

if (IS_ERR(chip->tcpm_port)) {



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

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

[Rafael J. Wysocki]

On Wednesday, August 30, 2017 2:41:41 PM CEST Christoph Hellwig wrote:
> On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote:
> > > >> > Cc: "Rafael J. Wysocki" 
> > > >> > Cc: Mika Westerberg 
> > > >>
> > > >> Acked-by: Mika Westerberg 
> > > >
> > > > OK
> > > >
> > > > Andy, do you want me to apply this?
> > > 
> > > If you would like to.
> > > 
> > > The patch is now pretty independent since necessary stuff made v4.13-rc1.
> > 
> > OK
> 
> This didn't seem to make it into linux-next so far, though.

I have

3689d3d69072 ACPI: device property: Switch to use new generic UUID API

in my linux-next branch.  Isn't it this one?

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

Re: [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

[Guenter Roeck]

On 08/30/2017 02:48 AM, Hans de Goede wrote:

This is board specific info so it should come from board config, such
as devicetree.

I've chosen to prefix these with "fcs," treating them as fusb302 driver
specific for now. We may want to revisit this and replace these with
properties which are part of a (to be written) generic type-c controller
devicetree binding.

Since this commit adds new dt-properties it also adds devicetree-bindings
documentation (which so far was absent for the fusb302 driver).

Cc: Rob Herring 
Cc: Frank Rowand 
Cc: devicet...@vger.kernel.org
Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
Acked-by: Rob Herring 


Reviewed-by: Guenter Roeck 


---
Changes in v2:
-Use micro... instead of mili...
-Add devicetree bindings documentation

Changes in v3:
-Use sink rather then snk in property names
-Add Rob's Acked-by
---
  .../devicetree/bindings/usb/fcs,fusb302.txt| 29 ++
  drivers/staging/typec/fusb302/TODO |  4 +++
  drivers/staging/typec/fusb302/fusb302.c| 18 +-
  3 files changed, 50 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/usb/fcs,fusb302.txt

diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt 
b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
new file mode 100644
index ..472facfa5a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -0,0 +1,29 @@
+Fairchild FUSB302 Type-C Port controllers
+
+Required properties :
+- compatible : "fcs,fusb302"
+- reg: I2C slave address
+- interrupts : Interrupt specifier
+
+Optional properties :
+- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink
+- fcs,max-sink-microamp  : Maximum current to negotiate when configured as sink
+- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink
+  If this is less then max-sink-microvolt *
+  max-sink-microamp then the configured current will
+  be clamped.
+- fcs,operating-sink-microwatt :
+  Minimum amount of power accepted from a sink
+  when negotiating
+
+Example:
+
+fusb302: typec-portc@54 {
+   compatible = "fcs,fusb302";
+   reg = <0x54>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   fcs,max-sink-microvolt = <1200>;
+   fcs,max-sink-microamp = <300>;
+   fcs,max-sink-microwatt = <3600>;
+};
diff --git a/drivers/staging/typec/fusb302/TODO 
b/drivers/staging/typec/fusb302/TODO
index 4933a1d92c32..19b466eb585d 100644
--- a/drivers/staging/typec/fusb302/TODO
+++ b/drivers/staging/typec/fusb302/TODO
@@ -4,3 +4,7 @@ fusb302:
  - Find a non-hacky way to coordinate between PM and I2C access
  - Documentation? The FUSB302 datasheet provides information on the chip to 
help
understand the code. But it may still be helpful to have a documentation.
+- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
+  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
+  properties with properties which are part of a generic type-c controller
+  devicetree binding.
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 6baed06a3c0d..1c1751c994db 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -90,6 +90,7 @@ struct fusb302_chip {
struct i2c_client *i2c_client;
struct tcpm_port *tcpm_port;
struct tcpc_dev tcpc_dev;
+   struct tcpc_config tcpc_config;
  
  	struct regulator *vbus;
  
@@ -1198,7 +1199,6 @@ static const struct tcpc_config fusb302_tcpc_config = {
  
  static void init_tcpc_dev(struct tcpc_dev *fusb302_tcpc_dev)

  {
-   fusb302_tcpc_dev->config = _tcpc_config;
fusb302_tcpc_dev->init = tcpm_init;
fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
fusb302_tcpc_dev->set_cc = tcpm_set_cc;
@@ -1684,7 +1684,9 @@ static int fusb302_probe(struct i2c_client *client,
  {
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
+   struct device *dev = >dev;
int ret = 0;
+   u32 v;
  
  	adapter = to_i2c_adapter(client->dev.parent);

if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_I2C_BLOCK)) {
@@ -1699,8 +1701,22 @@ static int fusb302_probe(struct i2c_client *client,
chip->i2c_client = client;
i2c_set_clientdata(client, chip);
chip->dev = >dev;
+   chip->tcpc_config = fusb302_tcpc_config;
+   chip->tcpc_dev.config = >tcpc_config;
mutex_init(>lock);
  
+	if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", ))

+   chip->tcpc_config.max_snk_mv = v / 1000;
+

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

[Ulf Hansson]

On 30 August 2017 at 14:44, Hans de Goede  wrote:
> Hi,
>
>
> On 21-07-17 16:35, Quentin Schulz wrote:
>>
>> From: Hans de Goede 
>>
>> Some sdio devices have a multiple stage bring-up process. Specifically
>> the esp8089 (for which an out of tree driver is available) loads firmware
>> on the first call to its sdio-drivers' probe function and then resets
>> the device causing it to reboot from its RAM with the new firmware.
>>
>> When this sdio device reboots it comes back up in 1 bit 400 KHz mode
>> again, and we need to walk through the whole ios negatiation and sdio
>> setup
>> again.
>>
>> There are 2 problems with this:
>>
>> 1) Typically these devices are soldered onto some (ARM) tablet / SBC
>> PCB and as such are described in devicetree as "non-removable", which
>> causes the mmc-core to scan them only once and not poll for the device
>> dropping of the bus. Normally this is the right thing todo but in the
>> eso8089 example we need the mmc-core to notice the module has disconnected
>> (since it is now in 1 bit mode again it will not talk to the host in 4 bit
>> mode). This can be worked around by using "broken-cd" in devicetree
>> instead of "non-removable", but that is not a proper fix since the device
>> really is non-removable.
>>
>> 2) When the mmc-core detects the device has disconnected it will poweroff
>> the device, causing the RAM loaded firmware to be lost. This can be worked
>> around in devicetree by using regulator-always-on (and avoiding the use of
>> mmc-pwrseq), but again that is more of a hack then a proper fix.
>>
>> This commmit fixes 1) by adding a mmc_force_detect_change function which
>> will cause scanning for device removal / insertion until a new device is
>> detected. 2) Is fixed by a keep_power flag to the mmc_force_detect_change
>> function which when set causes the mmc-core to keep the power to the
>> device
>> on during the rescan.
>>
>> Cc: Icenowy Zheng 
>> Cc: Maxime Ripard 
>> Cc: Chen-Yu Tsai 
>> Signed-off-by: Hans de Goede 
>
>
> So when I posted this patch quite a while back, there was some discussion
> about this and a consensus that this is not the right solution.
>
> So first of all lets describe the problem:
>
> The esp8089 sdio wifi chip is really an ARM core with a wifi phy
> connected to it (as many wifi chipsets are).
>
> But this one comes up in some really generic sdio capable boot-loader
> mode and we need to feed it firmware and then reboot it into the
> new firmware.
>
> The reboot is where the problems happens. It seems to fallback
> from the negotiated 4 wire sdio mode to single wire spi mode then.
>
> The out of tree version of the driver deals with this by not setting
> the non-removable flag as well as setting the broken_cd flag so that
> the mmc core polls the device, after the reboot the poll fails
> because the mmc-controller and the esp8089 are using a different
> amount of wires so the mmc-cmd the poll uses times out.
>
> After which the esp8089 drivers remove function gets called, and
> the mmc stack re-discovers the esp8089 by restarting the whole
> number of wires (and speed) used negotiation. After which the
> esp8089 driver's probe function gets called (again) and on
> firmware loading is has set a global flag, so now it actually
> acts as a wifi driver rather then trying to load the firmware
> a second time.
>
> Since I did not want to rely on broken_cd polling I came up
> with the hack which is this patch.
>
> So when this patch was first discussed we came to the conclusion
> that what we really need is some sort of mmc_reprobe_device
> function which the driver can call from probe which will
> redo the number of wires (and speed) used negotiation,
> while keeping the sdio_function device as is so that probe can
> simply continue after this and we also don't need the ugly
> global flag.
>
> The idea would be for this function to be some wrapper
> around mmc_init_card() which resets the ios settings as is
> normally done on remove and then call mmc_init_card()
> passing in the existing card the same way as is done
> one resume, so that the existing card / sdio_function
> devices get reused.
>
> IIRC Ulf would look into writing this mmc_reprobe_device
> function and then I would test it with the esp8089, but
> Ulf never got around to writing the function and I ended
> up working on other things too.

Thanks for summary!

Just to let you know, I haven't forgot about this problem. I am
planning for a major update of the SDIO for power management support,
within a not too far future.
The issue described above, is then also one of the things I also plan
to look into.

However, if there anybody that wants to hack on this, feel free to do it!

Kind regards
Uffe
___
devel mailing list
de...@linuxdriverproject.org

Re: [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V

[Guenter Roeck]

On 08/30/2017 02:48 AM, Hans de Goede wrote:

Anything higher then 5V may damage hardware not capable of it, so
the only sane default here is 5V. If a board is able to handle a
higher voltage that should come from board specific data such as
device-tree and not be hard coded into the fusb302 code.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/staging/typec/fusb302/fusb302.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 03a3809d18f0..6baed06a3c0d 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1187,9 +1187,9 @@ static const struct tcpc_config fusb302_tcpc_config = {
.nr_src_pdo = ARRAY_SIZE(src_pdo),
.snk_pdo = snk_pdo,
.nr_snk_pdo = ARRAY_SIZE(snk_pdo),
-   .max_snk_mv = 9000,
+   .max_snk_mv = 5000,
.max_snk_ma = 3000,
-   .max_snk_mw = 27000,
+   .max_snk_mw = 15000,
.operating_snk_mw = 2500,
.type = TYPEC_PORT_DRP,
.default_role = TYPEC_SINK,



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

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Greg Kroah-Hartman]

On Wed, Aug 30, 2017 at 02:38:45PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> > 
> > I have just sent a v2 of this patch separately.
> 
> Greg, did you pick that patch up?

Yes, it's already in my tree and in linux-next.

thanks,

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

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Andy Shevchenko]

On Wed, 2017-08-30 at 14:38 +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> > 
> > I have just sent a v2 of this patch separately.
> 
> Greg, did you pick that patch up?

That patch in his tree.

-- 
Andy Shevchenko 
Intel Finland Oy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

[Hans de Goede]

Hi,

On 21-07-17 16:35, Quentin Schulz wrote:

From: Hans de Goede 

Some sdio devices have a multiple stage bring-up process. Specifically
the esp8089 (for which an out of tree driver is available) loads firmware
on the first call to its sdio-drivers' probe function and then resets
the device causing it to reboot from its RAM with the new firmware.

When this sdio device reboots it comes back up in 1 bit 400 KHz mode
again, and we need to walk through the whole ios negatiation and sdio setup
again.

There are 2 problems with this:

1) Typically these devices are soldered onto some (ARM) tablet / SBC
PCB and as such are described in devicetree as "non-removable", which
causes the mmc-core to scan them only once and not poll for the device
dropping of the bus. Normally this is the right thing todo but in the
eso8089 example we need the mmc-core to notice the module has disconnected
(since it is now in 1 bit mode again it will not talk to the host in 4 bit
mode). This can be worked around by using "broken-cd" in devicetree
instead of "non-removable", but that is not a proper fix since the device
really is non-removable.

2) When the mmc-core detects the device has disconnected it will poweroff
the device, causing the RAM loaded firmware to be lost. This can be worked
around in devicetree by using regulator-always-on (and avoiding the use of
mmc-pwrseq), but again that is more of a hack then a proper fix.

This commmit fixes 1) by adding a mmc_force_detect_change function which
will cause scanning for device removal / insertion until a new device is
detected. 2) Is fixed by a keep_power flag to the mmc_force_detect_change
function which when set causes the mmc-core to keep the power to the device
on during the rescan.

Cc: Icenowy Zheng 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Signed-off-by: Hans de Goede 


So when I posted this patch quite a while back, there was some discussion
about this and a consensus that this is not the right solution.

So first of all lets describe the problem:

The esp8089 sdio wifi chip is really an ARM core with a wifi phy
connected to it (as many wifi chipsets are).

But this one comes up in some really generic sdio capable boot-loader
mode and we need to feed it firmware and then reboot it into the
new firmware.

The reboot is where the problems happens. It seems to fallback
from the negotiated 4 wire sdio mode to single wire spi mode then.

The out of tree version of the driver deals with this by not setting
the non-removable flag as well as setting the broken_cd flag so that
the mmc core polls the device, after the reboot the poll fails
because the mmc-controller and the esp8089 are using a different
amount of wires so the mmc-cmd the poll uses times out.

After which the esp8089 drivers remove function gets called, and
the mmc stack re-discovers the esp8089 by restarting the whole
number of wires (and speed) used negotiation. After which the
esp8089 driver's probe function gets called (again) and on
firmware loading is has set a global flag, so now it actually
acts as a wifi driver rather then trying to load the firmware
a second time.

Since I did not want to rely on broken_cd polling I came up
with the hack which is this patch.

So when this patch was first discussed we came to the conclusion
that what we really need is some sort of mmc_reprobe_device
function which the driver can call from probe which will
redo the number of wires (and speed) used negotiation,
while keeping the sdio_function device as is so that probe can
simply continue after this and we also don't need the ugly
global flag.

The idea would be for this function to be some wrapper
around mmc_init_card() which resets the ios settings as is
normally done on remove and then call mmc_init_card()
passing in the existing card the same way as is done
one resume, so that the existing card / sdio_function
devices get reused.

IIRC Ulf would look into writing this mmc_reprobe_device
function and then I would test it with the esp8089, but
Ulf never got around to writing the function and I ended
up working on other things too.

I HTH.

Regards,

Hans






---
  drivers/mmc/core/core.c  | 47 ++-
  include/linux/mmc/host.h |  7 +++
  2 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 26431267a3e2..103badde910b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1620,8 +1620,11 @@ int mmc_select_drive_strength(struct mmc_card *card, 
unsigned int max_dtr,
   */
  void mmc_power_up(struct mmc_host *host, u32 ocr)
  {
-   if (host->ios.power_mode == MMC_POWER_ON)
+   if (host->ios.power_mode == MMC_POWER_ON) {
+   if (host->ios.clock == 0)
+   goto set_clock;
return;
+   }
  
  	mmc_pwrseq_pre_power_on(host);
  
@@ -1646,6 

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

[Christoph Hellwig]

Thanks,

applied to the uuid for-next tree.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

[Christoph Hellwig]

On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote:
> > >> > Cc: "Rafael J. Wysocki" 
> > >> > Cc: Mika Westerberg 
> > >>
> > >> Acked-by: Mika Westerberg 
> > >
> > > OK
> > >
> > > Andy, do you want me to apply this?
> > 
> > If you would like to.
> > 
> > The patch is now pretty independent since necessary stuff made v4.13-rc1.
> 
> OK

This didn't seem to make it into linux-next so far, though.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Christoph Hellwig]

On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> Yep! There are so many conflicts that would be better just to push
> through your tree.
> 
> I have just sent a v2 of this patch separately.

Greg, did you pick that patch up?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH][staging-next] staging: pi433: fix spelling mistake: "preample" -> "preamble"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_dbg message

Signed-off-by: Colin Ian King 
---
 drivers/staging/pi433/rf69.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index f04840a799bb..c4b1b218ea38 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -678,7 +678,7 @@ int rf69_set_preamble_length(struct spi_device *spi, u16 
preambleLength)
u8 msb, lsb;
 
#ifdef DEBUG
-   dev_dbg(>dev, "set: preample length");
+   dev_dbg(>dev, "set: preamble length");
#endif
 
/* no value check needed - u16 exactly matches register size */
-- 
2.14.1

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

[PATCH] staging:rtl8188eu:core Fix Code Indent

[Janani Sankara Babu]

This patch solves the code indentation issue inside the if block

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c 
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 77bf8e2..d5e111a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -186,7 +186,7 @@ int rtw_cmd_thread(void *context)
pcmd->res = H2C_DROPPED;
} else {
if (pcmd->cmdcode < ARRAY_SIZE(wlancmds)) {
-   cmd_hdl = wlancmds[pcmd->cmdcode].h2cfuns;
+   cmd_hdl = wlancmds[pcmd->cmdcode].h2cfuns;
 
if (cmd_hdl) {
ret = cmd_hdl(pcmd->padapter, 
pcmd->parmbuf);
-- 
1.9.1

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

[PATCH] staging: goldfish: (Coding Style) Fixed parenthesis alignment.

[edvard . holst]

From: Edvard Holst 

Fixed paranthesis alignment for compliance with checkpatch.

Signed-off-by: Edvard Holst 
---
 drivers/staging/goldfish/goldfish_nand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/goldfish/goldfish_nand.c 
b/drivers/staging/goldfish/goldfish_nand.c
index e742b92bb153..52cc1363993e 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -153,7 +153,7 @@ static int goldfish_nand_read_oob(struct mtd_info *mtd, 
loff_t ofs,
ofs += mtd->writesize + ops->ooboffs;
if (ops->oobbuf)
ops->oobretlen = goldfish_nand_cmd(mtd, NAND_CMD_READ, ofs,
-   ops->ooblen, ops->oobbuf);
+  ops->ooblen, ops->oobbuf);
return 0;
 
 invalid_arg:
@@ -185,7 +185,7 @@ static int goldfish_nand_write_oob(struct mtd_info *mtd, 
loff_t ofs,
ofs += mtd->writesize + ops->ooboffs;
if (ops->oobbuf)
ops->oobretlen = goldfish_nand_cmd(mtd, NAND_CMD_WRITE, ofs,
-   ops->ooblen, ops->oobbuf);
+  ops->ooblen, ops->oobbuf);
return 0;
 
 invalid_arg:
-- 
2.13.5

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

[PATCH v3 net-next] staging: irda: fix init level for irda core

[Greg KH]

When moving the IRDA code out of net/ into drivers/staging/irda/net, the
link order changes when IRDA is built into the kernel.  That causes a
kernel crash at boot time as netfilter isn't initialized yet.

To fix this, move the init call level of the irda core to be
device_initcall() as the link order keeps this being initialized at the
correct time.

Reported-by: kernel test robot 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman 
---

v3 - just change the initcall level, works so much simpler, thanks to
 DaveM for the idea.
v2 - don't force irda to be a module, make the Makefiles put irda back
 where it was before in the link order.

 drivers/staging/irda/net/irmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/irda/net/irmod.c b/drivers/staging/irda/net/irmod.c
index c5e35b85c477..4319f4ff66b0 100644
--- a/drivers/staging/irda/net/irmod.c
+++ b/drivers/staging/irda/net/irmod.c
@@ -190,7 +190,7 @@ static void __exit irda_cleanup(void)
  *
  * Jean II
  */
-subsys_initcall(irda_init);
+device_initcall(irda_init);
 module_exit(irda_cleanup);
 
 MODULE_AUTHOR("Dag Brattli  & Jean Tourrilhes 
");
-- 
2.14.1

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

[PATCH 0/4] staging: fsl-mc: dpio: add dpseci dependencies

[Horia Geantă]

This patch set adds support for functionalities needed by the upcoming
dpseci (Data Path SEC Interface) object device driver:
-Frame List Entries (FLEs)
-Congestion State Change Notifications (CSCNs)
-Order Preservation

An RFC has been previously submitted:
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg27290.html
and crypto-specific (dpseci) patches have been ack-ed.

I am resending the dpio dependencies separately (patches 1-4 in the RFC)
for inclusion in the staging tree.

Thanks,
Horia

Horia Geantă (3):
  staging: fsl-mc: dpio: add frame list format support
  staging: fsl-mc: dpio: add congestion notification support
  staging: fsl-dpaa2/eth: move generic FD defines to DPIO

Radu Alexe (1):
  staging: fsl-mc: dpio: add order preservation support

 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c |   8 +-
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  19 +-
 drivers/staging/fsl-mc/include/dpaa2-fd.h  | 255 +
 drivers/staging/fsl-mc/include/dpaa2-io.h  |  43 +
 drivers/staging/fsl-mc/include/dpopr.h | 110 +++
 5 files changed, 416 insertions(+), 19 deletions(-)
 create mode 100644 drivers/staging/fsl-mc/include/dpopr.h

-- 
2.12.0.264.gd6db3f216544

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

[PATCH 2/4] staging: fsl-mc: dpio: add congestion notification support

[Horia Geantă]

Add support for Congestion State Change Notifications (CSCN), which
allow DPIO users to be notified when a congestion group changes its
state (due to hitting the entrance / exit threshold).

Signed-off-by: Ioana Radulescu 
Signed-off-by: Radu Alexe 
Signed-off-by: Horia Geantă 
---
 drivers/staging/fsl-mc/include/dpaa2-io.h | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/staging/fsl-mc/include/dpaa2-io.h 
b/drivers/staging/fsl-mc/include/dpaa2-io.h
index c5646096c5d4..d1bf9c1bdb67 100644
--- a/drivers/staging/fsl-mc/include/dpaa2-io.h
+++ b/drivers/staging/fsl-mc/include/dpaa2-io.h
@@ -137,4 +137,47 @@ struct dpaa2_io_store *dpaa2_io_store_create(unsigned int 
max_frames,
 void dpaa2_io_store_destroy(struct dpaa2_io_store *s);
 struct dpaa2_dq *dpaa2_io_store_next(struct dpaa2_io_store *s, int *is_last);
 
+/***/
+/* CSCN*/
+/***/
+
+/**
+ * struct dpaa2_cscn - The CSCN message format
+ * @verb: identifies the type of message (should be 0x27).
+ * @stat: status bits related to dequeuing response (not used)
+ * @state: bit 0 = 0/1 if CG is no/is congested
+ * @reserved: reserved byte
+ * @cgid: congest grp ID - the first 16 bits
+ * @ctx: context data
+ *
+ * Congestion management can be implemented in software through
+ * the use of Congestion State Change Notifications (CSCN). These
+ * are messages written by DPAA2 hardware to memory whenever the
+ * instantaneous count (I_CNT field in the CG) exceeds the
+ * Congestion State (CS) entrance threshold, signifying congestion
+ * entrance, or when the instantaneous count returns below exit
+ * threshold, signifying congestion exit. The format of the message
+ * is given by the dpaa2_cscn structure. Bit 0 of the state field
+ * represents congestion state written by the hardware.
+ */
+struct dpaa2_cscn {
+   u8 verb;
+   u8 stat;
+   u8 state;
+   u8 reserved;
+   __le32 cgid;
+   __le64 ctx;
+};
+
+#define DPAA2_CSCN_SIZE64
+#define DPAA2_CSCN_ALIGN   16
+
+#define DPAA2_CSCN_STATE_MASK  0x1
+#define DPAA2_CSCN_CONGESTED   1
+
+static inline bool dpaa2_cscn_state_congested(struct dpaa2_cscn *cscn)
+{
+   return ((cscn->state & DPAA2_CSCN_STATE_MASK) == DPAA2_CSCN_CONGESTED);
+}
+
 #endif /* __FSL_DPAA2_IO_H */
-- 
2.12.0.264.gd6db3f216544

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

[PATCH 4/4] staging: fsl-dpaa2/eth: move generic FD defines to DPIO

[Horia Geantă]

Previous commits:
6e2387e8f19e ("staging: fsl-dpaa2/eth: Add Freescale DPAA2 Ethernet driver")
39163c0ce0f4 ("staging: fsl-dpaa2/eth: Errors checking update")
have added bits that are not specific to the WRIOP accelerator.

Move these where they belong (in DPIO) such that other accelerators
can make use of them.

While here, fix the values of FD_CTRL_FSE and FD_CTRL_FAERR, which
were shifted off by one bit.

Signed-off-by: Horia Geantă 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c |  8 +++-
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 19 +--
 drivers/staging/fsl-mc/include/dpaa2-fd.h  | 12 
 3 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 26017fe9df93..664cd1f4cd91 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -410,8 +410,7 @@ static int build_sg_fd(struct dpaa2_eth_priv *priv,
dpaa2_fd_set_format(fd, dpaa2_fd_sg);
dpaa2_fd_set_addr(fd, addr);
dpaa2_fd_set_len(fd, skb->len);
-   dpaa2_fd_set_ctrl(fd, DPAA2_FD_CTRL_ASAL | DPAA2_FD_CTRL_PTA |
- DPAA2_FD_CTRL_PTV1);
+   dpaa2_fd_set_ctrl(fd, DPAA2_FD_CTRL_ASAL | FD_CTRL_PTA | FD_CTRL_PTV1);
 
return 0;
 
@@ -464,8 +463,7 @@ static int build_single_fd(struct dpaa2_eth_priv *priv,
dpaa2_fd_set_offset(fd, (u16)(skb->data - buffer_start));
dpaa2_fd_set_len(fd, skb->len);
dpaa2_fd_set_format(fd, dpaa2_fd_single);
-   dpaa2_fd_set_ctrl(fd, DPAA2_FD_CTRL_ASAL | DPAA2_FD_CTRL_PTA |
- DPAA2_FD_CTRL_PTV1);
+   dpaa2_fd_set_ctrl(fd, DPAA2_FD_CTRL_ASAL | FD_CTRL_PTA | FD_CTRL_PTV1);
 
return 0;
 }
@@ -653,7 +651,7 @@ static void dpaa2_eth_tx_conf(struct dpaa2_eth_priv *priv,
/* We only check error bits in the FAS field if corresponding
 * FAERR bit is set in FD and the FAS field is marked as valid
 */
-   has_fas_errors = (fd_errors & DPAA2_FD_CTRL_FAERR) &&
+   has_fas_errors = (fd_errors & FD_CTRL_FAERR) &&
 !!(dpaa2_fd_get_frc(fd) & DPAA2_FD_FRC_FASV);
if (net_ratelimit())
netdev_dbg(priv->net_dev, "TX frame FD error: 0x%08x\n",
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
index e6d28a249fc1..dfbb60b1 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
@@ -120,23 +120,14 @@ struct dpaa2_eth_swa {
 #define DPAA2_FD_FRC_FASWOV0x0800
 #define DPAA2_FD_FRC_FAICFDV   0x0400
 
-/* Error bits in FD CTRL */
-#define DPAA2_FD_CTRL_UFD  0x0004
-#define DPAA2_FD_CTRL_SBE  0x0008
-#define DPAA2_FD_CTRL_FSE  0x0010
-#define DPAA2_FD_CTRL_FAERR0x0020
-
-#define DPAA2_FD_RX_ERR_MASK   (DPAA2_FD_CTRL_SBE  | \
-DPAA2_FD_CTRL_FAERR)
-#define DPAA2_FD_TX_ERR_MASK   (DPAA2_FD_CTRL_UFD  | \
-DPAA2_FD_CTRL_SBE  | \
-DPAA2_FD_CTRL_FSE  | \
-DPAA2_FD_CTRL_FAERR)
+#define DPAA2_FD_RX_ERR_MASK   (FD_CTRL_SBE | FD_CTRL_FAERR)
+#define DPAA2_FD_TX_ERR_MASK   (FD_CTRL_UFD| \
+FD_CTRL_SBE| \
+FD_CTRL_FSE| \
+FD_CTRL_FAERR)
 
 /* Annotation bits in FD CTRL */
 #define DPAA2_FD_CTRL_ASAL 0x0002  /* ASAL = 128 */
-#define DPAA2_FD_CTRL_PTA  0x0080
-#define DPAA2_FD_CTRL_PTV1 0x0040
 
 /* Frame annotation status */
 struct dpaa2_fas {
diff --git a/drivers/staging/fsl-mc/include/dpaa2-fd.h 
b/drivers/staging/fsl-mc/include/dpaa2-fd.h
index 992fdc7ba5b8..72328415c26d 100644
--- a/drivers/staging/fsl-mc/include/dpaa2-fd.h
+++ b/drivers/staging/fsl-mc/include/dpaa2-fd.h
@@ -101,6 +101,18 @@ struct dpaa2_fd {
 #define FL_FINAL_FLAG_MASK 0x1
 #define FL_FINAL_FLAG_SHIFT15
 
+/* Error bits in FD CTRL */
+#define FD_CTRL_ERR_MASK   0x00FF
+#define FD_CTRL_UFD0x0004
+#define FD_CTRL_SBE0x0008
+#define FD_CTRL_FLC0x0010
+#define FD_CTRL_FSE0x0020
+#define FD_CTRL_FAERR  0x0040
+
+/* Annotation bits in FD CTRL */
+#define FD_CTRL_PTA0x0080
+#define FD_CTRL_PTV1   0x0040
+
 enum dpaa2_fd_format {
dpaa2_fd_single = 0,
dpaa2_fd_list,
-- 
2.12.0.264.gd6db3f216544

___
devel mailing list
de...@linuxdriverproject.org

[PATCH 1/4] staging: fsl-mc: dpio: add frame list format support

[Horia Geantă]

Add support for dpaa2_fd_list format, i.e. dpaa2_fl_entry structure
and accessors.

Frame list entries (FLEs) are similar, but not identical to frame
descriptors (FDs):
+ "F" (final) bit
- FMT[b'01] is reserved
- DD, SC, DROPP bits (covered by "FD compatibility" field in FLE case)
- FLC[5:0] not used for stashing

Signed-off-by: Horia Geantă 
---
 drivers/staging/fsl-mc/include/dpaa2-fd.h | 243 ++
 1 file changed, 243 insertions(+)

diff --git a/drivers/staging/fsl-mc/include/dpaa2-fd.h 
b/drivers/staging/fsl-mc/include/dpaa2-fd.h
index cf7857f00a5c..992fdc7ba5b8 100644
--- a/drivers/staging/fsl-mc/include/dpaa2-fd.h
+++ b/drivers/staging/fsl-mc/include/dpaa2-fd.h
@@ -91,6 +91,15 @@ struct dpaa2_fd {
 #define SG_BPID_MASK   0x3FFF
 #define SG_FINAL_FLAG_MASK 0x1
 #define SG_FINAL_FLAG_SHIFT15
+#define FL_SHORT_LEN_FLAG_MASK 0x1
+#define FL_SHORT_LEN_FLAG_SHIFT14
+#define FL_SHORT_LEN_MASK  0x3
+#define FL_OFFSET_MASK 0x0FFF
+#define FL_FORMAT_MASK 0x3
+#define FL_FORMAT_SHIFT12
+#define FL_BPID_MASK   0x3FFF
+#define FL_FINAL_FLAG_MASK 0x1
+#define FL_FINAL_FLAG_SHIFT15
 
 enum dpaa2_fd_format {
dpaa2_fd_single = 0,
@@ -448,4 +457,238 @@ static inline void dpaa2_sg_set_final(struct 
dpaa2_sg_entry *sg, bool final)
sg->format_offset |= cpu_to_le16(final << SG_FINAL_FLAG_SHIFT);
 }
 
+/**
+ * struct dpaa2_fl_entry - structure for frame list entry.
+ * @addr:  address in the FLE
+ * @len:   length in the FLE
+ * @bpid:  buffer pool ID
+ * @format_offset: format, offset, and short-length fields
+ * @frc:   frame context
+ * @ctrl:  control bits...including pta, pvt1, pvt2, err, etc
+ * @flc:   flow context address
+ */
+struct dpaa2_fl_entry {
+   __le64 addr;
+   __le32 len;
+   __le16 bpid;
+   __le16 format_offset;
+   __le32 frc;
+   __le32 ctrl;
+   __le64 flc;
+};
+
+enum dpaa2_fl_format {
+   dpaa2_fl_single = 0,
+   dpaa2_fl_res,
+   dpaa2_fl_sg
+};
+
+/**
+ * dpaa2_fl_get_addr() - get the addr field of FLE
+ * @fle: the given frame list entry
+ *
+ * Return the address in the frame list entry.
+ */
+static inline dma_addr_t dpaa2_fl_get_addr(const struct dpaa2_fl_entry *fle)
+{
+   return (dma_addr_t)le64_to_cpu(fle->addr);
+}
+
+/**
+ * dpaa2_fl_set_addr() - Set the addr field of FLE
+ * @fle: the given frame list entry
+ * @addr: the address needs to be set in frame list entry
+ */
+static inline void dpaa2_fl_set_addr(struct dpaa2_fl_entry *fle,
+dma_addr_t addr)
+{
+   fle->addr = cpu_to_le64(addr);
+}
+
+/**
+ * dpaa2_fl_get_frc() - Get the frame context in the FLE
+ * @fle: the given frame list entry
+ *
+ * Return the frame context field in the frame lsit entry.
+ */
+static inline u32 dpaa2_fl_get_frc(const struct dpaa2_fl_entry *fle)
+{
+   return le32_to_cpu(fle->frc);
+}
+
+/**
+ * dpaa2_fl_set_frc() - Set the frame context in the FLE
+ * @fle: the given frame list entry
+ * @frc: the frame context needs to be set in frame list entry
+ */
+static inline void dpaa2_fl_set_frc(struct dpaa2_fl_entry *fle, u32 frc)
+{
+   fle->frc = cpu_to_le32(frc);
+}
+
+/**
+ * dpaa2_fl_get_ctrl() - Get the control bits in the FLE
+ * @fle: the given frame list entry
+ *
+ * Return the control bits field in the frame list entry.
+ */
+static inline u32 dpaa2_fl_get_ctrl(const struct dpaa2_fl_entry *fle)
+{
+   return le32_to_cpu(fle->ctrl);
+}
+
+/**
+ * dpaa2_fl_set_ctrl() - Set the control bits in the FLE
+ * @fle: the given frame list entry
+ * @ctrl: the control bits to be set in the frame list entry
+ */
+static inline void dpaa2_fl_set_ctrl(struct dpaa2_fl_entry *fle, u32 ctrl)
+{
+   fle->ctrl = cpu_to_le32(ctrl);
+}
+
+/**
+ * dpaa2_fl_get_flc() - Get the flow context in the FLE
+ * @fle: the given frame list entry
+ *
+ * Return the flow context in the frame list entry.
+ */
+static inline dma_addr_t dpaa2_fl_get_flc(const struct dpaa2_fl_entry *fle)
+{
+   return (dma_addr_t)le64_to_cpu(fle->flc);
+}
+
+/**
+ * dpaa2_fl_set_flc() - Set the flow context field of FLE
+ * @fle: the given frame list entry
+ * @flc_addr: the flow context needs to be set in frame list entry
+ */
+static inline void dpaa2_fl_set_flc(struct dpaa2_fl_entry *fle,
+   dma_addr_t flc_addr)
+{
+   fle->flc = cpu_to_le64(flc_addr);
+}
+
+static inline bool dpaa2_fl_short_len(const struct dpaa2_fl_entry *fle)
+{
+   return !!((le16_to_cpu(fle->format_offset) >>
+ FL_SHORT_LEN_FLAG_SHIFT) & FL_SHORT_LEN_FLAG_MASK);
+}
+
+/**
+ * dpaa2_fl_get_len() - Get the length in the FLE
+ * @fle: the given frame list entry
+ *
+ * Return the length field in the frame list entry.
+ */
+static inline u32 dpaa2_fl_get_len(const struct dpaa2_fl_entry *fle)
+{
+   if (dpaa2_fl_short_len(fle))
+  

[PATCH 3/4] staging: fsl-mc: dpio: add order preservation support

[Horia Geantă]

From: Radu Alexe 

Order preservation is a feature that will be supported
in dpni, dpseci and dpci devices.
This is a preliminary patch for the changes to be
introduced in the corresponding drivers.

Signed-off-by: Radu Alexe 
Signed-off-by: Horia Geantă 
---
 drivers/staging/fsl-mc/include/dpopr.h | 110 +
 1 file changed, 110 insertions(+)
 create mode 100644 drivers/staging/fsl-mc/include/dpopr.h

diff --git a/drivers/staging/fsl-mc/include/dpopr.h 
b/drivers/staging/fsl-mc/include/dpopr.h
new file mode 100644
index ..e1110af2fe54
--- /dev/null
+++ b/drivers/staging/fsl-mc/include/dpopr.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright 2017 NXP
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of the above-listed copyright holders nor the
+ * names of any contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef __FSL_DPOPR_H_
+#define __FSL_DPOPR_H_
+
+/* Data Path Order Restoration API
+ * Contains initialization APIs and runtime APIs for the Order Restoration
+ */
+
+/** Order Restoration properties */
+
+/**
+ * Create a new Order Point Record option
+ */
+#define OPR_OPT_CREATE 0x1
+/**
+ * Retire an existing Order Point Record option
+ */
+#define OPR_OPT_RETIRE 0x2
+
+/**
+ * struct opr_cfg - Structure representing OPR configuration
+ * @oprrws: Order point record (OPR) restoration window size (0 to 5)
+ * 0 - Window size is 32 frames.
+ * 1 - Window size is 64 frames.
+ * 2 - Window size is 128 frames.
+ * 3 - Window size is 256 frames.
+ * 4 - Window size is 512 frames.
+ * 5 - Window size is 1024 frames.
+ * @oa: OPR auto advance NESN window size (0 disabled, 1 enabled)
+ * @olws: OPR acceptable late arrival window size (0 to 3)
+ * 0 - Disabled. Late arrivals are always rejected.
+ * 1 - Window size is 32 frames.
+ * 2 - Window size is the same as the OPR restoration
+ * window size configured in the OPRRWS field.
+ * 3 - Window size is 8192 frames. Late arrivals are
+ * always accepted.
+ * @oeane: Order restoration list (ORL) resource exhaustion
+ * advance NESN enable (0 disabled, 1 enabled)
+ * @oloe: OPR loose ordering enable (0 disabled, 1 enabled)
+ */
+struct opr_cfg {
+   u8 oprrws;
+   u8 oa;
+   u8 olws;
+   u8 oeane;
+   u8 oloe;
+};
+
+/**
+ * struct opr_qry - Structure representing OPR configuration
+ * @enable: Enabled state
+ * @rip: Retirement In Progress
+ * @ndsn: Next dispensed sequence number
+ * @nesn: Next expected sequence number
+ * @ea_hseq: Early arrival head sequence number
+ * @hseq_nlis: HSEQ not last in sequence
+ * @ea_tseq: Early arrival tail sequence number
+ * @tseq_nlis: TSEQ not last in sequence
+ * @ea_tptr: Early arrival tail pointer
+ * @ea_hptr: Early arrival head pointer
+ * @opr_id: Order Point Record ID
+ * @opr_vid: Order Point Record Virtual ID
+ */
+struct opr_qry {
+   char enable;
+   char rip;
+   u16 ndsn;
+   u16 nesn;
+   u16 ea_hseq;
+   char hseq_nlis;
+   u16 ea_tseq;
+   char tseq_nlis;
+   u16 ea_tptr;
+   u16 ea_hptr;
+   

Re: [PATCH v2] staging: ks7010: Fix coding style and remove checkpatch.pl warnings.

[Dan Carpenter]

On Tue, Aug 29, 2017 at 08:57:34PM -0600, Jonathan Whitaker wrote:
> It is prefered to use '"%s...", __func__ instead of function names for
> logging. This commit replaces hardcoded function name strings to the
> more preferred '"%s...", __func__' style. These warnings were reported
> by checkpatch.pl.
> 
> Signed-off-by: Jonathan Whitaker 
> 
> Changes in v2:
>   - Wrapped the changelog text to 72 columns.
>   - Fixed the commit subject to be more clear.
> ---

Put the Changelog under the --- cut off line.

>  drivers/staging/ks7010/ks7010_sdio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
> b/drivers/staging/ks7010/ks7010_sdio.c
> index 9b28ee1..c0e91c3 100644
> --- a/drivers/staging/ks7010/ks7010_sdio.c
> +++ b/drivers/staging/ks7010/ks7010_sdio.c
> @@ -834,7 +834,7 @@ static int ks7010_sdio_probe(struct sdio_func *func,
>   unsigned char byte;
>   int ret;
>  
> - DPRINTK(5, "ks7010_sdio_probe()\n");
> + DPRINTK(5, "%s()\n", __func__);

Just delete both the printks.  You can get the same information with
ftrace.

regards,
dan carpenter

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

[PATCH v3 08/11] power: supply: bq24190_charger: Export 5V boost converter as regulator

[Hans de Goede]

Register the 5V boost converter as a regulator named "usb_otg_vbus".

This commit also adds support for bq24190_platform_data, through which
non device-tree platforms can pass the regulator_init_data (containing
mappings for the consumer amongst other things).

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use "usb_otg_vbus" as default name for the regulator
-Add support for passing regulator_init_data for non device-tree platforms
-Register the regulator later, to avoid it showing up and shortly later
 disappearing again on probe errors (e.g. -EPROBE_DEFER).

Changes in v3:
-Add a bq24190_set_charge_mode helper and use that for the vbus_enable
 and vbus_disable callbacks to reduce code duplication
---
 drivers/power/supply/bq24190_charger.c | 112 +
 include/linux/power/bq24190_charger.h  |  18 ++
 2 files changed, 130 insertions(+)
 create mode 100644 include/linux/power/bq24190_charger.h

diff --git a/drivers/power/supply/bq24190_charger.c 
b/drivers/power/supply/bq24190_charger.c
index fa711c106b63..e606a078b0dd 100644
--- a/drivers/power/supply/bq24190_charger.c
+++ b/drivers/power/supply/bq24190_charger.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -513,6 +516,111 @@ static int bq24190_sysfs_create_group(struct 
bq24190_dev_info *bdi)
 static inline void bq24190_sysfs_remove_group(struct bq24190_dev_info *bdi) {}
 #endif
 
+#ifdef CONFIG_REGULATOR
+static int bq24190_set_charge_mode(struct regulator_dev *dev, u8 val)
+{
+   struct bq24190_dev_info *bdi = rdev_get_drvdata(dev);
+   int ret;
+
+   ret = pm_runtime_get_sync(bdi->dev);
+   if (ret < 0) {
+   dev_warn(bdi->dev, "pm_runtime_get failed: %i\n", ret);
+   pm_runtime_put_noidle(bdi->dev);
+   return ret;
+   }
+
+   ret = bq24190_write_mask(bdi, BQ24190_REG_POC,
+BQ24190_REG_POC_CHG_CONFIG_MASK,
+BQ24190_REG_POC_CHG_CONFIG_SHIFT, val);
+
+   pm_runtime_mark_last_busy(bdi->dev);
+   pm_runtime_put_autosuspend(bdi->dev);
+
+   return ret;
+}
+
+static int bq24190_vbus_enable(struct regulator_dev *dev)
+{
+   return bq24190_set_charge_mode(dev, BQ24190_REG_POC_CHG_CONFIG_OTG);
+}
+
+static int bq24190_vbus_disable(struct regulator_dev *dev)
+{
+   return bq24190_set_charge_mode(dev, BQ24190_REG_POC_CHG_CONFIG_CHARGE);
+}
+
+static int bq24190_vbus_is_enabled(struct regulator_dev *dev)
+{
+   struct bq24190_dev_info *bdi = rdev_get_drvdata(dev);
+   int ret;
+   u8 val;
+
+   ret = pm_runtime_get_sync(bdi->dev);
+   if (ret < 0) {
+   dev_warn(bdi->dev, "pm_runtime_get failed: %i\n", ret);
+   pm_runtime_put_noidle(bdi->dev);
+   return ret;
+   }
+
+   ret = bq24190_read_mask(bdi, BQ24190_REG_POC,
+   BQ24190_REG_POC_CHG_CONFIG_MASK,
+   BQ24190_REG_POC_CHG_CONFIG_SHIFT, );
+
+   pm_runtime_mark_last_busy(bdi->dev);
+   pm_runtime_put_autosuspend(bdi->dev);
+
+   return ret ? ret : val == BQ24190_REG_POC_CHG_CONFIG_OTG;
+}
+
+static const struct regulator_ops bq24190_vbus_ops = {
+   .enable = bq24190_vbus_enable,
+   .disable = bq24190_vbus_disable,
+   .is_enabled = bq24190_vbus_is_enabled,
+};
+
+static const struct regulator_desc bq24190_vbus_desc = {
+   .name = "usb_otg_vbus",
+   .type = REGULATOR_VOLTAGE,
+   .owner = THIS_MODULE,
+   .ops = _vbus_ops,
+   .fixed_uV = 500,
+   .n_voltages = 1,
+};
+
+static const struct regulator_init_data bq24190_vbus_init_data = {
+   .constraints = {
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+};
+
+static int bq24190_register_vbus_regulator(struct bq24190_dev_info *bdi)
+{
+   struct bq24190_platform_data *pdata = bdi->dev->platform_data;
+   struct regulator_config cfg = { };
+   struct regulator_dev *reg;
+   int ret = 0;
+
+   cfg.dev = bdi->dev;
+   if (pdata && pdata->regulator_init_data)
+   cfg.init_data = pdata->regulator_init_data;
+   else
+   cfg.init_data = _vbus_init_data;
+   cfg.driver_data = bdi;
+   reg = devm_regulator_register(bdi->dev, _vbus_desc, );
+   if (IS_ERR(reg)) {
+   ret = PTR_ERR(reg);
+   dev_err(bdi->dev, "Can't register regulator: %d\n", ret);
+   }
+
+   return ret;
+}
+#else
+static int bq24190_register_vbus_regulator(struct bq24190_dev_info *bdi)
+{
+   return 0;
+}
+#endif
+
 static int bq24190_set_config(struct bq24190_dev_info *bdi)
 {
int ret;
@@ -1740,6 +1848,10 @@ static int bq24190_probe(struct i2c_client *client,
goto out_sysfs;
}
 
+   ret = bq24190_register_vbus_regulator(bdi);
+   if (ret < 0)
+   goto out_sysfs;
+
if 

[PATCH v3 10/11] i2c-cht-wc: Add device-properties for fusb302 integration

[Hans de Goede]

Add device-properties to make the bq24292i charger connected to
the bus get its input-current-limit from the fusb302 Type-C port
controller which is used on boards with the cht-wc PMIC,
as well as regulator_init_data for the 5V boost converter on
the bq24292i.

Since this means we now hook-up the bq24292i to the fusb302 Type-C port
controller add a check for the ACPI device which instantiates the fusb302.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Set board_info.dev_name
-Define and pass regulator_init_data for the bq24292i
-Add a check for the ACPI device which instantiates the fusb302
---
 drivers/i2c/busses/Kconfig  |  5 
 drivers/i2c/busses/i2c-cht-wc.c | 52 +++--
 2 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 79c33817e412..272ef10fb629 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -197,6 +197,11 @@ config I2C_CHT_WC
  SMBus controller found in the Intel Cherry Trail Whiskey Cove PMIC
  found on some Intel Cherry Trail systems.
 
+ Note this controller is hooked up to a TI bq24292i charger-IC,
+ combined with a FUSB302 Type-C port-controller as such it is advised
+ to also select CONFIG_CHARGER_BQ24190=m and CONFIG_TYPEC_FUSB302=m
+ (the fusb302 driver currently is in drivers/staging).
+
 config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
depends on PCI
diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
index 21312eed09e4..69a159fc661a 100644
--- a/drivers/i2c/busses/i2c-cht-wc.c
+++ b/drivers/i2c/busses/i2c-cht-wc.c
@@ -16,6 +16,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CHT_WC_I2C_CTRL0x5e24
@@ -232,13 +234,36 @@ static const struct irq_chip cht_wc_i2c_irq_chip = {
.name   = "cht_wc_ext_chrg_irq_chip",
 };
 
+static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };
+
 static const struct property_entry bq24190_props[] = {
-   PROPERTY_ENTRY_STRING("extcon-name", "cht_wcove_pwrsrc"),
+   PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),
+   PROPERTY_ENTRY_BOOL("ti,input-current-limit-from-supplier"),
PROPERTY_ENTRY_BOOL("omit-battery-class"),
PROPERTY_ENTRY_BOOL("disable-reset"),
{ }
 };
 
+static struct regulator_consumer_supply fusb302_consumer = {
+   .supply = "vbus",
+   /* Must match fusb302 dev_name in intel_cht_int33fe.c */
+   .dev_name = "i2c-fusb302",
+};
+
+static const struct regulator_init_data bq24190_vbus_init_data = {
+   .constraints = {
+   /* The name is used in intel_cht_int33fe.c do not change. */
+   .name = "cht_wc_usb_typec_vbus",
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .consumer_supplies = _consumer,
+   .num_consumer_supplies = 1,
+};
+
+static struct bq24190_platform_data bq24190_pdata = {
+   .regulator_init_data = _vbus_init_data,
+};
+
 static int cht_wc_i2c_adap_i2c_probe(struct platform_device *pdev)
 {
struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
@@ -246,7 +271,9 @@ static int cht_wc_i2c_adap_i2c_probe(struct platform_device 
*pdev)
struct i2c_board_info board_info = {
.type = "bq24190",
.addr = 0x6b,
+   .dev_name = "bq24190",
.properties = bq24190_props,
+   .platform_data = _pdata,
};
int ret, reg, irq;
 
@@ -314,11 +341,21 @@ static int cht_wc_i2c_adap_i2c_probe(struct 
platform_device *pdev)
if (ret)
goto remove_irq_domain;
 
-   board_info.irq = adap->client_irq;
-   adap->client = i2c_new_device(>adapter, _info);
-   if (!adap->client) {
-   ret = -ENOMEM;
-   goto del_adapter;
+   /*
+* Normally the Whiskey Cove PMIC is paired with a TI bq24292i charger,
+* connected to this i2c bus, and a max17047 fuel-gauge and a fusb302
+* USB Type-C controller connected to another i2c bus. In this setup
+* the max17047 and fusb302 devices are enumerated through an INT33FE
+* ACPI device. If this device is present register an i2c-client for
+* the TI bq24292i charger.
+*/
+   if (acpi_dev_present("INT33FE", NULL, -1)) {
+   board_info.irq = adap->client_irq;
+   adap->client = i2c_new_device(>adapter, _info);
+   if (!adap->client) {
+   ret = -ENOMEM;
+   goto del_adapter;
+   }
}
 
platform_set_drvdata(pdev, adap);
@@ -335,7 +372,8 @@ static int cht_wc_i2c_adap_i2c_remove(struct 
platform_device 

[PATCH v3 09/11] power: supply: bq24190_charger: Get input_current_limit from our supplier

[Hans de Goede]

On some devices the USB Type-C port power (USB PD 2.0) negotiation is
done by a separate port-controller IC, while the current limit is
controlled through another (charger) IC.

It has been decided to model this by modelling the external Type-C
power brick (adapter/charger) as a power-supply class device which
supplies the charger-IC, with its voltage-now and current-max representing
the negotiated voltage and max current draw.

This commit adds support for this to the bq24190_charger driver by adding
an external_power_changed callback and calling
power_supply_set_input_current_limit_from_supplier from this callback.
This callback will only get called if the bq24190 has a parent-supply.

Note this replaces the functionality to get the current-limit from an
extcon device, which will be removed in a follow-up commit.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Wait a bit before applying current-max from our supplier as input-current-limit
 the bq24190 may still be in its power-good wait-state while our supplier is
 done negotating current-max and if we apply the limit to early then the
 input-current-limit will be reset to 0.5A by the bq24190 after its
 power-good wait is done.

Changes in v3:
-Drop the input-current-limit-from-supplier device-property, simply always
 sync the input-current-limit with the parent-supply if a parent-supply is
 present
---
 drivers/power/supply/bq24190_charger.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/power/supply/bq24190_charger.c 
b/drivers/power/supply/bq24190_charger.c
index e606a078b0dd..35ff406aca48 100644
--- a/drivers/power/supply/bq24190_charger.c
+++ b/drivers/power/supply/bq24190_charger.c
@@ -165,6 +165,7 @@ struct bq24190_dev_info {
struct extcon_dev   *extcon;
struct notifier_block   extcon_nb;
struct delayed_work extcon_work;
+   struct delayed_work input_current_limit_work;
charmodel_name[I2C_NAME_SIZE];
boolinitialized;
boolirq_event;
@@ -1210,6 +1211,32 @@ static int bq24190_charger_property_is_writeable(struct 
power_supply *psy,
return ret;
 }
 
+static void bq24190_input_current_limit_work(struct work_struct *work)
+{
+   struct bq24190_dev_info *bdi =
+   container_of(work, struct bq24190_dev_info,
+input_current_limit_work.work);
+
+   power_supply_set_input_current_limit_from_supplier(bdi->charger);
+}
+
+/* Sync the input-current-limit with our parent supply (if we have one) */
+static void bq24190_charger_external_power_changed(struct power_supply *psy)
+{
+   struct bq24190_dev_info *bdi = power_supply_get_drvdata(psy);
+
+   /*
+* The Power-Good detection may take up to 220ms, sometimes
+* the external charger detection is quicker, and the bq24190 will
+* reset to iinlim based on its own charger detection (which is not
+* hooked up when using external charger detection) resulting in a
+* too low default 500mA iinlim. Delay setting the input-current-limit
+* for 300ms to avoid this.
+*/
+   queue_delayed_work(system_wq, >input_current_limit_work,
+  msecs_to_jiffies(300));
+}
+
 static enum power_supply_property bq24190_charger_properties[] = {
POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_HEALTH,
@@ -1240,6 +1267,7 @@ static const struct power_supply_desc 
bq24190_charger_desc = {
.get_property   = bq24190_charger_get_property,
.set_property   = bq24190_charger_set_property,
.property_is_writeable  = bq24190_charger_property_is_writeable,
+   .external_power_changed = bq24190_charger_external_power_changed,
 };
 
 /* Battery power supply property routines */
@@ -1758,6 +1786,8 @@ static int bq24190_probe(struct i2c_client *client,
mutex_init(>f_reg_lock);
bdi->f_reg = 0;
bdi->ss_reg = BQ24190_REG_SS_VBUS_STAT_MASK; /* impossible state */
+   INIT_DELAYED_WORK(>input_current_limit_work,
+ bq24190_input_current_limit_work);
 
i2c_set_clientdata(client, bdi);
 
-- 
2.13.4

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

[PATCH v3 11/11] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

[Hans de Goede]

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
rather then just "fusb302" and needs us to set a number of device-
properties, adjust the intel_cht_int33fe driver accordingly.

One of the properties set is max-snk-mv which makes the fusb302 driver
negotiate up to 12V charging voltage, which is a bad idea on boards
which are not setup to handle this, so this commit also adds 2 extra
sanity checks to make sure that the expected Whiskey Cove PMIC +
TI bq24292i charger combo, which can handle 12V, is present.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Set board_info.dev_name
-Adjust for changes in other patches in this patch-set
---
 drivers/platform/x86/Kconfig |  6 -
 drivers/platform/x86/intel_cht_int33fe.c | 44 +++-
 2 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b87954f6dd..c5554577681a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -793,7 +793,7 @@ config ACPI_CMPC
 
 config INTEL_CHT_INT33FE
tristate "Intel Cherry Trail ACPI INT33FE Driver"
-   depends on X86 && ACPI && I2C
+   depends on X86 && ACPI && I2C && REGULATOR
---help---
  This driver add support for the INT33FE ACPI device found on
  some Intel Cherry Trail devices.
@@ -804,6 +804,10 @@ config INTEL_CHT_INT33FE
  This driver instantiates i2c-clients for these, so that standard
  i2c drivers for these chips can bind to the them.
 
+ If you enable this driver it is advised to also select
+ CONFIG_CHARGER_BQ24190=m, CONFIG_BATTERY_MAX17042=m and
+ CONFIG_TYPEC_FUSB302=m (currently in drivers/staging).
+
 config INTEL_INT0002_VGPIO
tristate "Intel ACPI INT0002 Virtual GPIO driver"
depends on GPIOLIB && ACPI
diff --git a/drivers/platform/x86/intel_cht_int33fe.c 
b/drivers/platform/x86/intel_cht_int33fe.c
index 5f1924fb3190..24a1662be81d 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define EXPECTED_PTYPE 4
@@ -70,12 +71,21 @@ static const struct property_entry max17047_props[] = {
{ }
 };
 
+static const struct property_entry fusb302_props[] = {
+   PROPERTY_ENTRY_STRING("fcs,extcon-name", "cht_wcove_pwrsrc"),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 1200),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microamp",   300),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microwatt", 3600),
+   { }
+};
+
 static int cht_int33fe_probe(struct i2c_client *client)
 {
struct device *dev = >dev;
struct i2c_board_info board_info;
struct cht_int33fe_data *data;
struct i2c_client *max17047;
+   struct regulator *regulator;
unsigned long long ptyp;
acpi_status status;
int ret, fusb302_irq;
@@ -93,6 +103,34 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (ptyp != EXPECTED_PTYPE)
return -ENODEV;
 
+   /* Check presence of INT34D3 (hardware-rev 3) expected for ptype == 4 */
+   if (!acpi_dev_present("INT34D3", "1", 3)) {
+   dev_err(dev, "Error PTYPE == %d, but no INT34D3 device\n",
+   EXPECTED_PTYPE);
+   return -ENODEV;
+   }
+
+   /*
+* We expect the WC PMIC to be paired with a TI bq24292i charger-IC.
+* We check for the bq24292i vbus regulator here, this has 2 purposes:
+* 1) The bq24292i allows charging with up to 12V, setting the fusb302's
+*max-snk voltage to 12V with another charger-IC is not good.
+* 2) For the fusb302 driver to get the bq24292i vbus regulator, the
+*regulator-map, which is part of the bq24292i regulator_init_data,
+*must be registered before the fusb302 is instantiated, otherwise
+*it will end up with a dummy-regulator.
+* Note "cht_wc_usb_typec_vbus" comes from the regulator_init_data
+* which is defined in i2c-cht-wc.c from where the bq24292i i2c-client
+* gets instantiated. We use regulator_get_optional here so that we
+* don't end up getting a dummy-regulator ourselves.
+*/
+   regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
+   if (IS_ERR(regulator)) {
+   ret = PTR_ERR(regulator);
+   return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
+   }
+   regulator_put(regulator);
+
/* The FUSB302 uses the irq at index 1 and is the only irq user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
@@ -119,6 +157,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
} else {
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, 

[PATCH v3 06/11] staging: typec: fusb302: Add support for USB2 charger detection through extcon

[Hans de Goede]

The fusb302 port-controller relies on an external device doing USB2
charger-type detection.

The Intel Whiskey Cove PMIC with which the fusb302 is combined on some
X86/ACPI platforms already has a charger-type detection driver which
uses extcon to communicate the detected charger-type.

Rather then inventing a new API for USB2 charger-type detection
specifically for use with the tcpm code, this commit simply re-uses the
existing extcon API and uses that do USB2 charger detection.

Note that the "fcs,extcon-name" property name is only for kernel internal
use by X86/ACPI platform code and as such is NOT documented in
the fusb302 devicetree bindings.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Put extcon code directly in fusb302.c rather then introducing helpers
 which are only used by fusb302.c

Changes in v3:
-Improve commit message
---
 drivers/staging/typec/fusb302/fusb302.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 675161cf4f3a..6f007f66d597 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +97,7 @@ struct fusb302_chip {
 
int gpio_int_n;
int gpio_int_n_irq;
+   struct extcon_dev *extcon;
 
struct workqueue_struct *wq;
struct delayed_work bc_lvl_handler;
@@ -516,6 +518,38 @@ static int tcpm_get_vbus(struct tcpc_dev *dev)
return ret;
 }
 
+static int tcpm_get_current_limit(struct tcpc_dev *dev)
+{
+   struct fusb302_chip *chip = container_of(dev, struct fusb302_chip,
+tcpc_dev);
+   int current_limit = 0;
+   unsigned long timeout;
+
+   if (!chip->extcon)
+   return 0;
+
+   /*
+* USB2 Charger detection may still be in progress when we get here,
+* this can take upto 600ms, wait 800ms max.
+*/
+   timeout = jiffies + msecs_to_jiffies(800);
+   do {
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_SDP) == 1)
+   current_limit = 500;
+
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_CDP) == 1 ||
+   extcon_get_state(chip->extcon, EXTCON_CHG_USB_ACA) == 1)
+   current_limit = 1500;
+
+   if (extcon_get_state(chip->extcon, EXTCON_CHG_USB_DCP) == 1)
+   current_limit = 2000;
+
+   msleep(50);
+   } while (current_limit == 0 && time_before(jiffies, timeout));
+
+   return current_limit;
+}
+
 static int fusb302_set_cc_pull(struct fusb302_chip *chip,
   bool pull_up, bool pull_down)
 {
@@ -1201,6 +1235,7 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
 {
fusb302_tcpc_dev->init = tcpm_init;
fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
+   fusb302_tcpc_dev->get_current_limit = tcpm_get_current_limit;
fusb302_tcpc_dev->set_cc = tcpm_set_cc;
fusb302_tcpc_dev->get_cc = tcpm_get_cc;
fusb302_tcpc_dev->set_polarity = tcpm_set_polarity;
@@ -1685,6 +1720,7 @@ static int fusb302_probe(struct i2c_client *client,
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
struct device *dev = >dev;
+   const char *name;
int ret = 0;
u32 v;
 
@@ -1717,6 +1753,19 @@ static int fusb302_probe(struct i2c_client *client,
if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", ))
chip->tcpc_config.operating_snk_mw = v / 1000;
 
+   /*
+* Devicetree platforms should get extcon via phandle (not yet
+* supported). On ACPI platforms, we get the name from a device prop.
+* This device prop is for kernel internal use only and is expected
+* to be set by the platform code which also registers the i2c client
+* for the fusb302.
+*/
+   if (device_property_read_string(dev, "fcs,extcon-name", ) == 0) {
+   chip->extcon = extcon_get_extcon_dev(name);
+   if (!chip->extcon)
+   return -EPROBE_DEFER;
+   }
+
ret = fusb302_debugfs_init(chip);
if (ret < 0)
return ret;
-- 
2.13.4

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

[PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev

[Hans de Goede]

The fusb302 Type-C port-controller cannot control the current-limit
directly, so we need to exported the limit so that another driver
(e.g. the charger driver) can pick the limit up and configure the
system accordingly.

The power-supply subsys already provides infrastructure for this,
power-supply devices have the notion of being supplied by another
power-supply and have properties through which we can export the
current-limit.

Register a power_supply and export the current-limit through the
power_supply's current-max property.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Put the psy class device code directly in fusb302.c rather then introducing
 helpers which are only used by fusb302.c
-Add an online property to the psy so that upower does not mistake it for a
 second battery in the system
---
 drivers/staging/typec/fusb302/Kconfig   |  2 +-
 drivers/staging/typec/fusb302/fusb302.c | 63 +++--
 2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/Kconfig 
b/drivers/staging/typec/fusb302/Kconfig
index fce099ff39fe..48a4f2fcee03 100644
--- a/drivers/staging/typec/fusb302/Kconfig
+++ b/drivers/staging/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
 config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C
+   depends on I2C && POWER_SUPPLY
help
  The Fairchild FUSB302 Type-C chip driver that works with
  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 6f007f66d597..cf6355f59cd9 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -108,6 +109,11 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
 
+   /* psy + psy status */
+   struct power_supply *psy;
+   u32 current_limit;
+   u32 supply_voltage;
+
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -876,11 +882,13 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
-   if (chip->charge_on == charge)
+   if (chip->charge_on == charge) {
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
-   else
+   } else {
chip->charge_on = charge;
+   power_supply_changed(chip->psy);
+   }
 
 done:
mutex_unlock(>lock);
@@ -896,6 +904,11 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
 
+   chip->supply_voltage = mv;
+   chip->current_limit = max_ma;
+
+   power_supply_changed(chip->psy);
+
return 0;
 }
 
@@ -1681,6 +1694,43 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static int fusb302_psy_get_property(struct power_supply *psy,
+   enum power_supply_property psp,
+   union power_supply_propval *val)
+{
+   struct fusb302_chip *chip = power_supply_get_drvdata(psy);
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_ONLINE:
+   val->intval = chip->charge_on;
+   break;
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+   val->intval = chip->supply_voltage * 1000; /* mV -> µV */
+   break;
+   case POWER_SUPPLY_PROP_CURRENT_MAX:
+   val->intval = chip->current_limit * 1000; /* mA -> µA */
+   break;
+   default:
+   return -ENODATA;
+   }
+
+   return 0;
+}
+
+static enum power_supply_property fusb302_psy_properties[] = {
+   POWER_SUPPLY_PROP_ONLINE,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_MAX,
+};
+
+const struct power_supply_desc fusb302_psy_desc = {
+   .name   = "fusb302-typec-source",
+   .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
+   .properties = fusb302_psy_properties,
+   .num_properties = ARRAY_SIZE(fusb302_psy_properties),
+   .get_property   = fusb302_psy_get_property,
+};
+
 static int init_gpio(struct fusb302_chip *chip)
 {
struct device_node *node;
@@ -1720,6 +1770,7 @@ static int fusb302_probe(struct i2c_client *client,
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
struct device *dev = >dev;
+   struct power_supply_config cfg = {};
const char *name;
int ret = 0;
u32 v;
@@ -1766,6 +1817,14 @@ static int 

[PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V

[Hans de Goede]

Anything higher then 5V may damage hardware not capable of it, so
the only sane default here is 5V. If a board is able to handle a
higher voltage that should come from board specific data such as
device-tree and not be hard coded into the fusb302 code.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
---
 drivers/staging/typec/fusb302/fusb302.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 03a3809d18f0..6baed06a3c0d 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1187,9 +1187,9 @@ static const struct tcpc_config fusb302_tcpc_config = {
.nr_src_pdo = ARRAY_SIZE(src_pdo),
.snk_pdo = snk_pdo,
.nr_snk_pdo = ARRAY_SIZE(snk_pdo),
-   .max_snk_mv = 9000,
+   .max_snk_mv = 5000,
.max_snk_ma = 3000,
-   .max_snk_mw = 27000,
+   .max_snk_mw = 15000,
.operating_snk_mw = 2500,
.type = TYPEC_PORT_DRP,
.default_role = TYPEC_SINK,
-- 
2.13.4

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

[PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set

[Hans de Goede]

The fusb302 is also used on x86 systems where the platform code sets
the irq in client->irq and there is no gpio named fcs,int_n.

Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
---
 drivers/staging/typec/fusb302/fusb302.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 1c1751c994db..675161cf4f3a 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1735,9 +1735,13 @@ static int fusb302_probe(struct i2c_client *client,
goto destroy_workqueue;
}
 
-   ret = init_gpio(chip);
-   if (ret < 0)
-   goto destroy_workqueue;
+   if (client->irq) {
+   chip->gpio_int_n_irq = client->irq;
+   } else {
+   ret = init_gpio(chip);
+   if (ret < 0)
+   goto destroy_workqueue;
+   }
 
chip->tcpm_port = tcpm_register_port(>dev, >tcpc_dev);
if (IS_ERR(chip->tcpm_port)) {
-- 
2.13.4

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

[PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

[Hans de Goede]

This is board specific info so it should come from board config, such
as devicetree.

I've chosen to prefix these with "fcs," treating them as fusb302 driver
specific for now. We may want to revisit this and replace these with
properties which are part of a (to be written) generic type-c controller
devicetree binding.

Since this commit adds new dt-properties it also adds devicetree-bindings
documentation (which so far was absent for the fusb302 driver).

Cc: Rob Herring 
Cc: Frank Rowand 
Cc: devicet...@vger.kernel.org
Cc: "Yueyao (Nathan) Zhu" 
Signed-off-by: Hans de Goede 
Acked-by: Rob Herring 
---
Changes in v2:
-Use micro... instead of mili...
-Add devicetree bindings documentation

Changes in v3:
-Use sink rather then snk in property names
-Add Rob's Acked-by
---
 .../devicetree/bindings/usb/fcs,fusb302.txt| 29 ++
 drivers/staging/typec/fusb302/TODO |  4 +++
 drivers/staging/typec/fusb302/fusb302.c| 18 +-
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/usb/fcs,fusb302.txt

diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt 
b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
new file mode 100644
index ..472facfa5a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -0,0 +1,29 @@
+Fairchild FUSB302 Type-C Port controllers
+
+Required properties :
+- compatible : "fcs,fusb302"
+- reg: I2C slave address
+- interrupts : Interrupt specifier
+
+Optional properties :
+- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink
+- fcs,max-sink-microamp  : Maximum current to negotiate when configured as sink
+- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink
+  If this is less then max-sink-microvolt *
+  max-sink-microamp then the configured current will
+  be clamped.
+- fcs,operating-sink-microwatt :
+  Minimum amount of power accepted from a sink
+  when negotiating
+
+Example:
+
+fusb302: typec-portc@54 {
+   compatible = "fcs,fusb302";
+   reg = <0x54>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   fcs,max-sink-microvolt = <1200>;
+   fcs,max-sink-microamp = <300>;
+   fcs,max-sink-microwatt = <3600>;
+};
diff --git a/drivers/staging/typec/fusb302/TODO 
b/drivers/staging/typec/fusb302/TODO
index 4933a1d92c32..19b466eb585d 100644
--- a/drivers/staging/typec/fusb302/TODO
+++ b/drivers/staging/typec/fusb302/TODO
@@ -4,3 +4,7 @@ fusb302:
 - Find a non-hacky way to coordinate between PM and I2C access
 - Documentation? The FUSB302 datasheet provides information on the chip to help
   understand the code. But it may still be helpful to have a documentation.
+- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
+  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
+  properties with properties which are part of a generic type-c controller
+  devicetree binding.
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index 6baed06a3c0d..1c1751c994db 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -90,6 +90,7 @@ struct fusb302_chip {
struct i2c_client *i2c_client;
struct tcpm_port *tcpm_port;
struct tcpc_dev tcpc_dev;
+   struct tcpc_config tcpc_config;
 
struct regulator *vbus;
 
@@ -1198,7 +1199,6 @@ static const struct tcpc_config fusb302_tcpc_config = {
 
 static void init_tcpc_dev(struct tcpc_dev *fusb302_tcpc_dev)
 {
-   fusb302_tcpc_dev->config = _tcpc_config;
fusb302_tcpc_dev->init = tcpm_init;
fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
fusb302_tcpc_dev->set_cc = tcpm_set_cc;
@@ -1684,7 +1684,9 @@ static int fusb302_probe(struct i2c_client *client,
 {
struct fusb302_chip *chip;
struct i2c_adapter *adapter;
+   struct device *dev = >dev;
int ret = 0;
+   u32 v;
 
adapter = to_i2c_adapter(client->dev.parent);
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_I2C_BLOCK)) {
@@ -1699,8 +1701,22 @@ static int fusb302_probe(struct i2c_client *client,
chip->i2c_client = client;
i2c_set_clientdata(client, chip);
chip->dev = >dev;
+   chip->tcpc_config = fusb302_tcpc_config;
+   chip->tcpc_dev.config = >tcpc_config;
mutex_init(>lock);
 
+   if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", ))
+   chip->tcpc_config.max_snk_mv = v / 1000;
+
+   if (!device_property_read_u32(dev, "fcs,max-sink-microamp", ))
+   

[PATCH v3 02/11] staging: typec: tcpm: Add get_current_limit tcpc_dev callback

[Hans de Goede]

A Rp signalling the default current limit indicates that we're possibly
connected to an USB2 power-source. In some cases the type-c port-controller
may provide the capability to detect the current-limit in this case,
through e.g. BC1.2 detection.

This commit adds an optional get_current_limit tcpc_dev callback which
allows the port-controller to provide current-limit detection for when
the CC pin is pulled up with Rp.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
---
Changes in v2:
-s/get_usb2_current_limit/get_current_limit/
---
 drivers/staging/typec/tcpm.c | 5 -
 drivers/staging/typec/tcpm.h | 7 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index a911cad41a59..6ca73a3c7e88 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -667,7 +667,10 @@ static u32 tcpm_get_current_limit(struct tcpm_port *port)
break;
case TYPEC_CC_RP_DEF:
default:
-   limit = 0;
+   if (port->tcpc->get_current_limit)
+   limit = port->tcpc->get_current_limit(port->tcpc);
+   else
+   limit = 0;
break;
}
 
diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
index 374cea44a84a..7e9a6b7b5cd6 100644
--- a/drivers/staging/typec/tcpm.h
+++ b/drivers/staging/typec/tcpm.h
@@ -109,6 +109,13 @@ struct tcpc_dev {
 
int (*init)(struct tcpc_dev *dev);
int (*get_vbus)(struct tcpc_dev *dev);
+   /*
+* This optional callback gets called by the tcpm core when configured
+* as a snk and cc=Rp-def. This allows the tcpm to provide a fallback
+* current-limit detection method for the cc=Rp-def case. E.g. some
+* tcpcs may include BC1.2 charger detection and use that in this case.
+*/
+   int (*get_current_limit)(struct tcpc_dev *dev);
int (*set_cc)(struct tcpc_dev *dev, enum typec_cc_status cc);
int (*get_cc)(struct tcpc_dev *dev, enum typec_cc_status *cc1,
  enum typec_cc_status *cc2);
-- 
2.13.4

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

[PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger

[Hans de Goede]

Hi All,

Here is v3 of my typec power-negotation hookup series. New this version:
- Drop a few patches merged into linux-power-supply.git/for-next
- Drop the "power: supply: bq24190_charger: Remove extcon handling"
  patch *for now*, this can only be merged once all the other patches are
  in place (and extcon handling is no longer needed)
- Address some review comments in some of the other patches, see the
  per patch changelogs inside the commit messages

I believe that this series is ready for merging now and I would like to
ask the various subsys maintainers to pick up and merge these patches.
All the patches can be merged independent of eachother with the exception
of the last 2 patches:

i2c-cht-wc: Add device-properties for fusb302 integration
platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

Which should not be merged until all the other patches are in place.

For reference below is the cover letter of v2 of this patch.

Regards,

Hans


v2 series cover letter:

This series implements a number of typec changes discussed a while back:

- It exports the negotiated voltage and max-current in the form of a
  power-supply class device which represents the USB Type-C power-brick
  (adapter/charger)
- It adds a power_supply_set_input_current_limit_from_supplier helper
  function which charger drivers can use to get the max-current from
  their supplier
- It adds regulator support to the charger IC on the device I've. The
  exported regulator controls the 5v boost convertor which generates the
  5V USB vbus which gets output when the Type-C port is in host / power-src
  mode
- It adds a bunch of misc. related fixes and glue code to tie everything
  together

One thing which was undecided in the previous discussion was how to make
port-controller drivers hookup to external ICs (e.g. a non Type-C aware PMIC)
to decect the input-current-limit for USB2 power-sources (through e.g. BC1.2
detection). Since a number of existing drivers, including the one for the
PMIC used on the 2 mini laptops I'm working on, already use the extcon
framework to communicate the detected USB2 charger-type, I've decided to
simply hook into this existing code. As this patch set shows this can be
done with zero changes to the existing PMIC/extcon drivers.

With this series the GPD win and GPD pocket mini laptops both fully
support any type of Type-C charging. When hooked up with:
-A -> C cable and plugged into a regular port they charge at 5V 0.5A
-A -> C cable and plugged into a dedictaed charger they charge at 5V 2A
-C -> C cable and plugged into a fixed 5V 3A charger, at 5V 3A
-C -> C cable and plugged into a PD capable charger, which delivers max 12V, 2A
 they charge at 12V, 2A

And when a Type-C to USB-A receptacle (so host mode) cable gets plugged in
the port correctly supplies 5V to any plugged in USB-A peripherals.

This is v2 of this series, which has the following changes (see
changelog inside individual patches for details):

-Add "i2c: Allow overriding dev_name through board_info" patch, this is
 necessary for getting stable dev_names which are necessary for specifying
 regulator-mappings through regulator_init_data
-Use regulator_init_data to specify mapping,  drop "staging: typec:
 fusb302: Add support for fcs,vbus-regulator-name device-property" patch
-Merged helper code for port-c related extcon / power_supply handling
 directly into the fusb302 patches using the code, rather then trying
 to add generic helpers even though there is only 1 user
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 01/11] i2c: Allow overriding dev_name through board_info

[Hans de Goede]

For devices not instantiated through ACPI the i2c-client's device-name
gets set to - by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.

In some cases having a predictable constant device-name is desirable,
for example on non device-tree platforms the link between a regulator
and its consumers is specified by the platform code by setting
regulator_init_data.consumers. This array identifies the regulator's
consumers by dev_name and supply(-name). Which requires a constant
dev_name.

This commit adds a dev_name field to i2c_board_info allowing
platform code to set a contstant dev_name so that the device can
be identified by its dev_name in other platform code.

Signed-off-by: Hans de Goede 
---
 drivers/i2c/i2c-core-base.c | 10 --
 include/linux/i2c.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 45fafcc88b93..5cdf3b947c23 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -672,10 +672,16 @@ static void i2c_adapter_unlock_bus(struct i2c_adapter 
*adapter,
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
-struct i2c_client *client)
+struct i2c_client *client,
+struct i2c_board_info const *info)
 {
struct acpi_device *adev = ACPI_COMPANION(>dev);
 
+   if (info && info->dev_name) {
+   dev_set_name(>dev, "i2c-%s", info->dev_name);
+   return;
+   }
+
if (adev) {
dev_set_name(>dev, "i2c-%s", acpi_dev_name(adev));
return;
@@ -772,7 +778,7 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
client->dev.of_node = info->of_node;
client->dev.fwnode = info->fwnode;
 
-   i2c_dev_set_name(adap, client);
+   i2c_dev_set_name(adap, client, info);
 
if (info->properties) {
status = device_add_properties(>dev, info->properties);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 701ad26fa6b4..d3655cfe9a3e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -310,6 +310,7 @@ static inline bool i2c_detect_slave_mode(struct device 
*dev) { return false; }
  * @type: chip type, to initialize i2c_client.name
  * @flags: to initialize i2c_client.flags
  * @addr: stored in i2c_client.addr
+ * @dev_name: Overrides the default - dev_name if set
  * @platform_data: stored in i2c_client.dev.platform_data
  * @archdata: copied into i2c_client.dev.archdata
  * @of_node: pointer to OpenFirmware device node
@@ -334,6 +335,7 @@ struct i2c_board_info {
chartype[I2C_NAME_SIZE];
unsigned short  flags;
unsigned short  addr;
+   const char  *dev_name;
void*platform_data;
struct dev_archdata *archdata;
struct device_node *of_node;
-- 
2.13.4

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

Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared with user space

[Dan Carpenter]

On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote:
> Binder driver allocates buffer meta data in a region that is mapped
> in user space. These meta data contain pointers in the kernel.
> 
> This patch allocates buffer meta data on the kernel heap that is
> not mapped in user space, and uses a pointer to refer to the data mapped.
> 
> Also move alloc->buffers initialization from mmap to init since it's
> now used even when mmap failed or was not called.
> 
> Signed-off-by: Sherry Yang 
> ---

The difference between v2 and v3 is that we've shifted some
initialization around to fix the crashing bug that kbuild found.  You
should not that difference here under the --- cut off.

>  drivers/android/binder_alloc.c  | 146 
> +++-
>  drivers/android/binder_alloc.h  |   2 +-
>  drivers/android/binder_alloc_selftest.c |  11 ++-
>  3 files changed, 91 insertions(+), 68 deletions(-)

But really we still need to have some answers or discussion about the
questions that Greg and I raised.  Greg asked if the other Android devs
had Acked this.  Please ping Arve to Ack this.

I was curious about the security impact or why we were writing this
patch 3/6.  It seems we are fixing an information disclosure bug.  Or is
it something worse than that?  Or have I misunderstood entirely.

We probably original put the buffers in userspace for accounting reasons
so we could kill programs that used too much RAM.  This patch doesn't
create a problem with that hopefully?  We're just moving the metadata to
kernel space?

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

Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG

[Andreas Ziegler]

Indeed, sorry I missed that as well.

So what should we make of that #ifdef? The code inside it doesn't compile
(anymore? I didn't find any development history for that patch except the
original mail), as there is no definition of struct submit_ctx in the headers
(for other rtl drivers - 8188eu, 8723bs - that struct lives in
include/rtw_xmit.h). Is a comparable header simply missing?

Regards,

Andreas

On 08/29/17 16:42, Greg KH wrote:
> On Tue, Aug 29, 2017 at 09:10:10AM -0500, Larry Finger wrote:
>> On 08/29/2017 06:30 AM, Andreas Ziegler wrote:
>>> The debugging output in deinit_priv is guarded by an  #ifdef using
>>> CONFIG_RTL_DEBUG. This symbol does not exist and should be
>>> CONFIG_RTLWIFI_DEBUG instead.
>>>
>>> Signed-off-by: Andreas Ziegler 
>>
>> NACK.
>>
>> Yes, there is a problem; however, CONFIG_RTLWIFI_DEBUG is not the value that
>> should be used. That one is reserved for the non-staging drivers in
>> drivers/net/wireless/realtek/rtlwifi/. The correct symbol for r8822be is
>> CONFIG_RTLWIFI_DEBUG_ST.
> 
> Yeah, kbuild just blew up on this as well, I wonder why my local build
> testing didn't see that :(
> 
> Now dropped.
> 
> greg k-h
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

[Ye Xiaolong]

On 08/30, Greg Kroah-Hartman wrote:
>On Wed, Aug 30, 2017 at 02:04:11PM +0800, kernel test robot wrote:
>> FYI, we noticed the following commit:
>> 
>> commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to 
>> drivers/staging/irda/net/")
>> url: 
>> https://github.com/0day-ci/linux/commits/Greg-Kroah-Hartman/irda-move-it-to-drivers-staging-so-we-can-delete-it/20170829-090816
>> 
>> in testcase: trinity
>> with following parameters:
>> 
>>  runtime: 300s
>> 
>> test-description: Trinity is a linux system call fuzz tester.
>> test-url: http://codemonkey.org.uk/projects/trinity/
>> 
>> on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M
>> 
>> caused below changes (please refer to attached dmesg/kmsg for entire 
>> log/backtrace):
>> 
>> +-+++
>> | | 89ff9d58e6 | 
>> 66d98e78e4 |
>> +-+++
>> | boot_successes  | 0  | 0   
>>|
>> | boot_failures   | 10 | 12  
>>|
>> | IP-Config:Auto-configuration_of_network_failed  | 8  | 
>>|
>> | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 2  | 
>>|
>> | EIP:note_page   | 2  | 
>>|
>> | BUG:unable_to_handle_kernel | 0  | 12  
>>|
>> | Oops:#[##]  | 0  | 12  
>>|
>> | EIP:dev_add_pack| 0  | 12  
>>|
>> | Kernel_panic-not_syncing:Fatal_exception| 0  | 12  
>>|
>> +-+++
>> 
>> [0.227015] BUG: unable to handle kernel NULL pointer dereference at 
>> 0004
>> [0.228000] IP: dev_add_pack+0x37/0x80
>
>Didn't you report this yesterday as well?  Anyway, am working on it,
>give me a few hours to wake up and test...

Hi,

0day bot tested both the lkml patch and the commit in dev-queue branch of
next-queue.git tree, hence the duplicated report.

Thanks,
Xiaolong
>
>thanks,
>
>greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

[Greg Kroah-Hartman]

On Wed, Aug 30, 2017 at 02:04:11PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
> 
> commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to 
> drivers/staging/irda/net/")
> url: 
> https://github.com/0day-ci/linux/commits/Greg-Kroah-Hartman/irda-move-it-to-drivers-staging-so-we-can-delete-it/20170829-090816
> 
> in testcase: trinity
> with following parameters:
> 
>   runtime: 300s
> 
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
> 
> on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> +-+++
> | | 89ff9d58e6 | 
> 66d98e78e4 |
> +-+++
> | boot_successes  | 0  | 0
>   |
> | boot_failures   | 10 | 12   
>   |
> | IP-Config:Auto-configuration_of_network_failed  | 8  |  
>   |
> | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 2  |  
>   |
> | EIP:note_page   | 2  |  
>   |
> | BUG:unable_to_handle_kernel | 0  | 12   
>   |
> | Oops:#[##]  | 0  | 12   
>   |
> | EIP:dev_add_pack| 0  | 12   
>   |
> | Kernel_panic-not_syncing:Fatal_exception| 0  | 12   
>   |
> +-+++
> 
> [0.227015] BUG: unable to handle kernel NULL pointer dereference at 
> 0004
> [0.228000] IP: dev_add_pack+0x37/0x80

Didn't you report this yesterday as well?  Anyway, am working on it,
give me a few hours to wake up and test...

thanks,

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

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

[Greg Kroah-Hartman]

On Tue, Aug 29, 2017 at 05:46:57PM -0700, Sherry Yang wrote:
> Use helper functions buffer_next and buffer_prev instead
> of list_entry to get the next and previous buffers.
> 
> Signed-off-by: Sherry Yang 
> ---
>  drivers/android/binder_alloc.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)

What changed from the previous version?

Always put the changes below the --- line.  Like the documentation says
to do so.

Also, don't I already have these patches in my tree?  Do you want me to
revert the existing ones and use the new ones, or what about a fixup
patch for any differences?

confused,

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

[lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit:

commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to 
drivers/staging/irda/net/")
url: 
https://github.com/0day-ci/linux/commits/Greg-Kroah-Hartman/irda-move-it-to-drivers-staging-so-we-can-delete-it/20170829-090816

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/

on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):

+-+++
| | 89ff9d58e6 | 66d98e78e4 
|
+-+++
| boot_successes  | 0  | 0  
|
| boot_failures   | 10 | 12 
|
| IP-Config:Auto-configuration_of_network_failed  | 8  |
|
| WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 2  |
|
| EIP:note_page   | 2  |
|
| BUG:unable_to_handle_kernel | 0  | 12 
|
| Oops:#[##]  | 0  | 12 
|
| EIP:dev_add_pack| 0  | 12 
|
| Kernel_panic-not_syncing:Fatal_exception| 0  | 12 
|
+-+++

[0.227015] BUG: unable to handle kernel NULL pointer dereference at 0004
[0.228000] IP: dev_add_pack+0x37/0x80
[0.228000] *pdpt =  *pde = f000ff53f000ff53 
[0.228000] 
[0.228000] Oops: 0002 [#1] SMP
[0.228000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.13.0-rc5-00526-g66d98e7 #60
[0.228000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[0.228000] task: d3042040 task.stack: d3044000
[0.228000] EIP: dev_add_pack+0x37/0x80
[0.228000] EFLAGS: 00210286 CPU: 0
[0.228000] EAX:  EBX: c20c9318 ECX: d30424c8 EDX: c20c8c60
[0.228000] ESI: c20c8c4c EDI:  EBP: d3045f18 ESP: d3045f10
[0.228000]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[0.228000] CR0: 80050033 CR2: 0004 CR3: 022f4000 CR4: 06b0
[0.228000] Call Trace:
[0.228000]  ? irda_nl_register+0xf/0xf
[0.228000]  irda_init+0x30/0x88
[0.228000]  do_one_initcall+0x8b/0x131
[0.228000]  kernel_init_freeable+0xee/0x166
[0.228000]  ? rest_init+0x120/0x120
[0.228000]  kernel_init+0xb/0x100
[0.228000]  ? schedule_tail_wrapper+0x9/0xc
[0.228000]  ret_from_fork+0x19/0x24
[0.228000] Code: 03 00 00 74 3f 8b 5e 04 85 db 74 50 83 c3 5c b8 e0 6a 09 
c2 e8 ab 69 20 00 8b 03 8d 56 14 89 5e 18 89 46 14 0f ae f0 89 f6 89 13 <89> 50 
04 b8 e0 6a 09 c2 e8 cc 6d 20 00 5b 5e 5d c3 90 8d b4 26
[0.228000] EIP: dev_add_pack+0x37/0x80 SS:ESP: 0068:d3045f10
[0.228000] CR2: 0004
[0.228000] ---[ end trace 593bc6d2366a532d ]---

To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email

Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y