Re: kernel BUG at ./include/linux/mm.h:LINE! (3)

2018-01-02 Thread Pete Zaitcev
On Fri, 29 Dec 2017 16:24:20 +0300
"Kirill A. Shutemov"  wrote:

> Looks like MON_IOCT_RING_SIZE reallocates ring buffer without any
> serialization wrt mon_bin_vma_fault(). By the time of get_page() the page
> may be freed.

Okay. Who knew that you could fork while holding an open descriptor. :-)

> The patch below seems help the crash to go away, but I *think* more work
> is required. For instance, after ring buffer reallocation the old pages
> will stay mapped. Nothing pulls them.

You know, this bothered me all these years too, but I was assured
back in the day (as much as I can remember), that doing get_page()
in the .fault() is just the right thing. In my defense, you can
see other drivers doing it, such as:

./drivers/char/agp/alpha-agp.c
./drivers/hsi/clients/cmt_speech.c

I'd appreciate insight from someone who knows how VM subsystem works.

Now, about the code:

> diff --git a/drivers/usb/mon/mon_bin.c b/drivers/usb/mon/mon_bin.c
> index f6ae753ab99b..ac168fecf04f 100644
> --- a/drivers/usb/mon/mon_bin.c
> +++ b/drivers/usb/mon/mon_bin.c
> @@ -1228,15 +1228,24 @@ static void mon_bin_vma_close(struct vm_area_struct 
> *vma)
>  static int mon_bin_vma_fault(struct vm_fault *vmf)
>  {
>   struct mon_reader_bin *rp = vmf->vma->vm_private_data;
> - unsigned long offset, chunk_idx;
> + unsigned long offset, chunk_idx, flags;
>   struct page *pageptr;
>  
> + mutex_lock(>fetch_lock);
> + spin_lock_irqsave(>b_lock, flags);
>   offset = vmf->pgoff << PAGE_SHIFT;
> - if (offset >= rp->b_size)
> + if (offset >= rp->b_size) {
> + spin_unlock_irqrestore(>b_lock, flags);
> + mutex_unlock(>fetch_lock);
>   return VM_FAULT_SIGBUS;
> + }
>   chunk_idx = offset / CHUNK_SIZE;
> +
>   pageptr = rp->b_vec[chunk_idx].pg;
>   get_page(pageptr);
> + spin_unlock_irqrestore(>b_lock, flags);
> + mutex_unlock(>fetch_lock);
> +
>   vmf->page = pageptr;
>   return 0;
>  }

I think that grabbing the spinlock is not really necessary in
this case. The ->b_lock is designed for things that are accessed
from interrupts that Host Controller Driver serves -- mostly
various pointers. By defintion it's not covering things that
are related to re-allocation. Now, the re-allocation itself
grabs it, because it resets indexes into the new buffer, but
does not appear to apply here, does it now?

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 01/78] xfs: Rename xa_ elements to ail_

2018-01-02 Thread Darrick J. Wong
On Fri, Dec 15, 2017 at 02:03:33PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> This is a simple rename, except that xa_ail becomes ail_head.
> 
> Signed-off-by: Matthew Wilcox 

That was an eyeful,
Reviewed-by: Darrick J. Wong 

> ---
>  fs/xfs/xfs_buf_item.c|  10 ++--
>  fs/xfs/xfs_dquot.c   |   4 +-
>  fs/xfs/xfs_dquot_item.c  |  11 ++--
>  fs/xfs/xfs_inode_item.c  |  22 +++
>  fs/xfs/xfs_log.c |   6 +-
>  fs/xfs/xfs_log_recover.c |  80 -
>  fs/xfs/xfs_trans.c   |  18 +++---
>  fs/xfs/xfs_trans_ail.c   | 152 
> +++
>  fs/xfs/xfs_trans_buf.c   |   4 +-
>  fs/xfs/xfs_trans_priv.h  |  42 ++---
>  10 files changed, 175 insertions(+), 174 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
> index e0a0af0946f2..6c5035544a93 100644
> --- a/fs/xfs/xfs_buf_item.c
> +++ b/fs/xfs/xfs_buf_item.c
> @@ -459,7 +459,7 @@ xfs_buf_item_unpin(
>   bp->b_fspriv = NULL;
>   bp->b_iodone = NULL;
>   } else {
> - spin_lock(>xa_lock);
> + spin_lock(>ail_lock);
>   xfs_trans_ail_delete(ailp, lip, SHUTDOWN_LOG_IO_ERROR);
>   xfs_buf_item_relse(bp);
>   ASSERT(bp->b_fspriv == NULL);
> @@ -1056,13 +1056,13 @@ xfs_buf_do_callbacks_fail(
>   struct xfs_log_item *lip = bp->b_fspriv;
>   struct xfs_ail  *ailp = lip->li_ailp;
>  
> - spin_lock(>xa_lock);
> + spin_lock(>ail_lock);
>   for (; lip; lip = next) {
>   next = lip->li_bio_list;
>   if (lip->li_ops->iop_error)
>   lip->li_ops->iop_error(lip, bp);
>   }
> - spin_unlock(>xa_lock);
> + spin_unlock(>ail_lock);
>  }
>  
>  static bool
> @@ -1215,7 +1215,7 @@ xfs_buf_iodone(
>*
>* Either way, AIL is useless if we're forcing a shutdown.
>*/
> - spin_lock(>xa_lock);
> + spin_lock(>ail_lock);
>   xfs_trans_ail_delete(ailp, lip, SHUTDOWN_CORRUPT_INCORE);
>   xfs_buf_item_free(BUF_ITEM(lip));
>  }
> @@ -1236,7 +1236,7 @@ xfs_buf_resubmit_failed_buffers(
>   /*
>* Clear XFS_LI_FAILED flag from all items before resubmit
>*
> -  * XFS_LI_FAILED set/clear is protected by xa_lock, caller  this
> +  * XFS_LI_FAILED set/clear is protected by ail_lock, caller  this
>* function already have it acquired
>*/
>   for (; lip; lip = next) {
> diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c
> index f248708c10ff..e2a466df5dd1 100644
> --- a/fs/xfs/xfs_dquot.c
> +++ b/fs/xfs/xfs_dquot.c
> @@ -974,7 +974,7 @@ xfs_qm_dqflush_done(
>(lip->li_flags & XFS_LI_FAILED))) {
>  
>   /* xfs_trans_ail_delete() drops the AIL lock. */
> - spin_lock(>xa_lock);
> + spin_lock(>ail_lock);
>   if (lip->li_lsn == qip->qli_flush_lsn) {
>   xfs_trans_ail_delete(ailp, lip, 
> SHUTDOWN_CORRUPT_INCORE);
>   } else {
> @@ -984,7 +984,7 @@ xfs_qm_dqflush_done(
>*/
>   if (lip->li_flags & XFS_LI_FAILED)
>   xfs_clear_li_failed(lip);
> - spin_unlock(>xa_lock);
> + spin_unlock(>ail_lock);
>   }
>   }
>  
> diff --git a/fs/xfs/xfs_dquot_item.c b/fs/xfs/xfs_dquot_item.c
> index 664dea105e76..62637a226601 100644
> --- a/fs/xfs/xfs_dquot_item.c
> +++ b/fs/xfs/xfs_dquot_item.c
> @@ -160,8 +160,9 @@ xfs_dquot_item_error(
>  STATIC uint
>  xfs_qm_dquot_logitem_push(
>   struct xfs_log_item *lip,
> - struct list_head*buffer_list) __releases(>li_ailp->xa_lock)
> -   __acquires(>li_ailp->xa_lock)
> + struct list_head*buffer_list)
> + __releases(>li_ailp->ail_lock)
> + __acquires(>li_ailp->ail_lock)
>  {
>   struct xfs_dquot*dqp = DQUOT_ITEM(lip)->qli_dquot;
>   struct xfs_buf  *bp = lip->li_buf;
> @@ -208,7 +209,7 @@ xfs_qm_dquot_logitem_push(
>   goto out_unlock;
>   }
>  
> - spin_unlock(>li_ailp->xa_lock);
> + spin_unlock(>li_ailp->ail_lock);
>  
>   error = xfs_qm_dqflush(dqp, );
>   if (error) {
> @@ -220,7 +221,7 @@ xfs_qm_dquot_logitem_push(
>   xfs_buf_relse(bp);
>   }
>  
> - spin_lock(>li_ailp->xa_lock);
> + spin_lock(>li_ailp->ail_lock);
>  out_unlock:
>   xfs_dqunlock(dqp);
>   return rval;
> @@ -403,7 +404,7 @@ xfs_qm_qoffend_logitem_committed(
>* Delete the qoff-start logitem from the AIL.
>* xfs_trans_ail_delete() drops the AIL lock.
>*/
> - spin_lock(>xa_lock);
> + spin_lock(>ail_lock);
>   xfs_trans_ail_delete(ailp, >qql_item, SHUTDOWN_LOG_IO_ERROR);
>  
> 

Re: [PATCH] USB: usbip: remove useless call in usbip_recv

2018-01-02 Thread Shuah Khan
On 01/02/2018 07:02 AM, Gustavo A. R. Silva wrote:
> Calling msg_data_left() is only useful for its return value,
> which in this particular case is ignored.
> 
> Fix this by removing such call.
> 
> Addresses-Coverity-ID: 1427080
> Fixes: 90120d15f4c3 ("usbip: prevent leaking socket pointer address in 
> messages")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/usbip/usbip_common.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/usbip/usbip_common.c 
> b/drivers/usb/usbip/usbip_common.c
> index 7b219d9..b5af6fc 100644
> --- a/drivers/usb/usbip/usbip_common.c
> +++ b/drivers/usb/usbip/usbip_common.c
> @@ -325,7 +325,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
>   usbip_dbg_xmit("enter\n");
>  
>   do {
> - msg_data_left();
>   sock->sk->sk_allocation = GFP_NOIO;
>  
>   result = sock_recvmsg(sock, , MSG_WAITALL);
> 

Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 03/78] xarray: Add the xa_lock to the radix_tree_root

2018-01-02 Thread Matthew Wilcox
On Tue, Jan 02, 2018 at 10:01:55AM -0800, Darrick J. Wong wrote:
> On Tue, Dec 26, 2017 at 07:58:15PM -0800, Matthew Wilcox wrote:
> > spin_lock_irqsave(>pages, flags);
> > __delete_from_page_cache(page, NULL);
> > spin_unlock_irqrestore(>pages, flags);
> >
> > More details here: https://9p.io/sys/doc/compiler.html
> 
> I read the link, and I understand (from section 3.3) that replacing
> foo.bar.baz.goo with foo.goo is less typing, but otoh the first time I
> read your example above I thought "we're passing (an array of pages |
> something that doesn't have the word 'lock' in the name) to
> spin_lock_irqsave? wtf?"

I can see that being a bit jarring initially.  If you think about what
object-oriented languages were offering in the nineties, this is basically
C++ multiple-inheritance / Java interfaces.  So when I read the above
example, I think "lock the mapping pages, delete from page cache, unlock
the mapping pages", and I don't have a wtf moment.  It's just simpler to
read than "lock the mapping pages lock", and less redundant.

> I suppose it does force me to go dig into whatever mapping->pages is to
> figure out that there's an unnamed spinlock_t and that the compiler can
> insert the appropriate pointer arithmetic, but now my brain trips over
> 'pages' being at the end of the selector for parameter 1 which slows
> down my review reading...
> 
> OTOH I guess it /did/ motivate me to click the link, so well played,
> sir. :)

Now if only I can trick you into giving your ACK on patch 1,
"xfs: Rename xa_ elements to ail_"
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 4.14.10-gentoo-r1 breaks Heimdall + cups functionality

2018-01-02 Thread Greg KH
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Tue, Jan 02, 2018 at 08:46:30PM +0100, Roman Gruber wrote:
> Hi
> 
> Abstract: Heimdall does not work with 4.14.10-gentoo-r1.
> Heimdall is an open source SAMSUNG odin protocol software to write custom 
> software to SAMSUNG ANDROID Tablets over USB.

What does that have to do with your printer?

I merely asked for the kernel log messages for when you plug in your USB
printer.  You can get this by doing from a console:
sudo dmesg -c
plug in the device
dmesg > log_messages.txt
and then email the contents of log_messages.txt to us.

Don't get confused with tablet updates and the like, that's not the
issue here at all.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625

2018-01-02 Thread David Miller
From: SZ Lin (林上智) 
Date: Fri, 29 Dec 2017 17:02:17 +0800

> This patch adds support for PID 0x9625 of YUGA CLM920-NC5.
> 
> YUGA CLM920-NC5 needs to enable QMI_WWAN_QUIRK_DTR before QMI operation.
> 
> qmicli -d /dev/cdc-wdm0 -p --dms-get-revision
> [/dev/cdc-wdm0] Device revision retrieved:
> Revision: 'CLM920_NC5-V1  1  [Oct 23 2016 19:00:00]'
> 
> Signed-off-by: SZ Lin (林上智) 

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


4.14.10-gentoo-r1 breaks Heimdall + cups functionality

2018-01-02 Thread Roman Gruber
Hi

Abstract: Heimdall does not work with 4.14.10-gentoo-r1.
Heimdall is an open source SAMSUNG odin protocol software to write custom 
software to SAMSUNG ANDROID Tablets over USB.

Going back to kernel 4.9.73-gentoo seems to have fixed it. A very small chance 
that the --no-reboot option of heimdall did the trick. that is up to 
discussion. Fact is an older kernel works on my side with cups and heimdall on 
the first try. 


I'll quote you the text which I have written in 
https://bugzilla.kernel.org/show_bug.cgi?id=198329

--
I will not make another bug report. Similar issue also related to USB but not 
CUPS related
Same box. Reverted to newest stable kernel.org gentoo based kernel.
roman@ASUS-G75VW ~ $ uname -a
Linux ASUS-G75VW 4.9.73-gentoo-03-01-2018 #3 SMP Tue Jan 2 16:36:33 CET 2018 
x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux
forum: 
https://forum.xda-developers.com/galaxy-tab-a/help/heimdall-t3701920/page2
My user name there: __roman__
Please pay attention to post #12
I was unable to flash TWRP recovery to my SAMSUNG Tablet with heimdall.
I'm kinda certain as cups was misbehaving and also heimdall it is a kernel 
issue.
Heimdall is the open source software to use the SAMSUNG odin protocol to write 
custom software like recovery to SAMSUNG TABLETS.
Only thing I changed regarding heimdall was the Kernel.
Only changes I did because I want to enforce fixed lowest cpu frequency was: 
CONFIG_X86_ACPI_CPUFREQ: M; X86_PCC_CPUFREQ [=m]; X86_INTEL_PSTATE [=n] 
(disable that as it is broken, i want 3 hours of battery life out of my 
notebook when i am on the road!)
There is small chance that --no-reboot option of heimdall may be the root cause 
but I highly doubt it. AS heimdall and cups were "broken" in my point of view 
as a user. And a long term gentoo user ~12-13 years. I used linux on other 
distros before also like SUSE 6.2. slackware 96 and such.
I tried several times to write custom recovery with heimdall.
i used several hours to get the printer working with kernel 4.14.x
I tested all different use-flags for cups and other packages. 
new cups config folder and such.
using an older kernel + grabing /cups folder from a backup (maybe 2 weeks old 
backup i suppose) fixed it
gentoo does not touch config files in /etc
I did that to rule out a mistake on my side, so i grabbed from a full backup 
the hole cups folder in etc.
For myself the issue is resolved. Broken kernel. I had different issues with 
other kernel branches also, which do not exists as of a few hours ago. 4.10 / 
4.12 / 4.13
I will see in a few weeks if kernel branch 4.9.x is useable for myself.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 03/78] xarray: Add the xa_lock to the radix_tree_root

2018-01-02 Thread Darrick J. Wong
On Tue, Dec 26, 2017 at 07:58:15PM -0800, Matthew Wilcox wrote:
> On Tue, Dec 26, 2017 at 07:43:40PM -0800, Matthew Wilcox wrote:
> > Also add the xa_lock() and xa_unlock() family of wrappers to make it
> > easier to use the lock.  If we could rely on -fplan9-extensions in
> > the compiler, we could avoid all of this syntactic sugar, but that
> > wasn't added until gcc 4.6.
> 
> Oh, in case anyone's wondering, here's how I'd do it with plan9 extensions:
> 
> struct xarray {
> spinlock_t;
> int xa_flags;
> void *xa_head;
> };
> 
> ...
> spin_lock_irqsave(>pages, flags);
> __delete_from_page_cache(page, NULL);
> spin_unlock_irqrestore(>pages, flags);
> ...
> 
> The plan9 extensions permit passing a pointer to a struct which has an
> unnamed element to a function which is expecting a pointer to the type
> of that element.  The compiler does any necessary arithmetic to produce 
> a pointer.  It's exactly as if I had written:
> 
> spin_lock_irqsave(>pages.xa_lock, flags);
> __delete_from_page_cache(page, NULL);
> spin_unlock_irqrestore(>pages.xa_lock, flags);
> 
> More details here: https://9p.io/sys/doc/compiler.html

I read the link, and I understand (from section 3.3) that replacing
foo.bar.baz.goo with foo.goo is less typing, but otoh the first time I
read your example above I thought "we're passing (an array of pages |
something that doesn't have the word 'lock' in the name) to
spin_lock_irqsave? wtf?"

I suppose it does force me to go dig into whatever mapping->pages is to
figure out that there's an unnamed spinlock_t and that the compiler can
insert the appropriate pointer arithmetic, but now my brain trips over
'pages' being at the end of the selector for parameter 1 which slows
down my review reading...

OTOH I guess it /did/ motivate me to click the link, so well played,
sir. :)

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] tools: usb: usbip_device_driver: prefer 'unsigned int' to 'unsigned'

2018-01-02 Thread Shuah Khan
On 12/30/2017 09:11 AM, Elad Wexler wrote:
> Fixup a coding style issue
> 
> Signed-off-by: Elad Wexler 


Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] tools: usb: usbip: fix fd leak in case of 'fread' failure

2018-01-02 Thread Shuah Khan
On 12/30/2017 09:01 AM, Elad Wexler wrote:
> Fix possible resource leak: fd
> 
> Signed-off-by: Elad Wexler 

Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 0/7] typec: tcpm: Add sink side support for PPS

2018-01-02 Thread Adam Thomson
This patch set adds sink side support for the PPS feature introduced in the
USB PD 3.0 specification.

The source PPS supply is represented using the Power Supply framework to provide
access and control APIs for dealing with it's operating voltage and current,
and switching between a standard PDO and PPS APDO operation. During standard PDO
operation the voltage and current is read-only, but for APDO PPS these are
writable as well to allow for control.

It should be noted that the keepalive for PPS is not handled within TCPM. The
expectation is that the external user will be required to ensure re-requests
occur regularly to ensure PPS remains and the source does not hard reset.

Changes in v4:
 - For PD 3.0 definitions patch, make it benign with regards to existing TCPM
   code so build isn't broken if this one patch is applied, as suggested by
   kbuild robot. Update for dynamic revision is moved to be part of sink side
   PPS support patch.
 - Use PTR_ERR_OR_ZERO macro to simplify return of devm_tcpm_psy_register()
   function, as suggested by kbuild robot.
 - Make devm_tcpm_psy_register() static as not used outside this file.

Changes in v3:
 - Drop 'RFC' from patch series titles
 - Rename PPS related defines to be PPS specific rather than generic APDO titles
 - Update source caps logging to only print PPS APDOs, and for others report as
   undefined.
 - Add ABI documentation for tcpm-source-psy sysfs properties
 - Rebase PDO selection on top of 'typec: tcpm: Only request matching pdos'
   patch.
 - Update capabilities validation introduced in
   'typec: tcpm: Validate source and sink caps' to support PPS APDOs.
 - Dropped power_supply 'type' property update for PPS addition
 - Added 'connected_type' property to power_supply framework, to support
   supplies which can report multiple connected types (e.g. USB), as discussed
   with Heikki.

Changes in v2:
 - Use USB_PD and usb_pd prefixes for macros and inline functions in headers.
 - Negotiate spec revision of PD headers during initial contract agreement.
 - New headers now use SPDX tags for referencing correct license.

NOTE: Code changes are based on linux-next tag 'next-20171212' to pick up
capabilities validation and selection updates.

Adam Thomson (7):
  typec: tcpm: Add PD Rev 3.0 definitions to PD header
  typec: tcpm: Add ADO header for Alert message handling
  typec: tcpm: Add SDB header for Status message handling
  typec: tcpm: Add core support for sink side PPS
  power: supply: Add 'connected_type' property and supporting code
  typec: tcpm: Represent source supply through power_supply class
  typec: tcpm: Add support for sink PPS related messages

 .../ABI/testing/sysfs-class-power-tcpm-source-psy  |  92 +++
 drivers/power/supply/power_supply_sysfs.c  |  50 ++
 drivers/usb/typec/Kconfig  |   1 +
 drivers/usb/typec/fusb302/Kconfig  |   2 +-
 drivers/usb/typec/fusb302/fusb302.c|  63 +-
 drivers/usb/typec/tcpm.c   | 916 -
 include/linux/power_supply.h   |  15 +
 include/linux/usb/pd.h | 187 -
 include/linux/usb/pd_ado.h |  42 +
 include/linux/usb/pd_ext_sdb.h |  31 +
 include/linux/usb/tcpm.h   |   2 +-
 11 files changed, 1306 insertions(+), 95 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy
 create mode 100644 include/linux/usb/pd_ado.h
 create mode 100644 include/linux/usb/pd_ext_sdb.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 3/7] typec: tcpm: Add SDB header for Status message handling

2018-01-02 Thread Adam Thomson
This commit adds a header providing definitions for handling
Status messages. Currently the header only focuses on handling
incoming Status messages.

Signed-off-by: Adam Thomson 
---
 include/linux/usb/pd_ext_sdb.h | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/linux/usb/pd_ext_sdb.h

diff --git a/include/linux/usb/pd_ext_sdb.h b/include/linux/usb/pd_ext_sdb.h
new file mode 100644
index 000..0eb83ce
--- /dev/null
+++ b/include/linux/usb/pd_ext_sdb.h
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017 Dialog Semiconductor
+ *
+ * Author: Adam Thomson 
+ */
+
+#ifndef __LINUX_USB_PD_EXT_SDB_H
+#define __LINUX_USB_PD_EXT_SDB_H
+
+/* SDB : Status Data Block */
+enum usb_pd_ext_sdb_fields {
+   USB_PD_EXT_SDB_INTERNAL_TEMP = 0,
+   USB_PD_EXT_SDB_PRESENT_INPUT,
+   USB_PD_EXT_SDB_PRESENT_BATT_INPUT,
+   USB_PD_EXT_SDB_EVENT_FLAGS,
+   USB_PD_EXT_SDB_TEMP_STATUS,
+   USB_PD_EXT_SDB_DATA_SIZE,
+};
+
+/* Event Flags */
+#define USB_PD_EXT_SDB_EVENT_OCP   BIT(1)
+#define USB_PD_EXT_SDB_EVENT_OTP   BIT(2)
+#define USB_PD_EXT_SDB_EVENT_OVP   BIT(3)
+#define USB_PD_EXT_SDB_EVENT_CF_CV_MODEBIT(4)
+
+#define USB_PD_EXT_SDB_PPS_EVENTS  (USB_PD_EXT_SDB_EVENT_OCP | \
+USB_PD_EXT_SDB_EVENT_OTP | \
+USB_PD_EXT_SDB_EVENT_OVP)
+
+#endif /* __LINUX_USB_PD_EXT_SDB_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 1/7] typec: tcpm: Add PD Rev 3.0 definitions to PD header

2018-01-02 Thread Adam Thomson
This commit adds definitions for PD Rev 3.0 messages, including
APDO PPS and extended message support for TCPM.

Signed-off-by: Adam Thomson 
---
 include/linux/usb/pd.h | 185 ++---
 1 file changed, 174 insertions(+), 11 deletions(-)

diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index b3d41d7..ff359bdf 100644
--- a/include/linux/usb/pd.h
+++ b/include/linux/usb/pd.h
@@ -35,6 +35,13 @@ enum pd_ctrl_msg_type {
PD_CTRL_WAIT = 12,
PD_CTRL_SOFT_RESET = 13,
/* 14-15 Reserved */
+   PD_CTRL_NOT_SUPP = 16,
+   PD_CTRL_GET_SOURCE_CAP_EXT = 17,
+   PD_CTRL_GET_STATUS = 18,
+   PD_CTRL_FR_SWAP = 19,
+   PD_CTRL_GET_PPS_STATUS = 20,
+   PD_CTRL_GET_COUNTRY_CODES = 21,
+   /* 22-31 Reserved */
 };
 
 enum pd_data_msg_type {
@@ -43,13 +50,39 @@ enum pd_data_msg_type {
PD_DATA_REQUEST = 2,
PD_DATA_BIST = 3,
PD_DATA_SINK_CAP = 4,
-   /* 5-14 Reserved */
+   PD_DATA_BATT_STATUS = 5,
+   PD_DATA_ALERT = 6,
+   PD_DATA_GET_COUNTRY_INFO = 7,
+   /* 8-14 Reserved */
PD_DATA_VENDOR_DEF = 15,
+   /* 16-31 Reserved */
+};
+
+enum pd_ext_msg_type {
+   /* 0 Reserved */
+   PD_EXT_SOURCE_CAP_EXT = 1,
+   PD_EXT_STATUS = 2,
+   PD_EXT_GET_BATT_CAP = 3,
+   PD_EXT_GET_BATT_STATUS = 4,
+   PD_EXT_BATT_CAP = 5,
+   PD_EXT_GET_MANUFACTURER_INFO = 6,
+   PD_EXT_MANUFACTURER_INFO = 7,
+   PD_EXT_SECURITY_REQUEST = 8,
+   PD_EXT_SECURITY_RESPONSE = 9,
+   PD_EXT_FW_UPDATE_REQUEST = 10,
+   PD_EXT_FW_UPDATE_RESPONSE = 11,
+   PD_EXT_PPS_STATUS = 12,
+   PD_EXT_COUNTRY_INFO = 13,
+   PD_EXT_COUNTRY_CODES = 14,
+   /* 15-31 Reserved */
 };
 
 #define PD_REV10   0x0
 #define PD_REV20   0x1
+#define PD_REV30   0x2
+#define PD_MAX_REV PD_REV30
 
+#define PD_HEADER_EXT_HDR  BIT(15)
 #define PD_HEADER_CNT_SHIFT12
 #define PD_HEADER_CNT_MASK 0x7
 #define PD_HEADER_ID_SHIFT 9
@@ -59,18 +92,19 @@ enum pd_data_msg_type {
 #define PD_HEADER_REV_MASK 0x3
 #define PD_HEADER_DATA_ROLEBIT(5)
 #define PD_HEADER_TYPE_SHIFT   0
-#define PD_HEADER_TYPE_MASK0xf
+#define PD_HEADER_TYPE_MASK0x1f
 
-#define PD_HEADER(type, pwr, data, id, cnt)\
+#define PD_HEADER(type, pwr, data, rev, id, cnt, ext_hdr)  \
type) & PD_HEADER_TYPE_MASK) << PD_HEADER_TYPE_SHIFT) | \
 ((pwr) == TYPEC_SOURCE ? PD_HEADER_PWR_ROLE : 0) | \
 ((data) == TYPEC_HOST ? PD_HEADER_DATA_ROLE : 0) | \
-(PD_REV20 << PD_HEADER_REV_SHIFT) |\
+(rev << PD_HEADER_REV_SHIFT) | \
 (((id) & PD_HEADER_ID_MASK) << PD_HEADER_ID_SHIFT) |   \
-(((cnt) & PD_HEADER_CNT_MASK) << PD_HEADER_CNT_SHIFT))
+(((cnt) & PD_HEADER_CNT_MASK) << PD_HEADER_CNT_SHIFT) |\
+((ext_hdr) ? PD_HEADER_EXT_HDR : 0))
 
 #define PD_HEADER_LE(type, pwr, data, id, cnt) \
-   cpu_to_le16(PD_HEADER((type), (pwr), (data), (id), (cnt)))
+   cpu_to_le16(PD_HEADER((type), (pwr), (data), PD_REV20, (id), (cnt), 
(0)))
 
 static inline unsigned int pd_header_cnt(u16 header)
 {
@@ -102,16 +136,75 @@ static inline unsigned int pd_header_msgid_le(__le16 
header)
return pd_header_msgid(le16_to_cpu(header));
 }
 
+static inline unsigned int pd_header_rev(u16 header)
+{
+   return (header >> PD_HEADER_REV_SHIFT) & PD_HEADER_REV_MASK;
+}
+
+static inline unsigned int pd_header_rev_le(__le16 header)
+{
+   return pd_header_rev(le16_to_cpu(header));
+}
+
+#define PD_EXT_HDR_CHUNKED BIT(15)
+#define PD_EXT_HDR_CHUNK_NUM_SHIFT 11
+#define PD_EXT_HDR_CHUNK_NUM_MASK  0xf
+#define PD_EXT_HDR_REQ_CHUNK   BIT(10)
+#define PD_EXT_HDR_DATA_SIZE_SHIFT 0
+#define PD_EXT_HDR_DATA_SIZE_MASK  0x1ff
+
+#define PD_EXT_HDR(data_size, req_chunk, chunk_num, chunked)   
\
+   data_size) & PD_EXT_HDR_DATA_SIZE_MASK) << 
PD_EXT_HDR_DATA_SIZE_SHIFT) |\
+((req_chunk) ? PD_EXT_HDR_REQ_CHUNK : 0) | 
\
+(((chunk_num) & PD_EXT_HDR_CHUNK_NUM_MASK) << 
PD_EXT_HDR_CHUNK_NUM_SHIFT) |\
+((chunked) ? PD_EXT_HDR_CHUNKED : 0))
+
+#define PD_EXT_HDR_LE(data_size, req_chunk, chunk_num, chunked) \
+   cpu_to_le16(PD_EXT_HDR((data_size), (req_chunk), (chunk_num), 
(chunked)))
+
+static inline unsigned int pd_ext_header_chunk_num(u16 ext_header)
+{
+   return (ext_header >> PD_EXT_HDR_CHUNK_NUM_SHIFT) &
+   PD_EXT_HDR_CHUNK_NUM_MASK;
+}
+
+static inline unsigned int pd_ext_header_data_size(u16 ext_header)
+{
+   return (ext_header >> PD_EXT_HDR_DATA_SIZE_SHIFT) &
+   PD_EXT_HDR_DATA_SIZE_MASK;
+}
+
+static inline unsigned int pd_ext_header_data_size_le(__le16 ext_header)
+{
+

[PATCH v4 4/7] typec: tcpm: Add core support for sink side PPS

2018-01-02 Thread Adam Thomson
This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.

Signed-off-by: Adam Thomson 
---
 drivers/usb/typec/tcpm.c | 533 ++-
 include/linux/usb/pd.h   |   4 +-
 include/linux/usb/tcpm.h |   2 +-
 3 files changed, 525 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563e..b66d26c 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -47,6 +47,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES),   \
S(SNK_NEGOTIATE_CAPABILITIES),  \
+   S(SNK_NEGOTIATE_PPS_CAPABILITIES),  \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY),   \
@@ -166,6 +167,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
 };
 
+struct pd_pps_data {
+   u32 min_volt;
+   u32 max_volt;
+   u32 max_curr;
+   u32 out_volt;
+   u32 op_curr;
+   bool supported;
+   bool active;
+};
+
 struct tcpm_port {
struct device *dev;
 
@@ -233,6 +244,7 @@ struct tcpm_port {
struct completion swap_complete;
int swap_status;
 
+   unsigned int negotiated_rev;
unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -255,6 +267,7 @@ struct tcpm_port {
unsigned int nr_fixed; /* number of fixed sink PDOs */
unsigned int nr_var; /* number of variable sink PDOs */
unsigned int nr_batt; /* number of battery sink PDOs */
+   unsigned int nr_apdo; /* number of APDO type PDOs */
u32 snk_vdo[VDO_MAX_OBJECTS];
unsigned int nr_snk_vdo;
 
@@ -262,6 +275,7 @@ struct tcpm_port {
unsigned int max_snk_ma;
unsigned int max_snk_mw;
unsigned int operating_snk_mw;
+   bool update_sink_caps;
 
/* Requested current / voltage */
u32 current_limit;
@@ -278,8 +292,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
 
-   /* Alternate mode data */
+   /* PPS */
+   struct pd_pps_data pps_data;
+   struct completion pps_complete;
+   bool pps_pending;
+   int pps_status;
 
+   /* Alternate mode data */
struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -497,6 +516,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+   else
+   strcpy(msg, "undefined APDO");
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -791,11 +820,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port 
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_src_pdo);
}
@@ -816,11 +847,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
  port->pwr_role,
  port->data_role,
+   

[PATCH v4 2/7] typec: tcpm: Add ADO header for Alert message handling

2018-01-02 Thread Adam Thomson
This commit adds a header providing definitions for handling Alert
messages. Currently the header only focuses on handling incoming
alerts.

Signed-off-by: Adam Thomson 
---
 include/linux/usb/pd_ado.h | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 include/linux/usb/pd_ado.h

diff --git a/include/linux/usb/pd_ado.h b/include/linux/usb/pd_ado.h
new file mode 100644
index 000..9aa1cf3
--- /dev/null
+++ b/include/linux/usb/pd_ado.h
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017 Dialog Semiconductor
+ *
+ * Author: Adam Thomson 
+ */
+
+#ifndef __LINUX_USB_PD_ADO_H
+#define __LINUX_USB_PD_ADO_H
+
+/* ADO : Alert Data Object */
+#define USB_PD_ADO_TYPE_SHIFT  24
+#define USB_PD_ADO_TYPE_MASK   0xff
+#define USB_PD_ADO_FIXED_BATT_SHIFT20
+#define USB_PD_ADO_FIXED_BATT_MASK 0xf
+#define USB_PD_ADO_HOT_SWAP_BATT_SHIFT 16
+#define USB_PD_ADO_HOT_SWAP_BATT_MASK  0xf
+
+#define USB_PD_ADO_TYPE_BATT_STATUS_CHANGE BIT(1)
+#define USB_PD_ADO_TYPE_OCPBIT(2)
+#define USB_PD_ADO_TYPE_OTPBIT(3)
+#define USB_PD_ADO_TYPE_OP_COND_CHANGE BIT(4)
+#define USB_PD_ADO_TYPE_SRC_INPUT_CHANGE   BIT(5)
+#define USB_PD_ADO_TYPE_OVPBIT(6)
+
+static inline unsigned int usb_pd_ado_type(u32 ado)
+{
+   return (ado >> USB_PD_ADO_TYPE_SHIFT) & USB_PD_ADO_TYPE_MASK;
+}
+
+static inline unsigned int usb_pd_ado_fixed_batt(u32 ado)
+{
+   return (ado >> USB_PD_ADO_FIXED_BATT_SHIFT) &
+  USB_PD_ADO_FIXED_BATT_MASK;
+}
+
+static inline unsigned int usb_pd_ado_hot_swap_batt(u32 ado)
+{
+   return (ado >> USB_PD_ADO_HOT_SWAP_BATT_SHIFT) &
+  USB_PD_ADO_HOT_SWAP_BATT_MASK;
+}
+#endif /* __LINUX_USB_PD_ADO_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 5/7] power: supply: Add 'connected_type' property and supporting code

2018-01-02 Thread Adam Thomson
This commit adds the 'connected_type' property to represent supplies
which can report a number of different types of supply based on a
connection event.

Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.

The 'connected_type' property is intended to fill this void and show
users all possible types supported by a driver. The property, when
read, shows all available types for the driver, and the one currently
chosen is highlighted/bracketed. It is expected that the 'type'
property would then just show the top-level type, such as 'USB', and
this would be static.

Currently the 'conn_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
the PPS type. In the future this can be extended further for other
types which have multiple connected types supported. The mirroring
is intentional so as to not impact existing usage of the 'type'
property.

Signed-off-by: Adam Thomson 
---
 drivers/power/supply/power_supply_sysfs.c | 50 +++
 include/linux/power_supply.h  | 15 ++
 2 files changed, 65 insertions(+)

diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..1b3b202 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
 };
 
+static const char * const power_supply_conn_type_text[] = {
+   "Unknown", "USB_DCP", "USB_CDP", "USB_ACA", "USB_C",
+   "USB_PD", "USB_PD_DRP", "USB_PD_PPS", "BrickID"
+};
+
 static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
 };
@@ -73,6 +78,46 @@
"Unknown", "System", "Device"
 };
 
+static ssize_t power_supply_show_conn_type(struct device *dev,
+  enum power_supply_conn_type 
*conn_types,
+  ssize_t num_conn_types,
+  union power_supply_propval *value,
+  char *buf)
+{
+   enum power_supply_conn_type conn_type;
+   ssize_t count = 0;
+   bool match = false;
+   int i;
+
+   if ((!conn_types) || (num_conn_types <= 0)) {
+   dev_warn(dev, "driver has no valid connected types\n");
+   return -ENODATA;
+   }
+
+   for (i = 0; i < num_conn_types; ++i) {
+   conn_type = conn_types[i];
+
+   if (value->intval == conn_type) {
+   count += sprintf(buf + count, "[%s] ",
+
power_supply_conn_type_text[conn_type]);
+   match = true;
+   } else {
+   count += sprintf(buf + count, "%s ",
+
power_supply_conn_type_text[conn_type]);
+   }
+   }
+
+   if (!match) {
+   dev_warn(dev, "driver reporting unsupported connected type\n");
+   return -EINVAL;
+   }
+
+   if (count)
+   buf[count - 1] = '\n';
+
+   return count;
+}
+
 static ssize_t power_supply_show_property(struct device *dev,
  struct device_attribute *attr,
  char *buf) {
@@ -115,6 +160,10 @@ static ssize_t power_supply_show_property(struct device 
*dev,
else if (off == POWER_SUPPLY_PROP_TYPE)
return sprintf(buf, "%s\n",
   power_supply_type_text[value.intval]);
+   else if (off == POWER_SUPPLY_PROP_CONNECTED_TYPE)
+   return power_supply_show_conn_type(dev, psy->desc->conn_types,
+  psy->desc->num_conn_types,
+  , buf);
else if (off == POWER_SUPPLY_PROP_SCOPE)
return sprintf(buf, "%s\n",
   power_supply_scope_text[value.intval]);
@@ -241,6 +290,7 @@ static ssize_t power_supply_store_property(struct device 
*dev,
POWER_SUPPLY_ATTR(time_to_full_now),
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
+   POWER_SUPPLY_ATTR(connected_type),
POWER_SUPPLY_ATTR(scope),
POWER_SUPPLY_ATTR(precharge_current),
POWER_SUPPLY_ATTR(charge_term_current),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 79e90b3..e15a629 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -145,6 +145,7 @@ enum power_supply_property {

[PATCH v4 6/7] typec: tcpm: Represent source supply through power_supply class

2018-01-02 Thread Adam Thomson
This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.

For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.

As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'

Signed-off-by: Adam Thomson 
---
 .../ABI/testing/sysfs-class-power-tcpm-source-psy  |  92 
 drivers/usb/typec/Kconfig  |   1 +
 drivers/usb/typec/fusb302/Kconfig  |   2 +-
 drivers/usb/typec/fusb302/fusb302.c|  63 +-
 drivers/usb/typec/tcpm.c   | 233 -
 5 files changed, 328 insertions(+), 63 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy

diff --git a/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy 
b/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy
new file mode 100644
index 000..4986cba
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy
@@ -0,0 +1,92 @@
+What:  /sys/class/power_supply/tcpm-source-psy/type
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-only property describes the main type of source supply.
+   Type-C is a USB standard so this property always returns "USB".
+
+What:  /sys/class/power_supply/tcpm-source-psy/connected_type
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-only property describes the type of source supply that is
+   connected, if the supply is online. The value is always Type C
+   unless a source has been attached which is identified as USB-PD capable.
+
+   Valid values:
+   - "USB_TYPE_C"  : Type C connected supply, not UBS-PD capable
+ (default value)
+   - "USB_PD"  : USB-PD capable source supply connected
+   - "USB_PD_PPS"  : USB-PD PPS capable source supply connected
+
+What:  /sys/class/power_supply/tcpm-source-psy/online
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-write property describes the online state of the source
+   supply. When the value of this property is not 0, and the supply allows
+   it, then it's possible to switch between online states (i.e. 1 -> 2,
+   2 -> 1)
+
+   Valid values:
+   - 0 : Offline, no source supply attached
+   - 1 : Fixed Online, Type-C or USB-PD capable supply
+ attached, non-configurable current and voltage
+ properties in this state.
+   - 2 : PPS Online, USB-PD PPS feature enabled, 'current_now'
+ and 'voltage_now' properties can be modified in this
+ state. Re-writing of this value again, once already
+ set, will re-request the same configured voltage and
+ current values. This can be used as a keep-alive for
+ the PPS connection.
+ [NOTE: This is value only selectable if
+  'connected_type' reports a value of "USB_PD_PPS"]
+
+What:  /sys/class/power_supply/tcpm-source-psy/voltage_min
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-only property describes the minimum voltage the source supply
+   can provide.
+
+   Value in microvolts.
+
+What:  /sys/class/power_supply/tcpm-source-psy/voltage_max
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-only property describes the maximum voltage the source supply
+   can provide.
+
+   Value in microvolts.
+
+What:  /sys/class/power_supply/tcpm-source-psy/voltage_now
+Date:  December 2017
+Contact:   Adam Thomson 
+Description:
+   This read-write property describes the voltage the source supply is
+   providing now. This property can only be written to if the source supply
+   is in online state '2' (PPS enabled), otherwise it's read-only
+   information.
+
+   Value in microvolts.
+
+What:  /sys/class/power_supply/tcpm-source-psy/current_max
+Date:  December 2017
+Contact:   Adam Thomson 

[PATCH v4 7/7] typec: tcpm: Add support for sink PPS related messages

2018-01-02 Thread Adam Thomson
This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported
handling of this message is also added. Sending of
Not_Supported is added is added to handle messages
received but not yet handled.

Signed-off-by: Adam Thomson 
---
 drivers/usb/typec/tcpm.c | 152 ---
 1 file changed, 143 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index b86a51c..54d17d7 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -113,6 +115,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+   S(GET_STATUS_SEND), \
+   S(GET_STATUS_SEND_TIMEOUT), \
+   S(GET_PPS_STATUS_SEND), \
+   S(GET_PPS_STATUS_SEND_TIMEOUT), \
+   \
S(ERROR_RECOVERY),  \
S(PORT_RESET),  \
S(PORT_RESET_WAIT_OFF)
@@ -143,6 +150,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+   PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
 };
@@ -1413,10 +1421,42 @@ static int tcpm_validate_caps(struct tcpm_port *port, 
const u32 *pdo,
 /*
  * PD (data, control) command handling functions
  */
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+   if (port->pwr_role == TYPEC_SOURCE)
+   return SRC_READY;
+   else
+   return SNK_READY;
+}
 
 static int tcpm_pd_send_control(struct tcpm_port *port,
enum pd_ctrl_msg_type type);
 
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,
+ int cnt)
+{
+   u32 p0 = le32_to_cpu(payload[0]);
+   unsigned int type = usb_pd_ado_type(p0);
+
+   if (!type) {
+   tcpm_log(port, "Alert message received with no type");
+   return;
+   }
+
+   /* Just handling non-battery alerts for now */
+   if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+   switch (port->state) {
+   case SRC_READY:
+   case SNK_READY:
+   tcpm_set_state(port, GET_STATUS_SEND, 0);
+   break;
+   default:
+   tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+   break;
+   }
+   }
+}
+
 static void tcpm_pd_data_request(struct tcpm_port *port,
 const struct pd_message *msg)
 {
@@ -1502,6 +1542,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+   case PD_DATA_ALERT:
+   tcpm_handle_alert(port, msg->payload, cnt);
+   break;
+   case PD_DATA_BATT_STATUS:
+   case PD_DATA_GET_COUNTRY_INFO:
+   /* Currently unsupported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1584,6 +1632,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+   case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1703,12 +1752,84 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+   case PD_CTRL_GET_SOURCE_CAP_EXT:
+   case PD_CTRL_GET_STATUS:
+   case PD_CTRL_FR_SWAP:
+   case PD_CTRL_GET_PPS_STATUS:
+   case PD_CTRL_GET_COUNTRY_CODES:
+   /* Currently not supported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
 }
 
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,
+   const struct pd_message *msg)
+{
+   enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+   unsigned int data_size = 
pd_ext_header_data_size_le(msg->ext_msg.header);
+   u8 *data;
+
+   if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+   tcpm_log(port, "Unchunked extended messages unsupported");
+   return;
+   }
+
+   if (data_size > 

Re: [PATCH 2/2] USB: serial: ark3116.c: Move TIOCGSERIAL ioctl case to function.

2018-01-02 Thread Johan Hovold
On Wed, Dec 13, 2017 at 04:45:06PM +0300, Mikhail Zaytsev wrote:
> The patch moves TIOCGSERIAL ioctl case to get_serial_info function.
> 
> Signed-off-by: Mikhail Zaytsev 
> ---
>  drivers/usb/serial/ark3116.c | 35 +--
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
> index 2e957c76f..2ce8fe10e 100644
> --- a/drivers/usb/serial/ark3116.c
> +++ b/drivers/usb/serial/ark3116.c
> @@ -36,6 +36,7 @@
>  #define DRIVER_DESC "USB ARK3116 serial/IrDA driver"
>  #define DRIVER_DEV_DESC "ARK3116 RS232/IrDA"
>  #define DRIVER_NAME "ark3116"
> +#define ARK3116_BAUDRATE 460800

I thought you and Oliver agreed this wasn't needed (wanted). Just
hard-code this number in the new helper as before.

>  /* usb timeout of 1 second */
>  #define ARK_TIMEOUT 1000
> @@ -397,27 +398,33 @@ static int ark3116_open(struct tty_struct *tty, struct 
> usb_serial_port *port)
>   return result;
>  }
>  
> +static int ark3116_get_serial_info(struct usb_serial_port *port,
> + unsigned long arg)

Keep the (void __user *) cast in ark3116_ioctl below and pass a struct
serial_struct __user pointer here.

> +{
> + struct serial_struct ser;
> +
> + memset(, 0, sizeof(ser));
> +
> + ser.type = PORT_16654;
> + ser.line = port->minor;
> + ser.port = port->port_number;
> + ser.custom_divisor = 0;

Might as well drop this redundant assignment as well.

> + ser.baud_base = ARK3116_BAUDRATE;
> +
> + if (copy_to_user((void __user *)arg, , sizeof(ser)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
>  static int ark3116_ioctl(struct tty_struct *tty,
>unsigned int cmd, unsigned long arg)
>  {
>   struct usb_serial_port *port = tty->driver_data;
> - struct serial_struct serstruct;
> - void __user *user_arg = (void __user *)arg;
>  
>   switch (cmd) {
>   case TIOCGSERIAL:
> - /* XXX: Some of these values are probably wrong. */
> - memset(, 0, sizeof(serstruct));
> - serstruct.type = PORT_16654;
> - serstruct.line = port->minor;
> - serstruct.port = port->port_number;
> - serstruct.custom_divisor = 0;
> - serstruct.baud_base = 460800;
> -
> - if (copy_to_user(user_arg, , sizeof(serstruct)))
> - return -EFAULT;
> -
> - return 0;
> + return ark3116_get_serial_info(port, arg);
>   default:
>   break;
>   }

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] USB: serial: ark3116.c: Remove unused TIOCSSERIAL ioctl case.

2018-01-02 Thread Johan Hovold
On Wed, Dec 13, 2017 at 04:44:55PM +0300, Mikhail Zaytsev wrote:
> The patch removes unused TIOCSSERIAL ioctl case and adds the default block 
> to the switch.
> 
> Signed-off-by: Mikhail Zaytsev 
> ---
>  drivers/usb/serial/ark3116.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
> index 23d46ef87..2e957c76f 100644
> --- a/drivers/usb/serial/ark3116.c
> +++ b/drivers/usb/serial/ark3116.c
> @@ -418,10 +418,8 @@ static int ark3116_ioctl(struct tty_struct *tty,
>   return -EFAULT;
>  
>   return 0;
> - case TIOCSSERIAL:
> - if (copy_from_user(, user_arg, sizeof(serstruct)))
> - return -EFAULT;
> - return 0;
> + default:
> + break;
>   }
>  
>   return -ENOIOCTLCMD;

This will make the ioctl return -ENOTTY to user space (e.g. setserial),
which I guess should be fine as TIOCSSERIAL really isn't supported for
these devices currently.

But you should at least mention this changed behaviour in the commit
message.

Please also drop the ".c" part from the subject prefix while at it.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] USB: usbip: remove useless call in usbip_recv

2018-01-02 Thread Gustavo A. R. Silva
Calling msg_data_left() is only useful for its return value,
which in this particular case is ignored.

Fix this by removing such call.

Addresses-Coverity-ID: 1427080
Fixes: 90120d15f4c3 ("usbip: prevent leaking socket pointer address in 
messages")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/usbip/usbip_common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index 7b219d9..b5af6fc 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -325,7 +325,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
usbip_dbg_xmit("enter\n");
 
do {
-   msg_data_left();
sock->sk->sk_allocation = GFP_NOIO;
 
result = sock_recvmsg(sock, , MSG_WAITALL);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] USB: host: Use zeroing memory allocator rather than allocator/memset

2018-01-02 Thread Mathias Nyman

On 30.12.2017 22:03, Himanshu Jha wrote:

Use dma_zalloc_coherent for allocating zeroed
memory and remove unnecessary memset function.

Done using Coccinelle.
Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
0-day tested with no failures.

Suggested-by: Luis R. Rodriguez 
Signed-off-by: Himanshu Jha 
---
v2:
-align argumenst as they were before applying the SmPL rule.

  drivers/usb/host/uhci-hcd.c | 7 +++
  drivers/usb/host/xhci-mem.c | 7 ++-
  2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index f5c9021..ac53398 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -600,15 +600,14 @@ static int uhci_start(struct usb_hcd *hcd)
uhci->dentry = dentry;
  #endif
  
-	uhci->frame = dma_alloc_coherent(uhci_dev(uhci),

-   UHCI_NUMFRAMES * sizeof(*uhci->frame),
-   >frame_dma_handle, GFP_KERNEL);
+   uhci->frame = dma_zalloc_coherent(uhci_dev(uhci),
+   UHCI_NUMFRAMES * sizeof(*uhci->frame),
+   >frame_dma_handle, GFP_KERNEL);
if (!uhci->frame) {
dev_err(uhci_dev(uhci),
"unable to allocate consistent memory for frame 
list\n");
goto err_alloc_frame;
}
-   memset(uhci->frame, 0, UHCI_NUMFRAMES * sizeof(*uhci->frame));
  
  	uhci->frame_cpu = kcalloc(UHCI_NUMFRAMES, sizeof(*uhci->frame_cpu),

GFP_KERNEL);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 554a8a5..332420d 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1782,14 +1782,11 @@ int xhci_alloc_erst(struct xhci_hcd *xhci,
struct xhci_erst_entry *entry;
  
  	size = sizeof(struct xhci_erst_entry) * evt_ring->num_segs;

-   erst->entries = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
-  size,
-  >erst_dma_addr,
-  flags);
+   erst->entries = dma_zalloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
+   size, >erst_dma_addr, flags);
if (!erst->entries)
return -ENOMEM;
  
-	memset(erst->entries, 0, size);

erst->num_entries = evt_ring->num_segs;
  
  	seg = evt_ring->first_seg;


For the xhci part:
Acked-by: Mathias Nyman 



 


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

2018-01-02 Thread Kai Heng Feng


> On 21 Dec 2017, at 7:43 PM, Daniel Drake  wrote:
> 
> On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris  
> wrote:
>> 
>> On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote:
>>> This commit causes a regression on some QCA ROME chips. The USB device
>>> reset happens in btusb_open(), hence firmware loading gets interrupted.
>> 
>> Oh, did you really confirm that's the root of the problem? I was only
>> hypothesizing, with some informed observation and code review; but I
>> didn't fully convince myself. If so, that's interesting.
> 
> I have the same doubt. Can you explain how/why firmware uploading and
> btusb_open() overlap, and how this is avoided with your patch?

QCA ROME chip uploads its firmware inside btusb_open().

The behavior is like below:
- btusb_probe()
- btusb_open()
- btusb_suspend(), reset_resume gets set.
- btusb_open() again, hub resets the device, then the issue happens.

I didn’t dig really deep for the issue, I simply tried usb core quirks, it reset
the USB device before btusb_probe().

It might be that using the USB quirk only papers over the real issue.

> If they do overlap, is that not a bug in the stack that should be fixed 
> instead?
> If the fix belongs in btusb and this BTUSB_RESET_RESUME thing really
> is problematic, should it be totally removed instead?

I think so. That’s why I need some insight from the original patch author.

Kai-Heng

> 
> Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ

2018-01-02 Thread Johan Hovold
On Fri, Dec 29, 2017 at 09:54:25AM +, Diego Elio Pettenò wrote:
> Add IDs for the OneTouch Verio IQ that comes with an embedded
> USB-to-serial converter.
> 
> Signed-off-by: Diego Elio Pettenò 

Now applied.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Second Try, as you will not accept not text mails: 4.14.10-gentoo-r1 breaks cups functionality

2018-01-02 Thread Greg KH
text emails work great, it's html emails that do not :)

On Mon, Jan 01, 2018 at 11:12:24PM +0100, Roman Gruber wrote:
> I send you  my bug because kernel.org bugzilla pointed me here.
>  
> https://bugzilla.kernel.org/show_bug.cgi?id=198329[https://deref-gmx.net/mail/client/HSud2NXiEWY/dereferrer/?redirectUrl=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D198329]
>  
> which is the same as
>  
> https://bugs.gentoo.org/643024[https://deref-gmx.net/mail/client/TMVlGHzulI0/dereferrer/?redirectUrl=https%3A%2F%2Fbugs.gentoo.org%2F643024]
>  
> which is described in details by myself here: 
>  
> https://www.linuxquestions.org/questions/linux-software-2/cups-no-printer-found-root-login-not-accepted-the-second-time-4175620647/[https://deref-gmx.net/mail/client/XMcEcZQi51M/dereferrer/?redirectUrl=https%3A%2F%2Fwww.linuxquestions.org%2Fquestions%2Flinux-software-2%2Fcups-no-printer-found-root-login-not-accepted-the-second-time-4175620647%2F]
> 
>  
> Details can be asked please in personal messages in linuxquestion topic.
>  
> --
>  
> Summary kernel 4.14 breaks cups functionality in regards of USB
> Printer support on gentoo linux.
>  
> A test kernel with the same kernel config with antique 4.1.x kernel on
> gentoo, oldest stable available kernel on gentoo, as described on
> kernel.org bugzilla, yielded in instantly working printer. But broken
> wifi which seems to be more a changed symbol of the wifi module over
> the kernel branches.
> Root cause faulty kernel usb stack, as the only component exchanged
> was the kernel to get it going.
>  
> a test installation of newst linux mint, on a very old notebook MSI
> Cr-700, + providing unzipped ppd file for my business printer
> instantly made it working. linux mint uses outdated old software of
> course. the old cups version is not in the gentoo portrage tree
> anymore. kernel 4.10 afaik is also dated.
>  
> Workaround now, bootup antique 4.1.x kernels to print something.
> kernel 4.1.x is not an option as i need those ext4 patches which were
> later introduced.  Use another notebook with fresh linux mint, but
> outdated software packages and outdated kernel.

This is odd, in that for printers, USB is just a "pass-through" pipe to
the hardware, the kernel should not be an issue here.

What are the kernel log messages you get when you plug in the printer on
the newer kernel version?  Does it give you any clue as to things going
wrong?  Can you post them here please?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] USB: cp2101 Add new device ID ELV ALC 8xxx

2018-01-02 Thread Johan Hovold
On Wed, Dec 27, 2017 at 10:13:23PM +0100, Christian Holl wrote:
> From: Christian Holl 
> Date: Wed, 27 Dec 2017 21:39:04 +0100
> Subject: [PATCH] USB: cp210x Add new device ID ELV ALC 8xxx
> 
> This adds the ELV ALC 8xxx Battery Charging device
> to the list of USB IDs of drivers/usb/serial/cp210x.c
> 
> Signed-off-by: Christian Holl 

Thanks for the patch. Unfortunately it has been corrupted by your
mailer, with tabs replaced by spaces, and does not apply.

Try sending the patch to yourself first and make sure you can apply it
with git am. git-send-email (and git-format-patch) can be very handy.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V1 3/4] usb: serial: f81534: add output pin control

2018-01-02 Thread Johan Hovold
On Tue, Jan 02, 2018 at 11:24:26AM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Johan,
> 
> >> In this code, I'm only read/write 3 registers of 0x2ae8, 0x2a90, 0x2a80,
> >> but some register will read/write more than once. Should I change the
> >> code from port_probe() to attach() and re-write it as:
> >>1: read the 3 register
> >>2: change them will 12 pin desire value
> >>3: write it back
> >> Is it ok?
> > 
> > Do you expect these pins to ever be changed after probe? If not, then
> > perhaps it can be moved to attach(), but otherwise I guess they should
> > be set at port_probe(). By using shadow registers, you should be able to
> > reduce the number of device accesses, but perhaps it's not worth the
> > complexity.
> > 
> > Do you have a rough idea about how long these register updates take? I
> > was just worried that these changes will add up to really long probe
> > times.
> > 
> 
> I had measured the time of the loop in f81534_set_port_output_pin() via
> getnstimeofday() with 685.410 ~ 3681.682us per port, but normally with
> 600~800us per port. So I prefer remain the current method of
> f81534_set_port_output_pin(). Is it ok?

That should be fine. Thanks for verifying.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html