Re: random insta-reboots on AMD Phenom II

[Adam Borowski]

On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote:
> On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote:
> > Any hints how to debug this?
> 
> Do
> rdmsr -a 0xc0010015
> as root and paste it here.

110
110
110
110
110
110

on both 4.13.4 and 4.14-rc2+.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

random insta-reboots on AMD Phenom II

[Adam Borowski]

Hi!
I'm afraid I see random instant reboots on current -rc, approximately
once per day, only under CPU load.  There's nothing on serial/etc -- just
an immediate reboot.  4.13 works perfectly; last kernel I've tried is
v4.14-rc2-165-g770b782f555d.  gcc 7.2.0-7 (Debian).

CPU is AMD Phenom II X6 1055T (family 10h).

Sometimes it dies within a few minutes of load, sometimes all is fine for a
couple of days.  This randomness makes bisecting not really an option.

Any hints how to debug this?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Re: random insta-reboots on AMD Phenom II

[Adam Borowski]

On Sat, Sep 30, 2017 at 01:53:02PM +0200, Borislav Petkov wrote:
> On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote:
> > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote:
> > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote:

> Boot into -rc2+ and do as root:
> 
> # wrmsr -a 0xc0010015 0x118

Seems to help, thus it's indeed this issue.  I failed to mention that "once
per day" meant a day of regular use, of which heavy loads were only a tiny
fraction.  I've applied this register setting, then kept the machine busy
(mostly with randconfig kernel builds) for a day, no explosions yet -- so
there's a good chance the problem would have triggered.

> If the issue gets fixed then Mr. Luto better revert the new lazy TLB
> flushing fun'n'games for 4.14 before it is too late and that kernel
> releases b0rked.

I have no clue about these matters so I'll leave it to you guys.  But, as
the other report I see gives different effects (frequent segfaults vs rare
insta-reboots), you do want to include my machine in testing.

Thanks for the workaround!

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

[Adam Borowski]

On Tue, Oct 03, 2017 at 12:40:12PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote:
> > That essay is full of shit, and you've even mentioned parts of that just 
> > above...
> > NAK; you'd _still_ need proper quoting (or a shell with something 
> > resembling an
> > actual syntax, rather than the "more or less what srb had ended up 
> > implementing"),
> > so it doesn't really buy you anything.  Badly written script will still be
> > exploitable.  And since older kernels and other Unices are not going away,
> > you would've created an inconsistently vulnerable set of scripts, on top of
> > the false sense of security.
> 
> Banning certain characters is certainly not a panacea, and there are a
> lot of best practices that you have to follow when writing good
> scripts which most people don't follow, and so it's arguable that
> benefits are being overstated.

Yeah, it's "most people don't follow" which is the main issue here.  And
it appears to me that it's easy to plug the worst issues, especially \n.

> That being said the costs of suppressing certain bytes from appearing
> in pathnames seem fairly low.

There are three categories of problematic bytes/byte sequences:
* those that don't appear in the wild, require a bit of knowledge to input
  (inserting a control char is no rocket science but is beyond an average
  user's skill), and also have potential to cause damage
  - This is why I picked 1-31,127 in the initial patch.
* stuff that's unwanted but not unknown in the wild
* stuff that's used by every "normal" user, and considered problematic only
  by us traditional Unix folks

> Would this be more palatable if the ban on control characters were made
> into a compile-time or mount-time option?

For malformed Unicode or such, it'd make sense, yeah.

But Al has a good point that if most people were protected, they won't
bother escaping badness anymore -- leaving those whose systems allow control
chars vulnerable if they run a script that doesn't do quoting.

Thus, it'd be good to make at least worst cases non-configurable.

I went bold and submitted 1-31,127, as those have very low cost to block;
but if that's not conservative enough, blocking just \n has both very low
cost and a high benefit (special burdensome quoting required).

Discussing a configurable policy (perhaps here in vfs, perhaps as a LSM, a
seccomp hack or even LD_PRELOAD) would be interesting, but for the above
reason I'd want \n hard-banned.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Re: kvm splat in mmu_spte_clear_track_bits

[Adam Borowski]

On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote:
> 2017-08-21 21:12+0200, Adam Borowski:
> > On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote:
> > > 2017-08-21 7:13 GMT+08:00 Adam Borowski <kilob...@angband.pl>:
> > > > I'm afraid I keep getting a quite reliable, but random, splat when 
> > > > running
> > > > KVM:
> > > 
> > > I reported something similar before. https://lkml.org/lkml/2017/6/29/64
> > 
> > Your problem seems to require OOM; I don't have any memory pressure at all:
> > running a single 2GB guest while there's nothing big on the host (bloatfox,
> > xfce, xorg, terminals + some minor junk); 8GB + (untouched) swap.  There's
> > no memory pressure inside the guest either -- none was Linux (I wanted to
> > test something on hurd, kfreebsd) and I doubt they even got to use all of
> > their frames.
> 
> I even tried hurd, but couldn't reproduce ...

Also happens with a win10 guest, and with multiple Linuxes.

> what is your qemu command
> line and the output of host's `grep . /sys/module/kvm*/parameters/*`?

qemu-system-x86_64 -enable-kvm -m 2048 -vga qxl -usbdevice tablet \
 -net bridge -net nic \
 -drive file="$DISK",cache=writeback,index=0,media=disk,discard=on

qemu-system-x86_64 -enable-kvm -m 2048 -vga qxl -usbdevice tablet \
 -net bridge -net nic \
 -drive 
file="$DISK",cache=unsafe,index=0,media=disk,discard=on,if=virtio,format=raw

/sys/module/kvm/parameters/halt_poll_ns:20
/sys/module/kvm/parameters/halt_poll_ns_grow:2
/sys/module/kvm/parameters/halt_poll_ns_shrink:0
/sys/module/kvm/parameters/ignore_msrs:N
/sys/module/kvm/parameters/kvmclock_periodic_sync:Y
/sys/module/kvm/parameters/lapic_timer_advance_ns:0
/sys/module/kvm/parameters/min_timer_period_us:500
/sys/module/kvm/parameters/tsc_tolerance_ppm:250
/sys/module/kvm/parameters/vector_hashing:Y
/sys/module/kvm_amd/parameters/avic:0
/sys/module/kvm_amd/parameters/nested:1
/sys/module/kvm_amd/parameters/npt:1
/sys/module/kvm_amd/parameters/vls:0

> > Also, it doesn't reproduce for me on 4.12.
> 
> Great info ... the most suspicious between v4.12 and v4.13-rc5 is the
> series with dcdca5fed5f6 ("x86: kvm: mmu: make spte mmio mask more
> explicit"), does reverting it help?
> 
> `git revert 
> ce00053b1cfca312c22e2a6465451f1862561eab~1..995f00a619584e65e53eff372d9b73b121a7bad5`

Alas, doesn't seem to help.

I've first installed a Debian stretch guest, the host survived both the
installation and subsequent fooling around.  But then I started a win10
guest which splatted as soon as the initial screen.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 

Re: [PATCH] zram: add zstd to the supported algorithms list

[Adam Borowski]

On Fri, Aug 25, 2017 at 04:45:33PM +0900, Sergey Senozhatsky wrote:
> that may lead to a bigger/more general question:
> 
> - if zstd is so much better, then do we need deflate/inflate at all in
>   the kernel? may be zstd can replace it?

zram and vmlinuz/modules are about the only cases that can be replaced. 
Everything else is long-lived data (filesystems) or comes from the outside
(network protocols).  There are also some cases where we have some control
over the producer (initramfstools) but even there you'd need many years of
deprecation.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: kvm splat in mmu_spte_clear_track_bits

[Adam Borowski]

On Fri, Aug 25, 2017 at 03:40:50PM +0200, Paolo Bonzini wrote:
> On 25/08/2017 15:14, Adam Borowski wrote:
> >>> I would also try commit 1372324b328cd5dabaef5e345e37ad48c63df2a9 to
> >>> identify whether it was caused by a KVM change in 4.13 or something
> >>> else.
> > I've ran different guests for a couple of hours, no explosions.  Thus it
> > looks like updating Cornelia's email address isn't the cause.
> > 
> > Too bad, there's 15k commits between 1372324b and 7f680d7ec315.
> 
> So:
> 
> - 4.12 works
> 
> - 1372324b328cd5dabaef5e345e37ad48c63df2a9 works
> 
> - 4.13-rc6 fails
> 
> The next ones to test are going to be
> c136b84393d4e340e1b53fc7f737dd5827b19ee5 and 4.13-rc1.

c136b84393d4e340e1b53fc7f737dd5827b19ee5 works

4.13-rc1 works
Which actually isn't so surprising, as I pull from linus/master every Sunday
night/Monday morning, so I'd would have noticed KVM breakage sooner.

4.13-rc4 works

4.13-rc5 works (but ↓)

v4.13-rc5-173-g58d4e450a490 works... uh oh.
It shouldn't -- it's merge-base between mainline and what I was running on
the initial crash, and I'm sure anything non-mainline I had isn't the
culprit.  After a couple of hours of running various loads inside and
outside KVM, I finally got it to crash.

4.13-rc5 retested fails
Crashed only after two hours or so of testing.

4.13-rc4 apparently works
It survived several hours of varied tests (like 5 debian-installer runs, a
win10 point release upgrade, some hurd package building, openbsd, etc),
all while the host was likewise busy.


Thus: to the best of my knowledge, the problem is between 4.13-rc4 and 4.13-rc5
but I wouldn't bet my life on it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: 4.13-rc7: WARNING at arch/x86/kvm/mmu.c:717 (and a crash thereafter)

[Adam Borowski]

On Mon, Aug 28, 2017 at 02:26:06PM +0200, Takashi Iwai wrote:
> I seem to get a kernel warning when running KVM on Dell desktop with
> IvyBridge like below.  As you can see, a bad page BUG is triggered
> after that, too.  The problem is not triggered always, but it happens
> occasionally.

See the thread starting with 20170820231302.s732zclznrqxw...@angband.pl

> I haven't seen this on 4.13-rc4 at all, and IIRC, it started happening
> since rc5.  So this might be a regression at rc5.  But, as it doesn't
> happen always, I can't be 100% sure about it, and it's quite difficult
> to bisect (the test case isn't reliable), unfortunately.

Same here -- it sometimes takes a few hours of trying to reproduce, which
makes proving the negative greatly unpleasant.

And all I've been able to tell so far is that the problem is between
4.13-rc4 and 4.13-rc5, just like you say.

> ===
> 
>  WARNING: CPU: 2 PID: 7188 at arch/x86/kvm/mmu.c:717 
> mmu_spte_clear_track_bits+0xe7/0x100 [kvm]
>  CPU: 2 PID: 7188 Comm: qemu-system-x86 Not tainted 4.13.0-rc7-test+ #26
>  Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
>  task: 997fdc1320c0 task.stack: b9394cf7
>  RIP: 0010:mmu_spte_clear_track_bits+0xe7/0x100 [kvm]
>  RSP: 0018:b9394cf73ab8 EFLAGS: 00010246
>  RAX:  RBX: 40010552cc77 RCX: dead00ff
>  RDX:  RSI: 997f53659108 RDI: e7c684154b00
>  RBP: b9394cf73ad0 R08: 0100 R09: 000c
>  R10: 997fc2ba0008 R11: 997fc2ba R12: 0010552c
>  R13: 997edd0f R14: 997f69c44348 R15: 
>  FS:  () GS:9980de28() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 7ffd57a77ff8 CR3: 000105704000 CR4: 001426e0
>  Call Trace:
>   drop_spte+0x1a/0xb0 [kvm]
>   mmu_page_zap_pte+0x9d/0xe0 [kvm]
>   kvm_mmu_prepare_zap_page+0x56/0x300 [kvm]
>   kvm_mmu_invalidate_zap_all_pages+0x10d/0x160 [kvm]
>   kvm_arch_flush_shadow_all+0xe/0x10 [kvm]
>   kvm_mmu_notifier_release+0x2c/0x40 [kvm]
>   __mmu_notifier_release+0x44/0xc0
>   exit_mmap+0x11e/0x130
>   ? __switch_to+0x216/0x3f0
>   ? __khugepaged_exit+0x114/0x120
>   mmput+0x46/0x120
>   do_exit+0x277/0xb10
>   ? preempt_schedule_common+0x1f/0x30
>   ? preempt_schedule+0x27/0x30
>   ? ___preempt_schedule+0x16/0x18
>   do_group_exit+0x43/0xb0
>   get_signal+0x260/0x600
>   ? get_futex_key+0x294/0x350
>   do_signal+0x28/0x710
>   ? recalc_sigpending+0x1b/0x50
>   exit_to_usermode_loop+0x6e/0xc0
>   syscall_return_slowpath+0x59/0x60
>   entry_SYSCALL_64_fastpath+0xa7/0xa9
>  RIP: 0033:0x7f95aab8f8ec
>  RSP: 002b:7f959c36c7e8 EFLAGS: 0246 ORIG_RAX: 00ca
>  RAX: fe00 RBX: 56156743b010 RCX: 7f95aab8f8ec
>  RDX: 0002 RSI: 0080 RDI: 56156626c080
>  RBP:  R08: 56156626c080 R09: 56156626c000
>  R10:  R11: 0246 R12: 000f
>  R13: 56156626c080 R14:  R15: 56156743b03c
>  Code: 4f 04 00 48 85 c0 75 1c 4c 89 e7 e8 54 4d fe ff 48 8b 05 9d 4f 04 00 
> 48 85 c0 74 c1 48 85 c3 0f 95 c3 eb bf 48 85 c3 74 e7 eb dd <0f> ff eb 9e 4c 
> 89 e7 e8 2d 4d fe ff eb a4 90 66 2e 0f 1f 84 00 
>  ---[ end trace dd04b99ed8787467 ]---

The first WARN is always the above.  But the rest seems to be totally random
-- a nasty case of fandango on core whose results range from harmless
through crash to massive data loss (just guess what would happen if some
idiot picked balancing the disk as a test load -- no one would be that
stupid, right?  At least an incomplete idiot has checksums and backups).

>  BUG: Bad page state in process python  pfn:10552c
>  page:e7c684154b00 count:0 mapcount:0 mapping:  (null) index:0x1
>  flags: 0x280014(referenced|dirty)
>  raw: 00280014  0001 
>  raw: dead0100 dead0200  
>  page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
>  bad because of flags: 0x14(referenced|dirty)
>  CPU: 7 PID: 9171 Comm: python Tainted: GW   4.13.0-rc7-test+ #26
>  Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
>  Call Trace:
>   dump_stack+0x63/0x8d
>   bad_page+0xcb/0x120
>   check_new_page_bad+0x67/0x80
>   get_page_from_freelist+0x9d1/0xb00
>   __alloc_pages_nodemask+0xce/0x230
>   alloc_pages_vma+0x88/0x1f0
>   __handle_mm_fault+0x7c9/0x1000
>   handle_mm_fault+0xde/0x1e0
>   __do_page_fault+0x23b/0x4f0
>   do_page_fault+0x22/0x30
>   page_fault+0x28/0x30
>  RIP: 0033:0x7f4a2761c2c3
>  RSP: 002b:7fffbe1b2988 EFLAGS: 00010206
>  RAX: 557a87b725b0 RBX: 00e8 RCX: 557a87b75000
>  RDX: 557a87b78a00 RSI: 00ba RDI: 557a87b725b0
>  RBP: 7f4a279362a8 R08: 0003 R09: 007c
>  R10: 01c1 R11: 0077 R12: 

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

[Adam Wallis]

On 8/28/2017 9:05 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Adam Wallis <awal...@codeaurora.org> writes:
>> The dma ops from the parent DWC device are not getting passed to the
>> child xhci-hcd device. This patch makes use of
>> platform_device_register_full to set the DMA ops. For the DT/OF case,
>> dma_ops were still null after the the device register, so
>> of_dma_configure is called in only the OF case.
>>
>> Signed-off-by: Adam Wallis <awal...@codeaurora.org>
> 
> you need to sysdev property, IMO.
> 
Thanks, good suggestion. I will test that out.

-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

[Adam Wallis]

On 8/25/2017 7:03 PM, Grygorii Strashko wrote:
> 
> 
> On 08/25/2017 01:02 PM, Adam Wallis wrote:
>> The dma ops from the parent DWC device are not getting passed to the
>> child xhci-hcd device. This patch makes use of
>> platform_device_register_full to set the DMA ops. For the DT/OF case,
>> dma_ops were still null after the the device register, so
>> of_dma_configure is called in only the OF case.
>>
>> Signed-off-by: Adam Wallis <awal...@codeaurora.org>
> 
> Hm. There were set of fixes in this area recently which actually removed
> settings you are going to restore

The set of fixes works for DWC if it is a child device, but in my testing, those
DMA settings do not get propagated to the created xHCI-hcd child device (which
is instantiated in dwc3_host_init). I see the same behavior with ACPI and
Device-Tree/OF boot.

> 
> 4c39d4b usb: xhci: use bus->sysdev for DMA configuration
> 
> d64ff40 usb: dwc3: use bus->sysdev for DMA configuration
> 
>> ---
>>   drivers/usb/dwc3/host.c | 39 +--
>>   1 file changed, 17 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>> index 76f0b0d..662e9e2 100644
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -16,6 +16,7 @@
>>    */
>>     #include 
>> +#include 
>>     #include "core.h"
>>   @@ -56,6 +57,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   {
>>   struct property_entry    props[3];
>>   struct platform_device    *xhci;
>> +    struct platform_device_info dwc_plat_info = {};
>>   int    ret, irq;
>>   struct resource    *res;
>>   struct platform_device    *dwc3_pdev = to_platform_device(dwc->dev);
>> @@ -79,22 +81,22 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   dwc->xhci_resources[1].flags = res->flags;
>>   dwc->xhci_resources[1].name = res->name;
>>   -    xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
>> -    if (!xhci) {
>> -    dev_err(dwc->dev, "couldn't allocate xHCI device\n");
>> -    return -ENOMEM;
>> -    }
>> +    dwc_plat_info.name = "xhci-hcd";
>> +    dwc_plat_info.parent = dwc->dev;
>> +    dwc_plat_info.res = dwc->xhci_resources;
>> +    dwc_plat_info.num_res = DWC3_XHCI_RESOURCES_NUM;
>> +    dwc_plat_info.fwnode = dwc->dev->fwnode;
>> +    dwc_plat_info.dma_mask = *dwc->dev->dma_mask;
>>   -    xhci->dev.parent    = dwc->dev;
>> +    xhci = platform_device_register_full(_plat_info);
>> +    if (IS_ERR(xhci)) {
>> +    dev_err(dwc->dev, "failed to register xHCI device\n");
>> +    return PTR_ERR(xhci);
>> +    }
>>     dwc->xhci = xhci;
>> -
>> -    ret = platform_device_add_resources(xhci, dwc->xhci_resources,
>> -    DWC3_XHCI_RESOURCES_NUM);
>> -    if (ret) {
>> -    dev_err(dwc->dev, "couldn't add resources to xHCI device\n");
>> -    goto err1;
>> -    }
>> +    if (dwc->dev->of_node)
>> +    of_dma_configure(>dev, dwc->dev->of_node);
>>     memset(props, 0, sizeof(struct property_entry) * ARRAY_SIZE(props));
>>   @@ -117,7 +119,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   ret = platform_device_add_properties(xhci, props);
>>   if (ret) {
>>   dev_err(dwc->dev, "failed to add properties to xHCI\n");
>> -    goto err1;
>> +    goto err;
>>   }
>>   }
>>   @@ -126,19 +128,12 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   phy_create_lookup(dwc->usb3_generic_phy, "usb3-phy",
>>     dev_name(dwc->dev));
>>   -    ret = platform_device_add(xhci);
>> -    if (ret) {
>> -    dev_err(dwc->dev, "failed to register xHCI device\n");
>> -    goto err2;
>> -    }
>> -
>>   return 0;
>> -err2:
>> +err:
>>   phy_remove_lookup(dwc->usb2_generic_phy, "usb2-phy",
>>     dev_name(dwc->dev));
>>   phy_remove_lookup(dwc->usb3_generic_phy, "usb3-phy",
>>     dev_name(dwc->dev));
>> -err1:
>>   platform_device_put(xhci);
>>   return ret;
>>   }
>>
> 


-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: kvm splat in mmu_spte_clear_track_bits

[Adam Borowski]

On Thu, Aug 24, 2017 at 03:43:55PM +0800, Wanpeng Li wrote:
> 2017-08-23 20:22 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> > On 22/08/2017 00:32, Adam Borowski wrote:
> >> On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote:
> >>> 2017-08-21 21:12+0200, Adam Borowski:
> >>>> Also, it doesn't reproduce for me on 4.12.
> >>>
> >>> Great info ... the most suspicious between v4.12 and v4.13-rc5 is the
> >>> series with dcdca5fed5f6 ("x86: kvm: mmu: make spte mmio mask more
> >>> explicit"), does reverting it help?
> >>>
> >>> `git revert 
> >>> ce00053b1cfca312c22e2a6465451f1862561eab~1..995f00a619584e65e53eff372d9b73b121a7bad5`
> >>
> >> Alas, doesn't seem to help.
> >>
> >> I've first installed a Debian stretch guest, the host survived both the
> >> installation and subsequent fooling around.  But then I started a win10
> >> guest which splatted as soon as the initial screen.
> >
> > Can you check if disabling THP on the host also fixes it for you?

As in: ?
echo never >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/defrag
Still reproduces, with or without reverting
ce00053b1cfca312c22e2a6465451f1862561eab~1..995f00a619584e65e53eff372d9b73b121a7bad5

> > I would also try commit 1372324b328cd5dabaef5e345e37ad48c63df2a9 to
> > identify whether it was caused by a KVM change in 4.13 or something
> > else.

I've ran different guests for a couple of hours, no explosions.  Thus it
looks like updating Cornelia's email address isn't the cause.

Too bad, there's 15k commits between 1372324b and 7f680d7ec315.

> For the OOM testcase, the splat will disappear if disabling THP.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

[PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

[Adam Wallis]

The dma ops from the parent DWC device are not getting passed to the
child xhci-hcd device. This patch makes use of
platform_device_register_full to set the DMA ops. For the DT/OF case,
dma_ops were still null after the the device register, so
of_dma_configure is called in only the OF case.

Signed-off-by: Adam Wallis <awal...@codeaurora.org>
---
 drivers/usb/dwc3/host.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 76f0b0d..662e9e2 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
@@ -56,6 +57,7 @@ int dwc3_host_init(struct dwc3 *dwc)
 {
struct property_entry   props[3];
struct platform_device  *xhci;
+   struct platform_device_info dwc_plat_info = {};
int ret, irq;
struct resource *res;
struct platform_device  *dwc3_pdev = to_platform_device(dwc->dev);
@@ -79,22 +81,22 @@ int dwc3_host_init(struct dwc3 *dwc)
dwc->xhci_resources[1].flags = res->flags;
dwc->xhci_resources[1].name = res->name;
 
-   xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
-   if (!xhci) {
-   dev_err(dwc->dev, "couldn't allocate xHCI device\n");
-   return -ENOMEM;
-   }
+   dwc_plat_info.name = "xhci-hcd";
+   dwc_plat_info.parent = dwc->dev;
+   dwc_plat_info.res = dwc->xhci_resources;
+   dwc_plat_info.num_res = DWC3_XHCI_RESOURCES_NUM;
+   dwc_plat_info.fwnode = dwc->dev->fwnode;
+   dwc_plat_info.dma_mask = *dwc->dev->dma_mask;
 
-   xhci->dev.parent= dwc->dev;
+   xhci = platform_device_register_full(_plat_info);
+   if (IS_ERR(xhci)) {
+   dev_err(dwc->dev, "failed to register xHCI device\n");
+   return PTR_ERR(xhci);
+   }
 
dwc->xhci = xhci;
-
-   ret = platform_device_add_resources(xhci, dwc->xhci_resources,
-   DWC3_XHCI_RESOURCES_NUM);
-   if (ret) {
-   dev_err(dwc->dev, "couldn't add resources to xHCI device\n");
-   goto err1;
-   }
+   if (dwc->dev->of_node)
+   of_dma_configure(>dev, dwc->dev->of_node);
 
memset(props, 0, sizeof(struct property_entry) * ARRAY_SIZE(props));
 
@@ -117,7 +119,7 @@ int dwc3_host_init(struct dwc3 *dwc)
ret = platform_device_add_properties(xhci, props);
if (ret) {
dev_err(dwc->dev, "failed to add properties to xHCI\n");
-   goto err1;
+   goto err;
}
}
 
@@ -126,19 +128,12 @@ int dwc3_host_init(struct dwc3 *dwc)
phy_create_lookup(dwc->usb3_generic_phy, "usb3-phy",
  dev_name(dwc->dev));
 
-   ret = platform_device_add(xhci);
-   if (ret) {
-   dev_err(dwc->dev, "failed to register xHCI device\n");
-   goto err2;
-   }
-
return 0;
-err2:
+err:
phy_remove_lookup(dwc->usb2_generic_phy, "usb2-phy",
  dev_name(dwc->dev));
phy_remove_lookup(dwc->usb3_generic_phy, "usb3-phy",
  dev_name(dwc->dev));
-err1:
platform_device_put(xhci);
return ret;
 }
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: kvm splat in mmu_spte_clear_track_bits

[Adam Borowski]

On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote:
> 2017-08-21 7:13 GMT+08:00 Adam Borowski <kilob...@angband.pl>:
> > Hi!
> > I'm afraid I keep getting a quite reliable, but random, splat when running
> > KVM:
> 
> I reported something similar before. https://lkml.org/lkml/2017/6/29/64

Your problem seems to require OOM; I don't have any memory pressure at all:
running a single 2GB guest while there's nothing big on the host (bloatfox,
xfce, xorg, terminals + some minor junk); 8GB + (untouched) swap.  There's
no memory pressure inside the guest either -- none was Linux (I wanted to
test something on hurd, kfreebsd) and I doubt they even got to use all of
their frames.

Also, it doesn't reproduce for me on 4.12.

> > [ cut here ]
> > WARNING: CPU: 5 PID: 5826 at arch/x86/kvm/mmu.c:717 
> > mmu_spte_clear_track_bits+0x123/0x170
> > Modules linked in: tun nbd arc4 rtl8xxxu mac80211 cfg80211 rfkill nouveau 
> > video ttm
> > CPU: 5 PID: 5826 Comm: qemu-system-x86 Not tainted 
> > 4.13.0-rc5-vanilla-ubsan-00211-g7f680d7ec315 #1
> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
> > 05/18/2011
> > task: 880207ef0400 task.stack: c900035e4000
> > RIP: 0010:mmu_spte_clear_track_bits+0x123/0x170
> > RSP: 0018:c900035e7ab0 EFLAGS: 00010246
> > RAX:  RBX: 00010501cc67 RCX: 0001
> > RDX: dead00ff RSI: 88020e501df8 RDI: 04140700
> > RBP: c900035e7ad8 R08: 0100 R09: 0003
> > R10: 0003 R11: 0005 R12: 0010501c
> > R13: ea0004140700 R14: 88020e1d R15: 
> > FS:  7f0213fbd700() GS:88022fd4() knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2:  CR3: 00022187f000 CR4: 06e0
> > Call Trace:
> >  drop_spte+0x26/0x130
> >  mmu_page_zap_pte+0xc4/0x160
> >  kvm_mmu_prepare_zap_page+0x65/0x660
> >  kvm_mmu_invalidate_zap_all_pages+0xc5/0x1f0
> >  kvm_mmu_invalidate_zap_pages_in_memslot+0x9/0x10
> >  kvm_page_track_flush_slot+0x86/0xd0
> >  kvm_arch_flush_shadow_memslot+0x9/0x10
> >  __kvm_set_memory_region+0x8fb/0x14f0
> >  kvm_set_memory_region+0x2f/0x50
> >  kvm_vm_ioctl+0x559/0xcc0
> >  ? kvm_vcpu_ioctl+0x171/0x620
> >  ? __switch_to+0x30b/0x740
> >  do_vfs_ioctl+0xbb/0x8d0
> >  ? find_vma+0x23/0x100
> >  ? __fget_light+0x94/0x110
> >  SyS_ioctl+0x86/0xa0
> >  entry_SYSCALL_64_fastpath+0x17/0x98
> > RIP: 0033:0x7f021c80ddc7
> > RSP: 002b:7f0213fbc518 EFLAGS: 0246 ORIG_RAX: 0010
> > RAX: ffda RBX:  RCX: 7f021c80ddc7
> > RDX: 7f0213fbc5b0 RSI: 4020ae46 RDI: 000a
> > RBP:  R08: 7f020c1698a0 R09: 
> > R10: 7f020c1698a0 R11: 0246 R12: 0006
> > R13: 7f022201c000 R14: 0002 R15: 558c3899e550
> > Code: ae fc 01 48 85 c0 75 1c 4c 89 e7 e8 98 de fd ff 48 8b 05 81 ae fc 01 
> > 48 85 c0 74 ba 48 85 c3 0f 95 c3 eb b8 48 85 c3 74 e7 eb dd <0f> ff eb 97 
> > 4c 89 e7 66 0f 1f 44 00 00 e8 6b de fd ff eb 97 31
> > ---[ end trace 16c196134f0dd0a9 ]---
> >
> > After this, there are hundreds of repeats and lots of secondary damage which
> > kills the host quickly.
> >
> > Usually this happens within a few minutes, but sometimes it takes ~half an
> > hour to reproduce.  Because of this, it'd be unpleasant to bisect -- is this
> > problem already known?

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 

[PATCH] ARM: dts: da850-evm: add chosen and SPI alias

[Adam Ford]

At the request of Sekhar Nori from TI, this is a follow-up to
pending ("ARM: dts: da850-evm: add serial and ethernet aliases")

This patch will add the chosen container to point stdout-path to serial2
and set the alias for spi0 to spi1 since the SPI NOR flash exists on SPI1.

Signed-off-by: Adam Ford <aford...@gmail.com>

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c755079..3962fa4 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -15,11 +15,16 @@
compatible = "ti,da850-evm", "ti,da850";
model = "DA850/AM1808/OMAP-L138 EVM";
 
+   chosen {
+   stdout-path = 
+   };
+
aliases {
serial0 = 
serial1 = 
serial2 = 
ethernet0 = 
+   spi0 = 
};
 
soc@1c0 {
-- 
2.7.4

Re: kvm splat in mmu_spte_clear_track_bits

[Adam Borowski]

On Tue, Aug 29, 2017 at 02:45:41PM +0200, Takashi Iwai wrote:
> [Put more people to Cc, sorry for growing too much...]

We're all interested in 4.13.0 not crashing on us, so that's ok.

> On Tue, 29 Aug 2017 11:19:13 +0200,
> Bernhard Held wrote:
> > 
> > On 08/28/2017 at 06:56 PM, Nadav Amit wrote:
> > > Don’t blame me for the TLB stuff... My money is on aac2fea94f7a .
> > 
> > Amit, thanks for your courage to expose your patch!
> > 
> > I'm more and more confident that aac2fea94f7a is the culprit.  Maybe it
> > just accelerates the triggering of the splash.  To be more sure the
> > kernel needs to be tested for a couple of days.  It would be great if
> > others could assist in testing aac2fea94f7a.
> 
> I'm testing with the revert for a while and it seems working.

With nothing but aac2fea94f7a reverted, no explosions for me either.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

[Adam Borowski]

On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote:
> I will wait for people to test and for result of my own test before
> reposting if need be, otherwise i will post as separate patch.
>
> > But from a _very_ quick read-through this looks fine. But it obviously
> > needs testing.
> > 
> > People - *especially* the people who saw issues under KVM - can you
> > try out Jérôme's patch-series? I aded some people to the cc, the full
> > series is on lkml. Jérôme - do you have a git branch for people to
> > test that they could easily pull and try out?
> 
> https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch
> git://people.freedesktop.org/~glisse/linux

Tested your branch as of 10f07641, on a long list of guest VMs.
No earth-shattering kaboom.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: [PATCH 4.13 077/160] usb: host: xhci-plat: allow sysdev to inherit from ACPI

[Adam Wallis]

On 10/11/2017 7:53 AM, Greg Kroah-Hartman wrote:
> On Wed, Oct 11, 2017 at 11:19:41AM +0700, Thang Q. Nguyen wrote:
>> Hi,
>>
>> On Wed, Oct 11, 2017 at 2:50 AM, Greg Kroah-Hartman 
>> <gre...@linuxfoundation.org
>>> wrote:
>>
>> 4.13-stable review patch.  If anyone has any objections, please let me
>>     know.
>>
>> --
>>
>> From: Adam Wallis <awal...@codeaurora.org>
>>
>> commit c6b8e79306f515b5483eb11076e0fbfc140434a8 upstream.
>>
>> Commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
>> updated the method determining DMA for XHCI from sysdev. However, this
>> patch broke the ability to enumerate the FWNODE from parent ACPI devices
>> from the child plat XHCI device.
>>
>> Currently, xhci_plat is not set up properly when the parent device is an
>> ACPI node. The conditions that xhci_plat_probe should satisfy are
>>
>> 1. xhci_plat comes from firmware
>> 2. xhci_plat is child of a device from firmware (dwc3-plat)
>> 3. xhci_plat is grandchild of a pci device (dwc3-pci)
>>
>> Case 2 is covered when the child is an OF node (by checking
>> sysdev->parent->of_node), however, an ACPI parent will return NULL in
>> the of_node check and will thus not result in sysdev being set to
>> sysdev->parent
>>
>> [   17.591549] xhci-hcd: probe of xhci-hcd.6.auto failed with error -5
>>
>> This change adds a check for ACPI to completely allow for condition 2.
>> This is done by first checking if the parent node is of type ACPI (e.g.,
>> dwc3-plat) and set sysdev to sysdev->parent if either of the two
>> following conditions are met:
>>
>> 1: If fwnode is empty (in the case that platform_device_add_properties
>> was not called on the allocated platform device)
>> 2: fwnode exists but is not of type ACPI (this would happen if
>> platform_device_add_properties was called on the allocated device.
>> Instead of type FWNODE_ACPI, you would end up with FWNODE_PDATA)
>>
>> Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
>> Tested-by: Thang Q. Nguyen <tqngu...@apm.com>
>> Signed-off-by: Adam Wallis <awal...@codeaurora.org>
>> Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>> ---
>>  drivers/usb/host/xhci-plat.c |   16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -186,14 +186,18 @@ static int xhci_plat_probe(struct platfo
>>          * 2. xhci_plat is child of a device from firmware (dwc3-plat)
>>          * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
>>          */
>> -       sysdev = >dev;
>> -       if (sysdev->parent && !sysdev->of_node && 
>> sysdev->parent->of_node)
>> -               sysdev = sysdev->parent;
>> +       for (sysdev = >dev; sysdev; sysdev = sysdev->parent) {
>> +               if (is_of_node(sysdev->fwnode) ||
>> +                       is_acpi_device_node(sysdev->fwnode))
>> +                       break;
>>  #ifdef CONFIG_PCI
>> -       else if (sysdev->parent && sysdev->parent->parent &&
>> -                sysdev->parent->parent->bus == _bus_type)
>> -               sysdev = sysdev->parent->parent;
>> +               else if (sysdev->bus == _bus_type)
>> +                       break;
>>  #endif
>> +       }
>> +
>> +       if (!sysdev)
>> +               sysdev = >dev;
>>
>>         /* Try to set 64-bit DMA first */
>>         if (WARN_ON(!sysdev->dma_mask))
>>
>>
>>
>> This patch and Sriram's patches below should come together:
>>
>> d64ff406e5("usb: dwc3: use bus->sysdev for DMA configuration")
>>
>> 8c9f2de459("usb: dwc3: Do not set dma coherent mask")
>>
>> a8c06e407e("usb: separate out sysdev pointer from usb_bus")
>>
>> aeb78cda51("usb: chipidea: use bus->sysdev for DMA configuration")
>>
>> 8123e4953f("usb: ehci: fsl: use bus->sysdev for DMA configuration")
>>
>> 4c39d4b949("usb: xh

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

[Adam Borowski]

On Wed, Oct 11, 2017 at 02:01:41AM +, Nick Terrell wrote:
> On 10/10/17, 5:08 PM, "Adam Borowski" <kilob...@angband.pl> wrote:
> > On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote:
> > > On 10/10/17, 2:56 PM, "h...@zytor.com" <h...@zytor.com> wrote:
> > > >On October 10, 2017 2:22:42 PM PDT, Nick Terrell <terre...@fb.com> wrote:
> > > >>This patch set adds support for a ZSTD-compressed kernel and ramdisk
> > > >>images in the kernel boot process. It only integrates the support with
> > > >>x86, though the first patch is generic to all architectures.
> 
> > > Comparing the command line tools on a kernel image that is 68970616 B 
> > > large:
> > >
> > > | Algorithm | Compression Ratio | Decompression MB/s |
> > > |---|---||
> > > | zstd  |  4.42 |  436.5 |
> > > | gzip  |  3.72 |  134.1 |
> > > | xz|  4.83 |   53.1 |
> > > | lz4   |  3.18 | 1682.2 |
> > > | lzo   |  3.36 |  389.6 |
> > > | bzip2 |  4.03 |   33.3 |
> 
> > Perhaps it'd be a good idea to cull some of bad algorithms?  I don't know
> > the memory used by those, but envelope of the table you just shown suggests
> > using bzip2 and lzo is pointless.  So is gzip, but it's widespread as the
> > default for initramfs producers, thus it'd be unsafe to kill it.
> 
> I'm not sure there is a great use case for bzip2. It requires more memory
> than xz, compresses worse, and decompresses slower. lzo in the kernel might
> decompress a bit faster than zstd (looking back at the BtrFS benchmarks, it
> did). More importantly, it uses less memory than zstd. When decompressing
> the kernel zstd only needs 192 KB, but for initramfs, it will need more.
> Still, unless you really need 5% more compression, lz4 is probably a better
> option than lzo for speed.

The main reason I'm raising this question is, bzip2 has no other users in
the kernel, thus removing support for it would allow us to delete its code.

As for lzo, even if there are cases when it's a bit faster (overcoming the
9% lead zstd has in your userspace benchmark), it wouldn't be faster by
much -- certainly nowhere to make anyone want the massive compression loss.

Thus, let's enumerate use cases:
* a fast modern machine: zstd boots a second faster at the cost of 1.3MB
  image size; doesn't matter much either way.  No one wants weaker options.
* a weaker machine: zstd rapidly gains as boot times rise.
* a very slow machine with fast I/O that boots often: lz4.
* disk space at extreme premium: xz.

In no case I can think of other algorithms are the rational choice.
There's little gain in removing the rest, though: the code is used for other
purposes in the kernel, and doesn't get compiled in unless manually
selected.

Zstd looks like a good default, but it's nowhere near mature enough: this
patch is x86-only, tools which people may use to analyze compressed kernels
don't know about zstd yet, etc.

Thus, I'd propose the following plan:
* add zstd
* remove bzip2
* update recommendations (Kconfig text)
* in a year or two, consider making zstd the default

> > > I know that this isn't a real benchmark of the kernel decompression. I
> > > still need to figure out how to time the kernel decompression. If you have
> > > any suggestions let me know. Otherwise, I'll get back to you when I've
> > > figured out how to run the benchmark.
> 
> I've found a way to benchmark the kernel decompression time during boot
> with QEMU. I add timestamps to every line of the output. I also had to
> print 100 lines before the decompression starts to get consistent results.
> 
> I've found that zstd is decompressing 2x slower than it should. I narrowed
> down the problem to ZSTD_wildcopy() and ZSTD_copy8() in
> lib/zstd/zstd_internal.h. ZSTD_wildcopy() calls memcpy(src, dst, 8) in
> a loop and doesn't handle the freestanding memcpy() well. Replacing it with
> __builtin_mcmpy(src, dst, 8) doubles the speed.

... and by maturing I meant issues like this.

> I'm not an expert in freestanding gcc compilation, but I believe it is okay
> to call __builtin_memcpy() in freestanding mode, and gcc will either
> inline it, or add the right function call. The difference being that gcc
> will be able to apply its memcpy() analysis. I also see that
> arch/x86/boot/string.h defines memcpy() to __builtin_memcpy. Is it safe to
> directly use __builtin_memcpy() in lib/zstd/zstd_internal.h?

Try it, and see if it builds and fails to crash. :)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

[Adam Borowski]

On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote:
> On 10/10/17, 2:56 PM, "h...@zytor.com"  wrote:
> >On October 10, 2017 2:22:42 PM PDT, Nick Terrell  wrote:
> >>This patch set adds support for a ZSTD-compressed kernel and ramdisk
> >>images in the kernel boot process. It only integrates the support with
> >>x86, though the first patch is generic to all architectures.
> >>
> >>Zstandard requires slightly more memory during the kernel decompression
> >>on x86 (192 KB vs 64 KB), and the memory usage is independent of the
> >>window size.
> >>
> >>Zstandard requires memory proprortional to the window size used during
> >>compression for decompressing the ramdisk image, since streaming mode
> >>is
> >>used. Newer versions of zstd (1.3.2+) list the window size of a file
> >>with `zstd -lv '. The absolute maximum amount of memory required
> >>is just over 8 MB.

> > And, pray tell, what are the actual results?  What is the trade-off of
> > kernel size versus decompression performance versus the other algorithms
> > that we already support?  Adding algorithms for their own sake is a bad
> > thing not a good thing.
> 
> Sorry I neglected to include the benchmarks I've run so far. I've included
> them below, and will add them to the next version's cover letter.
> 
> Comparing the command line tools on a kernel image that is 68970616 B large:
> 
> | Algorithm | Compression Ratio | Decompression MB/s |
> |---|---||
> | zstd  |  4.42 |  436.5 |
> | gzip  |  3.72 |  134.1 |
> | xz|  4.83 |   53.1 |
> | lz4   |  3.18 | 1682.2 |
> | lzo   |  3.36 |  389.6 |
> | bzip2 |  4.03 |   33.3 |

Perhaps it'd be a good idea to cull some of bad algorithms?  I don't know
the memory used by those, but envelope of the table you just shown suggests
using bzip2 and lzo is pointless.  So is gzip, but it's widespread as the
default for initramfs producers, thus it'd be unsafe to kill it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

RE: [RFC PATCH v2 6/7] typec: tcpm: Represent source supply through power_supply class

[Adam Thomson]

On 25 November 2017 14:03, Hans de Goede wrote:

> Hi,
> 
> On 11/24/2017 01:19 PM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, Nov 14, 2017 at 11:44:47AM +, Adam Thomson wrote:
> >> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> >> index 78983e1..7c26c3d 100644
> >> --- a/drivers/usb/typec/tcpm.c
> >> +++ b/drivers/usb/typec/tcpm.c
> >> @@ -12,6 +12,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -277,6 +278,10 @@ struct tcpm_port {
> >>u32 current_limit;
> >>u32 supply_voltage;
> >>
> >> +  /* Used to export TA voltage and current */
> >> +  struct power_supply *psy;
> >> +  struct power_supply_desc psy_desc;
> >> +
> >>u32 bist_request;
> >>
> >>/* PD state for Vendor Defined Messages */
> >> @@ -1756,6 +1761,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> >>int ret = -EINVAL;
> >>
> >>port->pps_data.supported = false;
> >> +  port->psy_desc.type = POWER_SUPPLY_TYPE_USB_PD;
> >>
> >>/*
> >> * Select the source PDO providing the most power while staying within
> >> @@ -1775,8 +1781,10 @@ static int tcpm_pd_select_pdo(struct tcpm_port
> *port)
> >>mv = pdo_min_voltage(pdo);
> >>break;
> >>case PDO_TYPE_APDO:
> >> -  if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
> >> +  if (pdo_apdo_type(pdo) == APDO_TYPE_PPS) {
> >>port->pps_data.supported = true;
> >> +  port->psy_desc.type =
> POWER_SUPPLY_TYPE_USB_PD_PPS;
> >> +  }
> >>continue;
> >>default:
> >>tcpm_log(port, "Invalid PDO type, ignoring");
> >> @@ -2248,6 +2256,9 @@ static void tcpm_reset_port(struct tcpm_port *port)
> >>port->try_snk_count = 0;
> >>port->supply_voltage = 0;
> >>port->current_limit = 0;
> >> +  port->psy_desc.type = POWER_SUPPLY_TYPE_USB_TYPE_C;
> >
> > Is it OK to everybody that the type of the psy is changed like that?
> > Hans?!
> >
> > We do have drivers that already change the type, for example
> > drivers/power/supply/isp1704_charger.c, but what does the user space
> > expect? The ABI for the power supply class was never documented I
> > guess.
> 
> The main userspace consumer of the power_supply sysfs class is upower,
> upower knows about 3 types: "Mains", "Battery" and "USB", anything
> else it gives a type of UP_DEVICE_KIND_UNKNOWN. So
> POWER_SUPPLY_TYPE_USB_TYPE_C
> vs POWER_SUPPLY_TYPE_USB_PD_PPS does matter to it.

Does or doesn't matter? I had a quick look at the code for upower and if I
understand correctly right now both USB_TYPE_C and USB_PD_PPS would be
represented as 'UP_DEVICE_KIND_UNKNOWN' based on g_ascii_strcasecmp result. Is
that correct?

RE: [PATCH 2/2 v7] typec: tcpm: Only request matching pdos

[Adam Thomson]

On 28 November 2017 02:07, Guenter Roeck wrote:

> On 11/27/2017 05:38 PM, Badhri Jagan Sridharan wrote:
> > On Thu, Nov 23, 2017 at 3:10 AM, Adam Thomson
> > <adam.thomson.opensou...@diasemi.com> wrote:
> >> On 16 November 2017 01:02, Badhri Jagan Sridharan wrote:
> >>
> >>> At present, TCPM code assumes that local device supports
> >>> variable/batt pdos and always selects the pdo with highest
> >>> possible power within the board limit. This assumption
> >>> might not hold good for all devices. To overcome this,
> >>> this patch makes TCPM only accept a source_pdo when there is
> >>> a matching sink pdo.
> >>>
> >>> For Fixed pdos: The voltage should match between the
> >>> incoming source_cap and the registered snk_pdo
> >>> For Variable/Batt pdos: The incoming source_cap voltage
> >>> range should fall within the registered snk_pdo's voltage
> >>> range.
> >>>
> >>> Also, when the cap_mismatch bit is set, the max_power/current
> >>> should be set to the max_current/power of the sink_pdo.
> >>> This is according to:
> >>>
> >>> "If the Capability Mismatch bit is set to one
> >>> The Maximum Operating Current/Power field may contain a value
> >>> larger than the maximum current/power offered in the Source
> >>> Capabilities message’s PDO as referenced by the Object position field.
> >>> This enables the Sink to indicate that it requires more current/power
> >>> than is being offered. If the Sink requires a different voltage this
> >>> will be indicated by its Sink Capabilities message.
> >>
> >> Hi Badhri,
> >>
> >> I have some queries on this change. At the moment the src/snk PDOs are hard
> >> coded in the relevant PD controller driver (e.g. fusb302.c), and the only 
> >> way
> >> to update these is to call the tcpm_update_source_capabilities() or
> >> tcpm_update_sink_capabilities() functions. However there are no real world
> >
> > Good point ! But I dont see any code which calls this either. I believe
> > Guenter added this. Guenter do you know ?
> >
> 
> A source might change its power capabilities dynamically. Practical example is
> a system with two USB-C ports. If one is in use, it may support 3A output 
> power.
> If two are in use, it may support 1.5A each. This isn't currently used in the
> kernel, but some of our devices have this behavior, so I thought it would be
> prudent to have support for it. The same is true for a sink, which may change
> its power requirements at runtime (same situation - a device is inserted at
> the second USB port) and ask for more or less power.
> 
> Is that a problem ? I won't object if you want to take it out because there is
> no current user, but you should keep in mind that those are valid use cases,
> and that the code should at least be extensible (ie the patch taking it away
> should be revertible) to support those use cases.

No, I have no desire to remove it and definitely see the valid use-cases. I was
curious though as to where these functions might be called from within the
kernel as wherever that is it will need to have the ability to retrieve the port
instance to be able to call these functions.

RE: [RFC PATCH v2 6/7] typec: tcpm: Represent source supply through power_supply class

[Adam Thomson]

On 27 November 2017 14:12, Heikki Krogerus wrote:

> Hi Adam,
> 
> On Fri, Nov 24, 2017 at 02:05:27PM +0000, Adam Thomson wrote:
> > On 24 November 2017 12:19, Heikki Krogerus wrote:
> > > Is it OK to everybody that the type of the psy is changed like that?
> > > Hans?!
> > >
> > > We do have drivers that already change the type, for example
> > > drivers/power/supply/isp1704_charger.c, but what does the user space
> > > expect? The ABI for the power supply class was never documented I
> > > guess.
> > >
> >
> > Hi Heikki,
> >
> > Appreciate your time in reviewing this.
> >
> > Yes, I actually saw that as an example when I considered this approach. I 
> > didn't
> > see anything obvious for this in the ABI documentation. Any ideas Sebastian?
> > What is user-space expectation for the 'type' property of a power_supply? I
> > assume having this dynamic is ok given existing drivers can already do 
> > something
> > like this, but would be good to have clarification.
> >
> > > I'm not against changing the type, but I think that we should have an
> > > attribute file listing all supported types a psy can have if we go
> > > forward with this. Ideally the type file would just list them as space
> > > separated values, and show the current one with asterisk in front of
> > > it. The output would be similar we have with some of the other files
> > > under /sys/power, at least /sys/power/state, but that would break the
> > > ABI.
> > >
> >
> > I added this as I wanted the user to know what was connected rather than
> > blindly trying to set the 'online' property to enable PPS, even if the 
> > attached
> > source partner didn't support this. As you say, am not sure we could change 
> > the
> > 'TYPE' property as that to my knowledge has always been a single string.
> >
> > Maybe the addition of a 'SUPPORTED_TYPES' property or something similar 
> > could
> > close this gap (as you eluded to), at least by providing a RO list of all
> > supported types? Another option would be to add a type which indicates the
> > supply supports multiple types, and then based on this we can read another
> > property which does as you suggest with multiple strings and one being
> > highlighted? Am certainly open to discussion on this.
> 
> It looks like this is USB specific problem. I think the type should
> actually be just USB, and there should be an other USB only attribute
> file which should list the current and supported connection types.
> Well, maybe it does not even need to be USB only.

I believe in Android (BatteryMonitor) right now it maps the various USB
types that can be reported by a power_supply driver to an internal Android 'AC'
type (or 'USB' for 'PD_DRP') for use in upper level software, so they handle the
various USB reported types but simplify reporting. That code seems like it would
also handle changes in type as well because the type is re-read when dealing
with updates. So there is a wide spread user which already 'copes' with current
driver implementations. That's not saying it's necessarily the correct way to go
in the future but wanted to highlight current usage.

Personally what you're suggesting seems reasonable to me. I would however like
to get a general consensus on this as I guess this could potentially change
future power_supply driver implementations.

Sebastian, do you have any thoughts on this topic?

RE: [PATCH 1/2] ASoC: da7213: Delete an error message for a failed memory allocation in da7213_fw_to_pdata()

[Adam Thomson]

On 24 November 2017 11:33, Julia Lawall wrote:

> On Fri, 24 Nov 2017, Adam Thomson wrote:
> 
> > On 23 November 2017 17:33, SF Markus Elfring wrote:
> >
> > > From: Markus Elfring <elfr...@users.sourceforge.net>
> > > Date: Thu, 23 Nov 2017 17:56:54 +0100
> > >
> > > Omit an extra message for a memory allocation failure in this function.
> >
> > I'm not sure this is an extra message. We don't return -ENOMEM as a result 
> > of
> > this operation and probe won't fail on this. So does devm_kzalloc() print 
> > error
> > messages?
> 
> Unless there is NO WARN, a backtrace will be generated in the out of
> memory case.
> 
> julia

Ok, fair enough. In which case:

Acked-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

> 
> >
> > > This issue was detected by using the Coccinelle software.
> > >
> > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> > > ---
> > >  sound/soc/codecs/da7213.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c
> > > index 41d9b1da27c2..d1b77a0e3b74 100644
> > > --- a/sound/soc/codecs/da7213.c
> > > +++ b/sound/soc/codecs/da7213.c
> > > @@ -1654,10 +1654,8 @@ static struct da7213_platform_data
> > >   u32 fw_val32;
> > >
> > >   pdata = devm_kzalloc(codec->dev, sizeof(*pdata), GFP_KERNEL);
> > > - if (!pdata) {
> > > - dev_warn(codec->dev, "Failed to allocate memory for pdata\n");
> > > + if (!pdata)
> > >   return NULL;
> > > - }
> > >
> > >   if (device_property_read_u32(dev, "dlg,micbias1-lvl", _val32) >= 0)
> > >   pdata->micbias1_lvl = da7213_of_micbias_lvl(codec, fw_val32);
> > > --
> > > 2.15.0
> > N?r??y??X??ǧv???)޺{.n?z?ޖ6?)?*¬
> jg??? ?ݢj/???z?ޖޙ&?)ߡ?a???G? ??:+v???w

RE: [PATCH 2/2] ASoC: da7213: Improve a size determination in da7213_i2c_probe()

[Adam Thomson]

On 23 November 2017 17:34, SF Markus Elfring wrote:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 23 Nov 2017 18:15:30 +0100
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

> ---
>  sound/soc/codecs/da7213.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c
> index d1b77a0e3b74..b2b4e90fc02a 100644
> --- a/sound/soc/codecs/da7213.c
> +++ b/sound/soc/codecs/da7213.c
> @@ -1853,8 +1853,7 @@ static int da7213_i2c_probe(struct i2c_client *i2c,
>   struct da7213_priv *da7213;
>   int ret;
> 
> - da7213 = devm_kzalloc(>dev, sizeof(struct da7213_priv),
> -   GFP_KERNEL);
> + da7213 = devm_kzalloc(>dev, sizeof(*da7213), GFP_KERNEL);
>   if (!da7213)
>   return -ENOMEM;
> 
> --
> 2.15.0

RE: [PATCH 2/3] ASoC: da7218: Use common error handling code in da7218_of_to_pdata()

[Adam Thomson]

On 23 November 2017 20:06, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Thu, 23 Nov 2017 20:48:05 +0100
> 
> Add a jump target so that a bit of exception handling can be better reused
> in an if branch of this function.
> 
> Signed-off-by: Markus Elfring 

Hmm. Doesn't really gain an awful lot this. Would understand if there were
multiple return paths, but in that case I'd have implemented something like
this anyway. Also your patch description isn't really correct. You're re-using
code from the sunny day scenario to handle an exception.

> ---
>  sound/soc/codecs/da7218.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
> index 25ab7443d803..93a0cb741751 100644
> --- a/sound/soc/codecs/da7218.c
> +++ b/sound/soc/codecs/da7218.c
> @@ -2524,10 +2524,9 @@ static struct da7218_pdata *da7218_of_to_pdata(struct
> snd_soc_codec *codec)
> 
>   hpldet_pdata = devm_kzalloc(codec->dev, sizeof(*hpldet_pdata),
>   GFP_KERNEL);
> - if (!hpldet_pdata) {
> - of_node_put(hpldet_np);
> - return pdata;
> - }
> + if (!hpldet_pdata)
> + goto put_node;
> +
>   pdata->hpldet_pdata = hpldet_pdata;
> 
>   if (of_property_read_u32(hpldet_np, "dlg,jack-rate-us",
> @@ -2561,6 +2560,7 @@ static struct da7218_pdata *da7218_of_to_pdata(struct
> snd_soc_codec *codec)
>   if (of_property_read_bool(hpldet_np, "dlg,discharge"))
>   hpldet_pdata->discharge = true;
> 
> +put_node:
>   of_node_put(hpldet_np);
>   }
> 
> --
> 2.15.0

RE: [PATCH 1/3] ASoC: da7218: Delete two error messages for a failed memory allocation in da7218_of_to_pdata()

[Adam Thomson]

On 23 November 2017 20:05, SF Markus Elfring wrote:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 23 Nov 2017 20:42:20 +0100
> 
> Omit extra messages for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

> ---
>  sound/soc/codecs/da7218.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
> index 56564ce90cb6..25ab7443d803 100644
> --- a/sound/soc/codecs/da7218.c
> +++ b/sound/soc/codecs/da7218.c
> @@ -2455,10 +2455,8 @@ static struct da7218_pdata *da7218_of_to_pdata(struct
> snd_soc_codec *codec)
>   u32 of_val32;
> 
>   pdata = devm_kzalloc(codec->dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata) {
> - dev_warn(codec->dev, "Failed to allocate memory for pdata\n");
> + if (!pdata)
>   return NULL;
> - }
> 
>   if (of_property_read_u32(np, "dlg,micbias1-lvl-millivolt", _val32) 
> >= 0)
>   pdata->micbias1_lvl = da7218_of_micbias_lvl(codec, of_val32);
> @@ -2527,8 +2525,6 @@ static struct da7218_pdata *da7218_of_to_pdata(struct
> snd_soc_codec *codec)
>   hpldet_pdata = devm_kzalloc(codec->dev, sizeof(*hpldet_pdata),
>   GFP_KERNEL);
>   if (!hpldet_pdata) {
> - dev_warn(codec->dev,
> -  "Failed to allocate memory for hpldet 
> pdata\n");
>   of_node_put(hpldet_np);
>   return pdata;
>   }
> --
> 2.15.0

RE: [PATCH 1/2] ASoC: da7213: Delete an error message for a failed memory allocation in da7213_fw_to_pdata()

[Adam Thomson]

On 23 November 2017 17:33, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Thu, 23 Nov 2017 17:56:54 +0100
> 
> Omit an extra message for a memory allocation failure in this function.

I'm not sure this is an extra message. We don't return -ENOMEM as a result of
this operation and probe won't fail on this. So does devm_kzalloc() print error
messages?

> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  sound/soc/codecs/da7213.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c
> index 41d9b1da27c2..d1b77a0e3b74 100644
> --- a/sound/soc/codecs/da7213.c
> +++ b/sound/soc/codecs/da7213.c
> @@ -1654,10 +1654,8 @@ static struct da7213_platform_data
>   u32 fw_val32;
> 
>   pdata = devm_kzalloc(codec->dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata) {
> - dev_warn(codec->dev, "Failed to allocate memory for pdata\n");
> + if (!pdata)
>   return NULL;
> - }
> 
>   if (device_property_read_u32(dev, "dlg,micbias1-lvl", _val32) >= 0)
>   pdata->micbias1_lvl = da7213_of_micbias_lvl(codec, fw_val32);
> --
> 2.15.0

RE: [PATCH 3/3] ASoC: da7218: Improve a size determination in da7218_i2c_probe()

[Adam Thomson]

On 23 November 2017 20:08, SF Markus Elfring wrote:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 23 Nov 2017 20:50:44 +0100
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

> ---
>  sound/soc/codecs/da7218.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
> index 93a0cb741751..0c1933a98995 100644
> --- a/sound/soc/codecs/da7218.c
> +++ b/sound/soc/codecs/da7218.c
> @@ -3269,8 +3269,7 @@ static int da7218_i2c_probe(struct i2c_client *i2c,
>   struct da7218_priv *da7218;
>   int ret;
> 
> - da7218 = devm_kzalloc(>dev, sizeof(struct da7218_priv),
> -   GFP_KERNEL);
> + da7218 = devm_kzalloc(>dev, sizeof(*da7218), GFP_KERNEL);
>   if (!da7218)
>   return -ENOMEM;
> 
> --
> 2.15.0

RE: [RFC PATCH v2 6/7] typec: tcpm: Represent source supply through power_supply class

[Adam Thomson]

On 24 November 2017 12:19, Heikki Krogerus wrote:

> Hi,
> 
> On Tue, Nov 14, 2017 at 11:44:47AM +0000, Adam Thomson wrote:
> > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> > index 78983e1..7c26c3d 100644
> > --- a/drivers/usb/typec/tcpm.c
> > +++ b/drivers/usb/typec/tcpm.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -277,6 +278,10 @@ struct tcpm_port {
> > u32 current_limit;
> > u32 supply_voltage;
> >
> > +   /* Used to export TA voltage and current */
> > +   struct power_supply *psy;
> > +   struct power_supply_desc psy_desc;
> > +
> > u32 bist_request;
> >
> > /* PD state for Vendor Defined Messages */
> > @@ -1756,6 +1761,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> > int ret = -EINVAL;
> >
> > port->pps_data.supported = false;
> > +   port->psy_desc.type = POWER_SUPPLY_TYPE_USB_PD;
> >
> > /*
> >  * Select the source PDO providing the most power while staying within
> > @@ -1775,8 +1781,10 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> > mv = pdo_min_voltage(pdo);
> > break;
> > case PDO_TYPE_APDO:
> > -   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
> > +   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS) {
> > port->pps_data.supported = true;
> > +   port->psy_desc.type =
> POWER_SUPPLY_TYPE_USB_PD_PPS;
> > +   }
> > continue;
> > default:
> > tcpm_log(port, "Invalid PDO type, ignoring");
> > @@ -2248,6 +2256,9 @@ static void tcpm_reset_port(struct tcpm_port *port)
> > port->try_snk_count = 0;
> > port->supply_voltage = 0;
> > port->current_limit = 0;
> > +   port->psy_desc.type = POWER_SUPPLY_TYPE_USB_TYPE_C;
> 
> Is it OK to everybody that the type of the psy is changed like that?
> Hans?!
> 
> We do have drivers that already change the type, for example
> drivers/power/supply/isp1704_charger.c, but what does the user space
> expect? The ABI for the power supply class was never documented I
> guess.
> 

Hi Heikki,

Appreciate your time in reviewing this.

Yes, I actually saw that as an example when I considered this approach. I didn't
see anything obvious for this in the ABI documentation. Any ideas Sebastian?
What is user-space expectation for the 'type' property of a power_supply? I
assume having this dynamic is ok given existing drivers can already do something
like this, but would be good to have clarification.

> I'm not against changing the type, but I think that we should have an
> attribute file listing all supported types a psy can have if we go
> forward with this. Ideally the type file would just list them as space
> separated values, and show the current one with asterisk in front of
> it. The output would be similar we have with some of the other files
> under /sys/power, at least /sys/power/state, but that would break the
> ABI.
> 

I added this as I wanted the user to know what was connected rather than
blindly trying to set the 'online' property to enable PPS, even if the attached
source partner didn't support this. As you say, am not sure we could change the
'TYPE' property as that to my knowledge has always been a single string.

Maybe the addition of a 'SUPPORTED_TYPES' property or something similar could
close this gap (as you eluded to), at least by providing a RO list of all
supported types? Another option would be to add a type which indicates the
supply supports multiple types, and then based on this we can read another
property which does as you suggest with multiple strings and one being
highlighted? Am certainly open to discussion on this.

Re: Regression in TTM driver w/Linus' master

[Adam Williamson]

On Wed, 2017-11-22 at 17:17 -0800, Laura Abbott wrote:
> Hi,
> 
> Fedora QA testing reported a panic when booting up VMs
> using qmeu vga drivers 
> (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)
> 
> [   30.108507] [ cut here ]
> [   30.108920] kernel BUG at ./include/linux/gfp.h:408!
> [   30.109356] invalid opcode:  [#1] SMP
> [   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
> nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
> xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
> ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
> nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
> iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
> snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass 
> ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm 
> joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore 
> parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp 
> mrp stp llc virtio_net
> [   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
> crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
> ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
> [   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
> 4.15.0-0.rc0.git6.1.fc28.x86_64 #1
> [   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-2.fc27 04/01/2014
> [   30.118866] task: 923a77e03380 task.stack: a78182228000
> [   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
> [   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
> [   30.120250] RAX: 0001 RBX: 014382c6 RCX: 
> 0006
> [   30.120840] RDX:  RSI: 0009 RDI: 
> 
> [   30.121443] RBP: 923a760d6000 R08:  R09: 
> 0006
> [   30.122039] R10: 0040 R11: 0300 R12: 
> 923a729273c0
> [   30.122629] R13:  R14:  R15: 
> 923a7483d400
> [   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
> knlGS:
> [   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
> [   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 
> 06f0
> [   30.124968] Call Trace:
> [   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
> [   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
> [   30.125964]  __do_fault+0x19/0x11e
> [   30.126255]  __handle_mm_fault+0xcd3/0x1260
> [   30.126609]  handle_mm_fault+0x14c/0x310
> [   30.126947]  __do_page_fault+0x28c/0x530
> [   30.127282]  do_page_fault+0x32/0x270
> [   30.127593]  async_page_fault+0x22/0x30
> [   30.127922] RIP: 0033:0x7fe48aae39a8
> [   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
> [   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 
> 7fe457b73040
> [   30.129259] RDX: 0030 RSI:  RDI: 
> 7fe457b73000
> [   30.129855] RBP: 0300 R08: 000c R09: 
> 0001
> [   30.130457] R10: 0001 R11: 0246 R12: 
> 55cd4c1041a0
> [   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 
> 0400
> [   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff 
> ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 
> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
> [   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
> [   30.133836] ---[ end trace d4f1deb60784f40a ]---
> 
> This is based off of Linus' master branch at 
> c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
> Configs are at 
> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0

To be as precise as I can at present, this appeared somewhere between
these two Fedora kernel package builds:

Package:  kernel-4.15.0-0.rc0.git6.1.fc28
Old package:  kernel-4.15.0-0.rc0.git3.1.fc28

(that is, 'git3' did not have the issue, 'git6' does). Laura could
translate that to a delta that'd mean more to you folks, I expect.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

RE: [PATCH 2/2 v7] typec: tcpm: Only request matching pdos

[Adam Thomson]

On 16 November 2017 01:02, Badhri Jagan Sridharan wrote:

> At present, TCPM code assumes that local device supports
> variable/batt pdos and always selects the pdo with highest
> possible power within the board limit. This assumption
> might not hold good for all devices. To overcome this,
> this patch makes TCPM only accept a source_pdo when there is
> a matching sink pdo.
> 
> For Fixed pdos: The voltage should match between the
> incoming source_cap and the registered snk_pdo
> For Variable/Batt pdos: The incoming source_cap voltage
> range should fall within the registered snk_pdo's voltage
> range.
> 
> Also, when the cap_mismatch bit is set, the max_power/current
> should be set to the max_current/power of the sink_pdo.
> This is according to:
> 
> "If the Capability Mismatch bit is set to one
> The Maximum Operating Current/Power field may contain a value
> larger than the maximum current/power offered in the Source
> Capabilities message’s PDO as referenced by the Object position field.
> This enables the Sink to indicate that it requires more current/power
> than is being offered. If the Sink requires a different voltage this
> will be indicated by its Sink Capabilities message.

Hi Badhri,

I have some queries on this change. At the moment the src/snk PDOs are hard
coded in the relevant PD controller driver (e.g. fusb302.c), and the only way
to update these is to call the tcpm_update_source_capabilities() or
tcpm_update_sink_capabilities() functions. However there are no real world
examples in the kernel where this happens. Where are these functions likely to
be called from, as wherever that is it will need a reference to the port?
Actually should we be adding DT bindings to set supported src/snk PDOs from FW,
if you're taking this approach to PDO selection?

This patch also seemingly leaves 'max_snk_mv', 'max_snk_ma' and 'max_snk_mv'
redundant, although those values can be configured from a PD controller driver
(e.g. fusb302 actually supports DT bindings which allow these to be set through
FW). Now these DT bindings are basically made redundant by your change as they
have no impact. Are we expecting these to be used again in the future, or should
these be removed? FYI, as part of my PPS patch set I have been using them as
part of the PPS APDO selection criteria, based on TCPM code prior to your
modifications, as for PPS we're interested in a wide range of voltages and
currents but want to stay within the platforms limits.

> 
> Signed-off-by: Badhri Jagan Sridharan 
> Acked-by: Heikki Krogerus 
> Reviewed-by: Guenter Roeck 
> 
> ---
> Changelog since v1:
> - Rebased the patch on top of drivers/usb/type/tcpm.c
> - Added duplicate pdo check for variable/batt pdo.
> - Fixed tabs as suggested by dan.carpen...@oracle.com
> 
> Changelog since v2:
> - Rebase
> 
> Changelog since v3:
> - Refactored code fixed formatting issues as suggested
>   by heikki.kroge...@linux.intel.com
> 
> Changelog since v4:
> - Rebase
> 
> Changelog since v5:
> - handling the sink pdo index as pointer argument in tcpm_pd_select_pdo
> - ACK by heikki.kroge...@linux.intel.com
> 
> Changelog since v6:
> - Added Reviewed-by: Guenter Roeck 
> 
>  drivers/usb/typec/tcpm.c | 163 +++---
> -
>  1 file changed, 121 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 8b637a4b474b..f4d563ee7690 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -252,6 +252,9 @@ struct tcpm_port {
>   unsigned int nr_src_pdo;
>   u32 snk_pdo[PDO_MAX_OBJECTS];
>   unsigned int nr_snk_pdo;
> + 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 */
>   u32 snk_vdo[VDO_MAX_OBJECTS];
>   unsigned int nr_snk_vdo;
> 
> @@ -1767,39 +1770,90 @@ static int tcpm_pd_check_request(struct tcpm_port
> *port)
>   return 0;
>  }
> 
> -static int tcpm_pd_select_pdo(struct tcpm_port *port)
> +#define min_power(x, y) min(pdo_max_power(x), pdo_max_power(y))
> +#define min_current(x, y) min(pdo_max_current(x), pdo_max_current(y))
> +
> +static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
> +   int *src_pdo)
>  {
> - unsigned int i, max_mw = 0, max_mv = 0;
> + unsigned int i, j, max_mw = 0, max_mv = 0, mw = 0, mv = 0, ma = 0;
>   int ret = -EINVAL;
> 
>   /*
> -  * Select the source PDO providing the most power while staying within
> -  * the board's voltage limits. Prefer PDO providing exp
> +  * Select the source PDO providing the most power which has a
> +  * matchig sink cap.
>*/
>   for (i = 0; i < port->nr_source_caps; i++) {
>   u32 pdo = port->source_caps[i];
>   enum pd_pdo_type type = 

RE: [PATCH 2/2 v7] typec: tcpm: Only request matching pdos

[Adam Thomson]

On 28 November 2017 01:38, Badhri Jagan Sridharan wrote:

> > examples in the kernel where this happens. Where are these functions likely 
> > to
> > be called from, as wherever that is it will need a reference to the port?
> > Actually should we be adding DT bindings to set supported src/snk PDOs from 
> > FW,
> > if you're taking this approach to PDO selection?
> >
> > This patch also seemingly leaves 'max_snk_mv', 'max_snk_ma' and 'max_snk_mv'
> > redundant, although those values can be configured from a PD controller 
> > driver
> > (e.g. fusb302 actually supports DT bindings which allow these to be set 
> > through
> > FW). Now these DT bindings are basically made redundant by your change as 
> > they
> > have no impact. Are we expecting these to be used again in the future, or 
> > should
> 
> Yes, I think  'max_snk_mv', 'max_snk_ma' and 'max_snk_mw' etc should be
> removed.
> The problem here is that maintaining these values implies that tcpm is
> not going to
> request pdo based on the sink_caps that are published. All these
> values can be derived from
> the sink_pdo objects that were declared, hence, they are redundant,
> I will update the patch to remove this.

I have no problem really with this approach, other than right now with your
patch there's no way to actually set the PDOs other than the 2 functions to
update source and sink capabilities. Previously you had the option, at least
through the fusb302 driver, to configure the max_snk_* values from DT, but your
patch obviously changes this behaviour. I think we need a FW based method of
configuring these at startup at least, as with your current patch the values
being used are hard coded. As this is generic for TCPM I would guess DT bindings
(and maybe equivalent ACPI properties as well I guess) would be a sensible
approach.
 
> > these be removed? FYI, as part of my PPS patch set I have been using them as
> > part of the PPS APDO selection criteria, based on TCPM code prior to your
> > modifications, as for PPS we're interested in a wide range of voltages and
> > currents but want to stay within the platforms limits.
> 
> Arent you defining a new PDO type similar to PDO_FIXED, PDO_VARIABLE etc ?
> If so values such as " 'max_snk_mv', 'max_snk_ma' and
> 'max_snk_mw' " should be part of the APDO object right ? So why would
> you still need
>  'max_snk_mv', 'max_snk_ma' and 'max_snk_mw'  ?

My initial implementation was based on the approach before your changes, and
actually for PPS this to me made sense, at least from the sink side. We are
dealing with a range of voltages and currents so the important points are the
maximum values. However, if we're now making decisions based on sink PDOs then
I can look at adapting.

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 .../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   | 235 -
 5 files changed, 330 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 <adam.thomson.opensou...@diasemi.com>
+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 <adam.thomson.opensou...@diasemi.com>
+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 <adam.thomson.opensou...@diasemi.com>
+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 <adam.thomson.opensou...@diasemi.com>
+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 <adam.thomson.opensou...@diasemi.com>
+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 <adam.thomson.opensou...@diasemi.com>
+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_m

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

[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 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   | 918 -
 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, 1308 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

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 include/linux/usb/pd.h | 187 +
 1 file changed, 175 insertions(+), 12 deletions(-)

diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index b3d41d7..09b570f 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)))
+#define PD_HEADER_LE(type, pwr, data, rev, id, cnt) \
+   cpu_to_le16(PD_HEADER((type), (pwr), (data), (rev), (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 >> P

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 <adam.thomson.opensou...@diasemi.com>
+ */
+
+#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

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/tcpm.c | 533 ++-
 include/linux/usb/tcpm.h |   2 +-
 2 files changed, 523 insertions(+), 12 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,
  p

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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(

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 f2bac3d..fe3bbb9 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 message

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 <adam.thomson.opensou...@diasemi.com>
+ */
+
+#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

[PATCH v2] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.

To avoid this problem, this commit moves all FIFO reading to be
done based on a GCRCSENT event, and when reading from the FIFO
any GoodCRC messages read in are discarded so only valid messages
are reported to TCPM.

Changes in v2:
 - Remove erroneous extended header check

Patch is based on Linux next-20171114 to include move out of staging.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/fusb302/fusb302.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 72cb060..ddf88f0 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1650,12 +1650,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
-   /* read out the received good CRC */
-   ret = fusb302_pd_read_message(chip, _msg);
-   if (ret < 0) {
-   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
-   goto done;
-   }
tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
 
@@ -1671,12 +1665,22 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interruptb & FUSB_REG_INTERRUPTB_GCRCSENT) {
fusb302_log(chip, "IRQ: PD sent good CRC");
+retry:
ret = fusb302_pd_read_message(chip, _msg);
if (ret < 0) {
fusb302_log(chip,
"cannot read in PD message, ret=%d", ret);
goto done;
}
+
+   /*
+* Check to make sure we've not read off a GoodCRC message.
+* If so then read again to retrieve expected message
+*/
+   if ((!pd_header_cnt_le(pd_msg.header)) &&
+   (pd_header_type_le(pd_msg.header) == PD_CTRL_GOOD_CRC))
+   goto retry;
+
tcpm_pd_receive(chip->tcpm_port, _msg);
}
 done:
-- 
1.9.1

[PATCH] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.

To avoid this problem, this commit moves all FIFO reading to be
done based on a GCRCSENT event, and when reading from the FIFO
any GoodCRC messages read in are discarded so only valid messages
are reported to TCPM.

Patch is based on Linux next-20171114 to include move out of staging.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/fusb302/fusb302.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 72cb060..48a7ff4 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1650,12 +1650,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
-   /* read out the received good CRC */
-   ret = fusb302_pd_read_message(chip, _msg);
-   if (ret < 0) {
-   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
-   goto done;
-   }
tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
 
@@ -1671,12 +1665,23 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interruptb & FUSB_REG_INTERRUPTB_GCRCSENT) {
fusb302_log(chip, "IRQ: PD sent good CRC");
+retry:
ret = fusb302_pd_read_message(chip, _msg);
if (ret < 0) {
fusb302_log(chip,
"cannot read in PD message, ret=%d", ret);
goto done;
}
+
+   /*
+* Check to make sure we've not read off a GoodCRC message.
+* If so then read again to retrieve expected message
+*/
+   if ((!(pd_msg.header & PD_HEADER_EXT_HDR)) &&
+   (!pd_header_cnt_le(pd_msg.header)) &&
+   (pd_header_type_le(pd_msg.header) == PD_CTRL_GOOD_CRC))
+   goto retry;
+
tcpm_pd_receive(chip->tcpm_port, _msg);
}
 done:
-- 
1.9.1

[PATCH 1/2] ASoC: da7219: Correct IRQ level in DT binding example

[Adam Thomson]

Current DT binding documentation shows an example where the IRQ
for the device is chosen to be ACTIVE_HIGH. This is incorrect as
the device only supports ACTIVE_LOW, so this commit fixes that
discrepancy.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 Documentation/devicetree/bindings/sound/da7219.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/da7219.txt 
b/Documentation/devicetree/bindings/sound/da7219.txt
index cf61681..5b54d2d 100644
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ b/Documentation/devicetree/bindings/sound/da7219.txt
@@ -77,7 +77,7 @@ Example:
reg = <0x1a>;
 
interrupt-parent = <>;
-   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 
VDD-supply = <_audio>;
VDDMIC-supply = <_audio>;
-- 
1.9.1

[PATCH 0/2] ASoC: Correct DT binding examples IRQ usage for da7218/9

[Adam Thomson]

Currently in the DT bindings documents for DA7218 and DA7219, the examples for
bindings usage show ACTIVE_HIGH IRQ usage. For both devices this is incorrect
as the devices themselves only suport ACTIVE_LOW. This patch set rectifies the
inconsistency.

Adam Thomson (2):
  ASoC: da7219: Correct IRQ level in DT binding example
  ASoC: da7218: Correct IRQ level in DT binding example

 Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
 Documentation/devicetree/bindings/sound/da7219.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1

RE: [PATCH v2] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

On 17 November 2017 17:20, Guenter Roeck wrote:

> On Thu, Nov 16, 2017 at 04:28:11PM +0000, Adam Thomson wrote:
> > The expectation in the FUSB302 driver is that a TX_SUCCESS event
> > should occur after a message has been sent, but before a GCRCSENT
> > event is raised to indicate successful receipt of a message from
> > the partner. However in some circumstances it is possible to see
> > the hardware raise a GCRCSENT event before a TX_SUCCESS event
> > is raised. The upshot of this is that the GCRCSENT handling portion
> > of code ends up reporting the GoodCRC message to TCPM because the
> > TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
> > When TX_SUCCESS is then raised by the chip it ends up consuming the
> > actual message that was meant for TCPM, and this incorrect sequence
> > results in a hard reset from TCPM.
> >
> > To avoid this problem, this commit moves all FIFO reading to be
> > done based on a GCRCSENT event, and when reading from the FIFO
> > any GoodCRC messages read in are discarded so only valid messages
> > are reported to TCPM.
> >
> > Changes in v2:
> >  - Remove erroneous extended header check
> >
> > Patch is based on Linux next-20171114 to include move out of staging.
> >
> > Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> > ---
> >  drivers/usb/typec/fusb302/fusb302.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c
> b/drivers/usb/typec/fusb302/fusb302.c
> > index 72cb060..ddf88f0 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -1650,12 +1650,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
> >
> > if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
> > fusb302_log(chip, "IRQ: PD tx success");
> > -   /* read out the received good CRC */
> > -   ret = fusb302_pd_read_message(chip, _msg);
> > -   if (ret < 0) {
> > -   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
> > -   goto done;
> > -   }
> 
> If multiple "Good CRC" messages are received in a row, they won't be read from
> the chip, which might result in a buffer overflow.

Thanks for your comments. I had considered this since sending the patch. In 
reality I think we'd need to send 11 consecutive messages to which we receive
11 GoodCRCs without receiving a real response message from the partner to clear
the FIFO. Having looked again at the PD spec that seemed really unlikely, but...

> It might be better to always read all pending messages and handle it depending
> on the message type. Something along the line of
>
>   while (interrupts & (FUSB_REG_INTERRUPTA_TX_SUCCESS |
>FUSB_REG_INTERRUPTB_GCRCSENT)) {
>   ret = fusb302_pd_read_message(chip, _msg);
>   if (ret < 0)
>   goto done;
>   if (msg_type == good CRC) {
>   tcpm_pd_transmit_complete(chip->tcpm_port,
> TCPC_TX_SUCCESS);
>   interrupts &= ~FUSB_REG_INTERRUPTA_TX_SUCCESS;
>   } else {
>   tcpm_pd_receive(chip->tcpm_port, _msg);
>   interrupts &= ~FUSB_REG_INTERRUPTB_GCRCSENT;
>   }
>   }
> 
> Guenter

...I do prefer your approach as it doesn't leave anything to chance. I'll
respin accordingly.

> 
> > tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
> > }
> >
> > @@ -1671,12 +1665,22 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
> >
> > if (interruptb & FUSB_REG_INTERRUPTB_GCRCSENT) {
> > fusb302_log(chip, "IRQ: PD sent good CRC");
> > +retry:
> > ret = fusb302_pd_read_message(chip, _msg);
> > if (ret < 0) {
> > fusb302_log(chip,
> > "cannot read in PD message, ret=%d", ret);
> > goto done;
> > }
> > +
> > +   /*
> > +* Check to make sure we've not read off a GoodCRC message.
> > +* If so then read again to retrieve expected message
> > +*/
> > +   if ((!pd_header_cnt_le(pd_msg.header)) &&
> > +   (pd_header_type_le(pd_msg.header) == PD_CTRL_GOOD_CRC))
> > +   goto retry;
> > +
> > tcpm_pd_receive(chip->tcpm_port, _msg);
> > }
> >  done:
> > --
> > 1.9.1
> >

Re: [PATCH 3/3] scsi: 3w-9xxx: rework lock timeouts

[adam radford]

On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann <a...@arndb.de> wrote:
> The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether
> a lock has expired. This can misbehave due to a concurrent
> settimeofday() call, as it is based on 'real' time, and it
> will overflow in y2038 on 32-bit architectures, producing
> unexpected results when used across the overflow time.
>
> This changes it to using monotonic time, using ktime_get()
> to simplify the code.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/scsi/3w-9xxx.c | 13 ++---
>  drivers/scsi/3w-9xxx.h |  2 +-
>  2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index b1c9bd9c1bfd..b42c9c479d4b 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -645,8 +645,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned 
> int cmd, unsigned long
> TW_Command_Full *full_command_packet;
> TW_Compatibility_Info *tw_compat_info;
> TW_Event *event;
> -   struct timeval current_time;
> -   u32 current_time_ms;
> +   ktime_t current_time;
> TW_Device_Extension *tw_dev = 
> twa_device_extension_list[iminor(inode)];
> int retval = TW_IOCTL_ERROR_OS_EFAULT;
> void __user *argp = (void __user *)arg;
> @@ -837,17 +836,17 @@ static long twa_chrdev_ioctl(struct file *file, 
> unsigned int cmd, unsigned long
> break;
> case TW_IOCTL_GET_LOCK:
> tw_lock = (TW_Lock *)tw_ioctl->data_buffer;
> -   do_gettimeofday(_time);
> -   current_time_ms = (current_time.tv_sec * 1000) + 
> (current_time.tv_usec / 1000);
> +   current_time = ktime_get();
>
> -   if ((tw_lock->force_flag == 1) || (tw_dev->ioctl_sem_lock == 
> 0) || (current_time_ms >= tw_dev->ioctl_msec)) {
> +   if ((tw_lock->force_flag == 1) || (tw_dev->ioctl_sem_lock == 
> 0) ||
> +   ktime_after(current_time, tw_dev->ioctl_time)) {
> tw_dev->ioctl_sem_lock = 1;
> -   tw_dev->ioctl_msec = current_time_ms + 
> tw_lock->timeout_msec;
> +   tw_dev->ioctl_time = ktime_add_ms(current_time, 
> tw_lock->timeout_msec);
> tw_ioctl->driver_command.status = 0;
> tw_lock->time_remaining_msec = tw_lock->timeout_msec;
> } else {
> tw_ioctl->driver_command.status = 
> TW_IOCTL_ERROR_STATUS_LOCKED;
> -   tw_lock->time_remaining_msec = tw_dev->ioctl_msec - 
> current_time_ms;
> +   tw_lock->time_remaining_msec = 
> ktime_ms_delta(tw_dev->ioctl_time, current_time);
> }
> break;
> case TW_IOCTL_RELEASE_LOCK:
> diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
> index b6c208cc474f..d88cd3499bd5 100644
> --- a/drivers/scsi/3w-9xxx.h
> +++ b/drivers/scsi/3w-9xxx.h
> @@ -666,7 +666,7 @@ typedef struct TAG_TW_Device_Extension {
> unsigned char   event_queue_wrapped;
> unsigned interror_sequence_id;
> int ioctl_sem_lock;
> -   u32     ioctl_msec;
> +   ktime_t ioctl_time;
> int chrdev_request_id;
> wait_queue_head_t   ioctl_wqueue;
> struct mutexioctl_lock;
> --
> 2.9.0
>

Looks good...  Thanks for this fix!

Acked-by: Adam Radford <aradf...@gmail.com>

Re: [PATCH 2/3] scsi: 3ware: use 64-bit times for FW time sync

[adam radford]

On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann <a...@arndb.de> wrote:
> The calculation of the number of seconds since Sunday 00:00:00 overflows
> in 2106, meaning that we instead will return the seconds since Wednesday
> 06:28:16 afterwards.
>
> Using 64-bit time stamps avoids this slight inconsistency, and the
> deprecated do_gettimeofday(), replacing it with the simpler
> ktime_get_real_seconds().
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/scsi/3w-9xxx.c |  8 +++-
>  drivers/scsi/3w-sas.c  | 10 --
>  2 files changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index cb9af3f7b653..b1c9bd9c1bfd 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -472,11 +472,10 @@ static char *twa_aen_severity_lookup(unsigned char 
> severity_code)
>  static void twa_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
> u32 schedulertime;
> -   struct timeval utc;
> TW_Command_Full *full_command_packet;
> TW_Command *command_packet;
> TW_Param_Apache *param;
> -   u32 local_time;
> +   time64_t local_time;
>
> /* Fill out the command packet */
> full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -498,9 +497,8 @@ static void twa_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>
> /* Convert system time in UTC to local time seconds since last
> Sunday 12:00AM */
> -   do_gettimeofday();
> -   local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> -   schedulertime = local_time - (3 * 86400);
> +   local_time = (ktime_get_real_seconds() - (sys_tz.tz_minuteswest * 
> 60));
> +   div_u64_rem(local_time - (3 * 86400), 604800, );
> schedulertime = cpu_to_le32(schedulertime % 604800);
>
> memcpy(param->data, , sizeof(u32));
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index c283fdb3cb24..cf9f2a09b47d 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -407,11 +407,10 @@ static int twl_aen_read_queue(TW_Device_Extension 
> *tw_dev, int request_id)
>  static void twl_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
> u32 schedulertime;
> -   struct timeval utc;
> TW_Command_Full *full_command_packet;
> TW_Command *command_packet;
> TW_Param_Apache *param;
> -   u32 local_time;
> +   time64_t local_time;
>
> /* Fill out the command packet */
> full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -433,10 +432,9 @@ static void twl_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>
> /* Convert system time in UTC to local time seconds since last
> Sunday 12:00AM */
> -   do_gettimeofday();
> -   local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> -   schedulertime = local_time - (3 * 86400);
> -   schedulertime = cpu_to_le32(schedulertime % 604800);
> +   local_time = (ktime_get_real_seconds() - (sys_tz.tz_minuteswest * 
> 60));
> +   div_u64_rem(local_time - (3 * 86400), 604800, );
> +   schedulertime = cpu_to_le32(schedulertime);
>
> memcpy(param->data, , sizeof(u32));
>
> --
> 2.9.0
>

Acked-by: Adam Radford <aradf...@gmail.com>

Re: [PATCH 1/3] scsi: 3ware: fix 32-bit time calculations

[adam radford]

On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann <a...@arndb.de> wrote:
> twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday()
> to read the lower 32 bits of the current time in seconds, to pass
> them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read
> sysfs file.
>
> This will overflow on all architectures in year 2106, there is
> not much we can do about that without breaking the ABI. User
> space has 90 years to learn to deal with it, so it's probably ok.
>
> I'm changing it to use ktime_get_real_seconds() with a comment
> to document what happens when.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/scsi/3w-9xxx.c | 5 ++---
>  drivers/scsi/3w-sas.c  | 5 ++---
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index 00e7968a1d70..cb9af3f7b653 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -369,7 +369,6 @@ static int twa_aen_drain_queue(TW_Device_Extension 
> *tw_dev, int no_check_reset)
>  static void twa_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> u32 local_time;
> -   struct timeval time;
> TW_Event *event;
> unsigned short aen;
> char host[16];
> @@ -392,8 +391,8 @@ static void twa_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
> memset(event, 0, sizeof(TW_Event));
>
> event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> -   do_gettimeofday();
> -   local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> +   /* event->time_stamp_sec overflows in y2106 */
> +   local_time = (u32)(ktime_get_real_seconds() - (sys_tz.tz_minuteswest 
> * 60));
> event->time_stamp_sec = local_time;
> event->aen_code = aen;
> event->retrieved = TW_AEN_NOT_RETRIEVED;
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index b150e131b2e7..c283fdb3cb24 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -221,7 +221,6 @@ static char *twl_aen_severity_lookup(unsigned char 
> severity_code)
>  static void twl_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> u32 local_time;
> -   struct timeval time;
> TW_Event *event;
> unsigned short aen;
> char host[16];
> @@ -240,8 +239,8 @@ static void twl_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
> memset(event, 0, sizeof(TW_Event));
>
> event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> -   do_gettimeofday();
> -   local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> +   /* event->time_stamp_sec overflows in y2106 */
> +   local_time = (u32)(ktime_get_real_seconds() - (sys_tz.tz_minuteswest 
> * 60));
> event->time_stamp_sec = local_time;
> event->aen_code = aen;
> event->retrieved = TW_AEN_NOT_RETRIEVED;
> --
> 2.9.0
>

Acked-by: Adam Radford <aradf...@gmail.com>

RE: [PATCH 1/2] ASoC: da7218: fix fix child-node lookup

[Adam Thomson]

On 13 November 2017 11:13, Johan Hovold wrote:

> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
> 
> To make things worse, the parent codec node was also prematurely freed.
> 
> Fixes: 4d50934abd22 ("ASoC: da7218: Add da7218 codec driver")
> Cc: stable <sta...@vger.kernel.org> # 4.5
> Cc: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> Signed-off-by: Johan Hovold <jo...@kernel.org>

Acked-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

> ---
>  sound/soc/codecs/da7218.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
> index b2d42ec1dcd9..56564ce90cb6 100644
> --- a/sound/soc/codecs/da7218.c
> +++ b/sound/soc/codecs/da7218.c
> @@ -2520,7 +2520,7 @@ static struct da7218_pdata *da7218_of_to_pdata(struct
> snd_soc_codec *codec)
>   }
> 
>   if (da7218->dev_id == DA7218_DEV_ID) {
> - hpldet_np = of_find_node_by_name(np, "da7218_hpldet");
> + hpldet_np = of_get_child_by_name(np, "da7218_hpldet");
>   if (!hpldet_np)
>   return pdata;
> 
> --
> 2.15.0

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 7c26c3d..8db49ab 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,
 };
@@ -1285,10 +1293,42 @@ static void vdm_state_machine_work(struct work_struct 
*work)
 /*
  * 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)
 {
@@ -1371,6 +1411,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;
@@ -1453,6 +1501,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 */
@@ -1569,12 +1618,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 message

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/Kconfig   |   1 +
 drivers/usb/typec/fusb302/Kconfig   |   2 +-
 drivers/usb/typec/fusb302/fusb302.c |  63 +-
 drivers/usb/typec/tcpm.c| 225 +++-
 4 files changed, 228 insertions(+), 63 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 465d7da..b9cd806 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -8,6 +8,7 @@ config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
select TYPEC
+   select POWER_SUPPLY
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
 config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C && POWER_SUPPLY
+   depends on I2C
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/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 72cb060..21bd075 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -100,11 +99,6 @@ 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;
@@ -873,13 +867,11 @@ 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);
@@ -895,11 +887,6 @@ 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;
 }
 
@@ -1685,43 +1672,6 @@ 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,
-};
-
-static 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

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 <adam.thomson.opensou...@diasemi.com>
+ */
+
+#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

[RFC PATCH v2 5/7] power: supply: Add type for USB PD PPS chargers

[Adam Thomson]

This adds a type to represent USB PPS chargers as defined in the
USB Power Delivery Specification Revision 3.0 V1.1

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
---
 drivers/power/supply/power_supply_sysfs.c | 2 +-
 include/linux/power_supply.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..efd2469 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -43,7 +43,7 @@
 static const char * const power_supply_type_text[] = {
"Unknown", "Battery", "UPS", "Mains", "USB",
"USB_DCP", "USB_CDP", "USB_ACA", "USB_C",
-   "USB_PD", "USB_PD_DRP", "BrickID"
+   "USB_PD", "USB_PD_DRP", "USB_PD_PPS", "BrickID"
 };
 
 static const char * const power_supply_status_text[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 79e90b3..3a79c75 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -167,6 +167,7 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB_TYPE_C,   /* Type C Port */
POWER_SUPPLY_TYPE_USB_PD,   /* Power Delivery Port */
POWER_SUPPLY_TYPE_USB_PD_DRP,   /* PD Dual Role Port */
+   POWER_SUPPLY_TYPE_USB_PD_PPS,   /* PD Programmable Power Supply 
*/
POWER_SUPPLY_TYPE_APPLE_BRICK_ID,   /* Apple Charging Method */
 };
 
-- 
1.9.1

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 include/linux/usb/pd.h | 174 +
 1 file changed, 162 insertions(+), 12 deletions(-)

diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index e00051c..8c9ac80 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)))
+#define PD_HEADER_LE(type, pwr, data, rev, id, cnt) \
+   cpu_to_le16(PD_HEADER((type), (pwr), (data), (rev), (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 >> P

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

[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 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-20171114' to pick up
the move out of staging of TCPM related code.

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 type for USB PD PPS chargers
  typec: tcpm: Represent source supply through power_supply class
  typec: tcpm: Add support for sink PPS related messages

 drivers/power/supply/power_supply_sysfs.c |   2 +-
 drivers/usb/typec/Kconfig |   1 +
 drivers/usb/typec/fusb302/Kconfig |   2 +-
 drivers/usb/typec/fusb302/fusb302.c   |  63 +--
 drivers/usb/typec/tcpm.c  | 851 +-
 include/linux/power_supply.h  |   1 +
 include/linux/usb/pd.h| 174 +-
 include/linux/usb/pd_ado.h|  42 ++
 include/linux/usb/pd_ext_sdb.h|  31 ++
 include/linux/usb/tcpm.h  |   2 +-
 10 files changed, 1071 insertions(+), 98 deletions(-)
 create mode 100644 include/linux/usb/pd_ado.h
 create mode 100644 include/linux/usb/pd_ext_sdb.h

-- 
1.9.1

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 <adam.thomson.opensou...@diasemi.com>
+ */
+
+#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

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/tcpm.c | 476 +--
 include/linux/usb/tcpm.h |   2 +-
 2 files changed, 464 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index c166fc7..78983e1 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 {
+   u16 min_volt;
+   u16 max_volt;
+   u16 max_curr;
+   u16 out_volt;
+   u16 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;
@@ -259,6 +271,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;
@@ -275,8 +288,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];
@@ -494,6 +512,13 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_apdo_min_voltage(pdo),
+ pdo_apdo_max_voltage(pdo),
+ pdo_apdo_max_current(pdo));
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -788,11 +813,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);
}
@@ -813,11 +840,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,
+ port->negotiated_rev,
  port->message_id,
  port->nr_snk_pdo);
}
@@ -1184,6 +1213,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_DATA_VENDOR_DEF,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
 

Re: [PATCH] Revert "async: simplify lowest_in_progress()"

[Adam Wallis]

On 11/20/2017 5:51 PM, Rasmus Villemoes wrote:
> This reverts commit 92266d6ef60c2381c980c6cdcb2a5c1667b36b49, which
> was simply wrong: In the case where domain is NULL, we now use the
> wrong offsetof() in the list_first_entry macro, so we don't actually
> fetch the ->cookie value, but rather the eight bytes located
> sizeof(struct list_head) further into the struct async_entry.
> 
> On 64 bit, that's the data member, while on 32 bit, we get a u64 built
> from func and data in some order.
> 
> I think the bug happens to be harmless in practice: It obviously only
> affects callers which pass a NULL domain, and AFAICT the only such
> caller is
> 
>   async_synchronize_full() ->
>   async_synchronize_full_domain(NULL) ->
>   async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
> 
> and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
> the async_global_pending list to be empty - but it would break if
> somebody happened to pass (void*)-1 as the data element to
> async_schedule, and of course also if somebody ever does a
> async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
> 
> Cc: sta...@vger.kernel.org # 3.10+

Recommend adding "Fixes" notation here referencing the original broken commit.

> Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk>
> ---
[..]

-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.

To avoid this problem, this commit updates the message reading
code to check whether a GoodCRC message was received or not. Based
on this check it will either report that the previous transmission
has completed or it will pass the msg data to TCPM for futher
processing. This way the incorrect ordering of the events no longer
matters.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---

Changes in v3:
 - Always read from FIFO on TX_SUCCES and GCRCSENT events, but decision on how
   to report to TCPM is no longer based on these event types but instead on type
   of message read in from FIFO.

Changes in v2:
 - Remove erroneous extended header check

Patch is based on Linux next-20171114 to include move out of staging.

 drivers/usb/typec/fusb302/fusb302.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 72cb060..d200085 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1543,6 +1543,21 @@ static int fusb302_pd_read_message(struct fusb302_chip 
*chip,
fusb302_log(chip, "PD message header: %x", msg->header);
fusb302_log(chip, "PD message len: %d", len);
 
+   /*
+* Check if we've read off a GoodCRC message. If so then indicate to
+* TCPM that the previous transmission has completed. Otherwise we pass
+* the received message over to TCPM for processing.
+*
+* We make this check here instead of basing the reporting decision on
+* the IRQ event type, as it's possible for the chip to report the
+* TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
+* to check the message type to ensure correct reporting to TCPM.
+*/
+   if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
+   tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
+   else
+   tcpm_pd_receive(chip->tcpm_port, msg);
+
return ret;
 }
 
@@ -1650,13 +1665,12 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
-   /* read out the received good CRC */
ret = fusb302_pd_read_message(chip, _msg);
if (ret < 0) {
-   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
+   fusb302_log(chip,
+   "cannot read in PD message, ret=%d", ret);
goto done;
}
-   tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
 
if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
@@ -1677,7 +1691,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
"cannot read in PD message, ret=%d", ret);
goto done;
}
-   tcpm_pd_receive(chip->tcpm_port, _msg);
}
 done:
mutex_unlock(>lock);
-- 
1.9.1

RE: [RFC PATCH v2 0/7] typec: tcpm: Add sink side support for PPS

[Adam Thomson]

On 21 November 2017 14:18, Heikki Krogerus wrote:

> On Tue, Nov 21, 2017 at 01:51:41PM +0000, Adam Thomson wrote:
> > > These don't apply on top of Badhri's series:
> > > http://www.spinics.net/lists/kernel/msg2649921.html
> >
> > Hi Heikki,
> >
> > When I submitted these I was aware of Badhri's patch set but at the time 
> > they
> > hadn't been approved or pulled, at least not into the version of Linux next
> > that I had based on. If these are now merged in to Linux Next then I'll 
> > re-spin
> > based on those changes.
> 
> Sure, just wanted to give you heads up in case you had not noticed.
> 
> Sorry for the noise.

No noise, and thanks for the heads up. I actually hadn't seen that go in :)

RE: [RFC PATCH v2 0/7] typec: tcpm: Add sink side support for PPS

[Adam Thomson]

On 21 November 2017 13:36, Heikki Krogerus write:

> Hi Adam,
> 
> On Tue, Nov 14, 2017 at 11:44:41AM +0000, Adam Thomson wrote:
> > 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 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-20171114' to pick up
> > the move out of staging of TCPM related code.
> >
> > 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 type for USB PD PPS chargers
> >   typec: tcpm: Represent source supply through power_supply class
> >   typec: tcpm: Add support for sink PPS related messages
> >
> >  drivers/power/supply/power_supply_sysfs.c |   2 +-
> >  drivers/usb/typec/Kconfig |   1 +
> >  drivers/usb/typec/fusb302/Kconfig |   2 +-
> >  drivers/usb/typec/fusb302/fusb302.c   |  63 +--
> >  drivers/usb/typec/tcpm.c  | 851 
> > +-
> >  include/linux/power_supply.h  |   1 +
> >  include/linux/usb/pd.h| 174 +-
> >  include/linux/usb/pd_ado.h|  42 ++
> >  include/linux/usb/pd_ext_sdb.h|  31 ++
> >  include/linux/usb/tcpm.h  |   2 +-
> >  10 files changed, 1071 insertions(+), 98 deletions(-)
> >  create mode 100644 include/linux/usb/pd_ado.h
> >  create mode 100644 include/linux/usb/pd_ext_sdb.h
> 
> These don't apply on top of Badhri's series:
> http://www.spinics.net/lists/kernel/msg2649921.html

Hi Heikki,

When I submitted these I was aware of Badhri's patch set but at the time they
hadn't been approved or pulled, at least not into the version of Linux next
that I had based on. If these are now merged in to Linux Next then I'll re-spin
based on those changes.

[PATCH v3] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.

To avoid this problem, this commit updates the message reading
code to check whether a GoodCRC message was received or not. Based
on this check it will either report that the previous transmission
has completed or it will pass the msg data to TCPM for futher
processing. This way the incorrect ordering of the events no longer
matters.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---

Changes in v3:
 - Always read from FIFO on TX_SUCCES and GCRCSENT events, but decision on how
   to report to TCPM is no longer based on these event types but instead on type
   of message read in from FIFO.

Changes in v2:
 - Remove erroneous extended header check

Patch is based on Linux next-20171114 to include move out of staging.

 drivers/usb/typec/fusb302/fusb302.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 72cb060..d200085 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1543,6 +1543,21 @@ static int fusb302_pd_read_message(struct fusb302_chip 
*chip,
fusb302_log(chip, "PD message header: %x", msg->header);
fusb302_log(chip, "PD message len: %d", len);
 
+   /*
+* Check if we've read off a GoodCRC message. If so then indicate to
+* TCPM that the previous transmission has completed. Otherwise we pass
+* the received message over to TCPM for processing.
+*
+* We make this check here instead of basing the reporting decision on
+* the IRQ event type, as it's possible for the chip to report the
+* TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
+* to check the message type to ensure correct reporting to TCPM.
+*/
+   if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
+   tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
+   else
+   tcpm_pd_receive(chip->tcpm_port, msg);
+
return ret;
 }
 
@@ -1650,13 +1665,12 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
 
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
-   /* read out the received good CRC */
ret = fusb302_pd_read_message(chip, _msg);
if (ret < 0) {
-   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
+   fusb302_log(chip,
+   "cannot read in PD message, ret=%d", ret);
goto done;
}
-   tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
 
if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
@@ -1677,7 +1691,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
"cannot read in PD message, ret=%d", ret);
goto done;
}
-   tcpm_pd_receive(chip->tcpm_port, _msg);
}
 done:
mutex_unlock(>lock);
-- 
1.9.1

RE: [PATCH] typec: tcpm: fusb302: Resolve out of order messaging events

[Adam Thomson]

On 21 November 2017 14:08, Adam Thomson wrote:

> Subject: [PATCH] typec: tcpm: fusb302: Resolve out of order messaging events

Sorry. Finger trouble. Will resend with correct 'v3' title

> The expectation in the FUSB302 driver is that a TX_SUCCESS event
> should occur after a message has been sent, but before a GCRCSENT
> event is raised to indicate successful receipt of a message from
> the partner. However in some circumstances it is possible to see
> the hardware raise a GCRCSENT event before a TX_SUCCESS event
> is raised. The upshot of this is that the GCRCSENT handling portion
> of code ends up reporting the GoodCRC message to TCPM because the
> TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
> When TX_SUCCESS is then raised by the chip it ends up consuming the
> actual message that was meant for TCPM, and this incorrect sequence
> results in a hard reset from TCPM.
> 
> To avoid this problem, this commit updates the message reading
> code to check whether a GoodCRC message was received or not. Based
> on this check it will either report that the previous transmission
> has completed or it will pass the msg data to TCPM for futher
> processing. This way the incorrect ordering of the events no longer
> matters.
> 
> Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> ---
> 
> Changes in v3:
>  - Always read from FIFO on TX_SUCCES and GCRCSENT events, but decision on how
>to report to TCPM is no longer based on these event types but instead on 
> type
>of message read in from FIFO.
> 
> Changes in v2:
>  - Remove erroneous extended header check
> 
> Patch is based on Linux next-20171114 to include move out of staging.
> 
>  drivers/usb/typec/fusb302/fusb302.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/typec/fusb302/fusb302.c
> b/drivers/usb/typec/fusb302/fusb302.c
> index 72cb060..d200085 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -1543,6 +1543,21 @@ static int fusb302_pd_read_message(struct fusb302_chip
> *chip,
>   fusb302_log(chip, "PD message header: %x", msg->header);
>   fusb302_log(chip, "PD message len: %d", len);
> 
> + /*
> +  * Check if we've read off a GoodCRC message. If so then indicate to
> +  * TCPM that the previous transmission has completed. Otherwise we pass
> +  * the received message over to TCPM for processing.
> +  *
> +  * We make this check here instead of basing the reporting decision on
> +  * the IRQ event type, as it's possible for the chip to report the
> +  * TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
> +  * to check the message type to ensure correct reporting to TCPM.
> +  */
> + if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
> + tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
> + else
> + tcpm_pd_receive(chip->tcpm_port, msg);
> +
>   return ret;
>  }
> 
> @@ -1650,13 +1665,12 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
> *dev_id)
> 
>   if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
>   fusb302_log(chip, "IRQ: PD tx success");
> - /* read out the received good CRC */
>   ret = fusb302_pd_read_message(chip, _msg);
>   if (ret < 0) {
> - fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
> + fusb302_log(chip,
> + "cannot read in PD message, ret=%d", ret);
>   goto done;
>   }
> - tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
>   }
> 
>   if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
> @@ -1677,7 +1691,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
> *dev_id)
>   "cannot read in PD message, ret=%d", ret);
>   goto done;
>   }
> - tcpm_pd_receive(chip->tcpm_port, _msg);
>   }
>  done:
>   mutex_unlock(>lock);
> --
> 1.9.1

[PATCH v2][for 4.15] dmaengine: dmatest: move callback wait queue to thread context

[Adam Wallis]

Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks).

Commit a9df21e34b42 ("dmaengine: dmatest: warn user when dma test times
out") attempted to WARN the user that the stack was likely corrupted but
did not fix the actual issue.

This patch fixes the issue by pushing the wait queue and callback
structs into the the thread structure. If a failure occurs due to time,
dmaengine_terminate_all will force the callback to safely call
wake_up_all() without possibility of using a freed pointer.

Cc: sta...@vger.kernel.org # 4.13.x: a9df21e: dmatest: Warn User
Cc: sta...@vger.kernel.org # 4.13.x
Cc: sta...@vger.kernel.org # 4.14.x
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Reviewed-by: Sinan Kaya <ok...@codeaurora.org>
Suggested-by: Shunyong Yang <shunyong.y...@hxt-semitech.com>
Signed-off-by: Adam Wallis <awal...@codeaurora.org>
---
changes from v1: Added pre-req patches for stable


 drivers/dma/dmatest.c | 37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index 47edc7f..2573b6c 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -155,6 +155,12 @@ struct dmatest_params {
 #define PATTERN_COUNT_MASK 0x1f
 #define PATTERN_MEMSET_IDX 0x01
 
+/* poor man's completion - we want to use wait_event_freezable() on it */
+struct dmatest_done {
+   booldone;
+   wait_queue_head_t   *wait;
+};
+
 struct dmatest_thread {
struct list_headnode;
struct dmatest_info *info;
@@ -165,6 +171,8 @@ struct dmatest_thread {
u8  **dsts;
u8  **udsts;
enum dma_transaction_type type;
+   wait_queue_head_t done_wait;
+   struct dmatest_done test_done;
booldone;
 };
 
@@ -342,11 +350,6 @@ static unsigned int dmatest_verify(u8 **bufs, unsigned int 
start,
return error_count;
 }
 
-/* poor man's completion - we want to use wait_event_freezable() on it */
-struct dmatest_done {
-   booldone;
-   wait_queue_head_t   *wait;
-};
 
 static void dmatest_callback(void *arg)
 {
@@ -424,9 +427,8 @@ static unsigned long long dmatest_KBs(s64 runtime, unsigned 
long long len)
  */
 static int dmatest_func(void *data)
 {
-   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(done_wait);
struct dmatest_thread   *thread = data;
-   struct dmatest_done done = { .wait = _wait };
+   struct dmatest_done *done = >test_done;
struct dmatest_info *info;
struct dmatest_params   *params;
struct dma_chan *chan;
@@ -673,9 +675,9 @@ static int dmatest_func(void *data)
continue;
}
 
-   done.done = false;
+   done->done = false;
tx->callback = dmatest_callback;
-   tx->callback_param = 
+   tx->callback_param = done;
cookie = tx->tx_submit(tx);
 
if (dma_submit_error(cookie)) {
@@ -688,21 +690,12 @@ static int dmatest_func(void *data)
}
dma_async_issue_pending(chan);
 
-   wait_event_freezable_timeout(done_wait, done.done,
+   wait_event_freezable_timeout(thread->done_wait, done->done,
 msecs_to_jiffies(params->timeout));
 
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
 
-   if (!done.done) {
-   /*
-* We're leaving the timed out dma operation with
-* dangling pointer to done_wait.  To make this
-* correct, we'll need to allocate wait_done for
-* each test iteration and perform "who's gonna
-* free it this time?" dancing.  For now, just
-* leave it dangling.
-*/
-   WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
+   if (!done->done) {
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
   len, 0);
@@ -789,7 +782,7 @@ static int dmatest_func(void *data)
dmatest_KBs(runtime, total_len), ret);
 
/* terminate all transfers on specified channels */
-   if (ret)
+   if (ret || failed_tests)
dmaengine_terminate_all(chan);
 
thread->done = true;
@@ -849,6 +8

RE: [PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[Adam Thomson]

On 15 November 2017 16:43, alexander.le...@verizon.com wrote:

> On Wed, Nov 15, 2017 at 12:19:18PM +, Mark Brown wrote:
> >On Wed, Nov 15, 2017 at 02:45:42AM +, alexander.le...@verizon.com wrote:
> >
> >> This patch updates the AIF_OUT widget to set the DAI output pin of
> >> the device as high impedance when not in use.
> >
> >This will leave the line floating which EEs don't always like.  It's
> >probably OK and hasn't lead to any reports in mainline yet but still...
> 
> The idea I got from the patch is that output will not be working if
> there are multiple codecs?

Yes, if there are multiple codecs sharing the same DAI line for capture as
DA7217/8, and we don't set this to high impedance, then it will interfere with
the other codecs' capture data.

[PATCH 2/2] ASoC: da7218: Correct IRQ level in DT binding example

[Adam Thomson]

Current DT binding documentation shows an example where the IRQ
for the device is chosen to be ACTIVE_HIGH. This is incorrect as
the device only supports ACTIVE_LOW, so this commit fixes that
discrepancy.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/da7218.txt 
b/Documentation/devicetree/bindings/sound/da7218.txt
index 5ca5a70..3ab9dfe 100644
--- a/Documentation/devicetree/bindings/sound/da7218.txt
+++ b/Documentation/devicetree/bindings/sound/da7218.txt
@@ -73,7 +73,7 @@ Example:
compatible = "dlg,da7218";
reg = <0x1a>;
interrupt-parent = <>;
-   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
 
VDD-supply = <_audio>;
-- 
1.9.1

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

[Adam Thomson]

On 02 November 2017 16:49, Greg Kroah-Hartman wrote:

> On Thu, Nov 02, 2017 at 11:40:12AM +0000, Adam Thomson wrote:
> > On 01 November 2017 17:20, Greg Kroah-Hartman wrote:
> >
> > > On Wed, Nov 01, 2017 at 05:03:10PM +, Adam Thomson wrote:
> > > > 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 <adam.thomson.opensou...@diasemi.com>
> > > > ---
> > > >  include/linux/usb/pd_ado.h | 49
> > > ++
> > > >  1 file changed, 49 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..edcbcfa
> > > > --- /dev/null
> > > > +++ b/include/linux/usb/pd_ado.h
> > > > @@ -0,0 +1,49 @@
> > > > +/*
> > > > + * Copyright (c) 2017 Dialog Semiconductor
> > > > + *
> > > > + * Author: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License as published by
> > > > + * the Free Software Foundation; either version 2 of the License, or
> > > > + * (at your option) any later version.
> > >
> > > I have to ask, do you _really_ mean "any later version"?
> >
> > Many thanks for the prompt comments.
> >
> > So this is the same copyright header applied for the other PD related code
> > (bit of a copy and paste to follow existing tcpm practice), and have tended 
> > to
> > use this header for other driver development as well. Within the context of 
> > the
> > Linux kernel I believe this should be fine and will resolve to GPLv2, and 
> > should
> > someone use the code elsewhere then they can choose a later GPL license, not
> > that I suspect many would. Do you see any problems here as am happy to be
> > corrected? :)
>
> Please consult your lawyers as to what license you should use for new
> kernel code.  Never just blindly copy/paste without knowing what you are
> supposed to be doing :)

Yes, our legal department are aware of the use of this header, from previous
driver submissions, and have no problems. I certainly wouldn't have applied this
otherwise, but completely understand why you raised this :)

> > > > + *
> > > > + * This program is distributed in the hope that it will be useful,
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > > + * GNU General Public License for more details.
> > > > + */
> > > > +
> > > > +#ifndef __LINUX_USB_PD_ADO_H
> > > > +#define __LINUX_USB_PD_ADO_H
> > > > +
> > > > +/* ADO : Alert Data Object */
> > > > +#define ADO_TYPE_SHIFT 24
> > > > +#define ADO_TYPE_MASK  0xff
> > > > +#define ADO_FIXED_BATT_SHIFT   20
> > > > +#define ADO_FIXED_BATT_MASK0xf
> > > > +#define ADO_HOT_SWAP_BATT_SHIFT16
> > > > +#define ADO_HOT_SWAP_BATT_MASK 0xf
> > >
> > > USB_ prefixes perhaps?
> >
> > Again here I was following the existing TCPM approach, but if it's a problem
> > then I can update this.
>
> What does TCPM use here?  I missed those defines...

For example, include/linux/usb/pd_bdo.h uses defines such as:

#define BDO_MODE_TRANSMIT   (1 << 28)

and include/linux/usb/pd.h has defines such as:

#define PDO_FIXED_DUAL_ROLE BIT(29)

>
> > > > +
> > > > +#define ADO_TYPE_BATT_STATUS_CHANGEBIT(1)
> > > > +#define ADO_TYPE_OCP   BIT(2)
> > > > +#define ADO_TYPE_OTP   BIT(3)
> > > > +#define ADO_TYPE_OP_COND_CHANGEBIT(4)
> > > > +#define ADO_TYPE_SRC_INPUT_CHANGE  BIT(5)
> > > > +#define ADO_TYPE_OVP   BIT(6)
> > > > +
> > > > +static inline unsigned int ado_type(u32 ado)
> > > > +{
> > > > +   return (ado >> ADO_TYPE_SHIFT) & ADO_TYPE_MASK;
> > > > +}
> > >
> > > usb_ prefix for this and the other inline functions as well?
> >
> > Same comment here.
>
> But it would make more sense, right?

I'm happy with that. Actually I'd probably opt for 'usb_pd_' if I was going that
route as it's PD specific information. Would that be reasonable?

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

[Adam Thomson]

On 01 November 2017 17:20, Greg Kroah-Hartman wrote:

> On Wed, Nov 01, 2017 at 05:03:10PM +0000, Adam Thomson wrote:
> > 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 <adam.thomson.opensou...@diasemi.com>
> > ---
> >  include/linux/usb/pd_ado.h | 49
> ++
> >  1 file changed, 49 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..edcbcfa
> > --- /dev/null
> > +++ b/include/linux/usb/pd_ado.h
> > @@ -0,0 +1,49 @@
> > +/*
> > + * Copyright (c) 2017 Dialog Semiconductor
> > + *
> > + * Author: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
>
> I have to ask, do you _really_ mean "any later version"?

Many thanks for the prompt comments.

So this is the same copyright header applied for the other PD related code
(bit of a copy and paste to follow existing tcpm practice), and have tended to
use this header for other driver development as well. Within the context of the
Linux kernel I believe this should be fine and will resolve to GPLv2, and should
someone use the code elsewhere then they can choose a later GPL license, not
that I suspect many would. Do you see any problems here as am happy to be
corrected? :)

>
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __LINUX_USB_PD_ADO_H
> > +#define __LINUX_USB_PD_ADO_H
> > +
> > +/* ADO : Alert Data Object */
> > +#define ADO_TYPE_SHIFT 24
> > +#define ADO_TYPE_MASK  0xff
> > +#define ADO_FIXED_BATT_SHIFT   20
> > +#define ADO_FIXED_BATT_MASK0xf
> > +#define ADO_HOT_SWAP_BATT_SHIFT16
> > +#define ADO_HOT_SWAP_BATT_MASK 0xf
>
> USB_ prefixes perhaps?

Again here I was following the existing TCPM approach, but if it's a problem
then I can update this.

>
> > +
> > +#define ADO_TYPE_BATT_STATUS_CHANGEBIT(1)
> > +#define ADO_TYPE_OCP   BIT(2)
> > +#define ADO_TYPE_OTP   BIT(3)
> > +#define ADO_TYPE_OP_COND_CHANGEBIT(4)
> > +#define ADO_TYPE_SRC_INPUT_CHANGE  BIT(5)
> > +#define ADO_TYPE_OVP   BIT(6)
> > +
> > +static inline unsigned int ado_type(u32 ado)
> > +{
> > +   return (ado >> ADO_TYPE_SHIFT) & ADO_TYPE_MASK;
> > +}
>
> usb_ prefix for this and the other inline functions as well?

Same comment here.

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

[Adam Thomson]

On 01 November 2017 17:21, Greg Kroah-Hartman wrote:

> On Wed, Nov 01, 2017 at 05:03:11PM +0000, Adam Thomson wrote:
> > 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 <adam.thomson.opensou...@diasemi.com>
> > ---
> >  include/linux/usb/pd_ext_sdb.h | 40
> 
> >  1 file changed, 40 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..6d6da31
> > --- /dev/null
> > +++ b/include/linux/usb/pd_ext_sdb.h
> > @@ -0,0 +1,40 @@
> > +/*
> > + * Copyright (c) 2017 Dialog Semiconductor
> > + *
> > + * Author: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
>
> Same license question here.
>
>
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __LINUX_USB_PD_EXT_SDB_H
> > +#define __LINUX_USB_PD_EXT_SDB_H
>
> No need for __LINUX_ right?

As for patch 2, was following existing TCPM code but can remove the LINUX part
if that's preferred.

[RFC PATCH 5/7] power: supply: Add type for USB PD PPS chargers

[Adam Thomson]

This adds a type to represent USB PPS chargers as defined in the
USB Power Delivery Specification Revision 3.0 V1.1

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 drivers/power/supply/power_supply_sysfs.c | 2 +-
 include/linux/power_supply.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..efd2469 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -43,7 +43,7 @@
 static const char * const power_supply_type_text[] = {
"Unknown", "Battery", "UPS", "Mains", "USB",
"USB_DCP", "USB_CDP", "USB_ACA", "USB_C",
-   "USB_PD", "USB_PD_DRP", "BrickID"
+   "USB_PD", "USB_PD_DRP", "USB_PD_PPS", "BrickID"
 };
 
 static const char * const power_supply_status_text[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 79e90b3..3a79c75 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -167,6 +167,7 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB_TYPE_C,   /* Type C Port */
POWER_SUPPLY_TYPE_USB_PD,   /* Power Delivery Port */
POWER_SUPPLY_TYPE_USB_PD_DRP,   /* PD Dual Role Port */
+   POWER_SUPPLY_TYPE_USB_PD_PPS,   /* PD Programmable Power Supply 
*/
POWER_SUPPLY_TYPE_APPLE_BRICK_ID,   /* Apple Charging Method */
 };
 
-- 
1.9.1

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 include/linux/usb/pd_ado.h | 49 ++
 1 file changed, 49 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..edcbcfa
--- /dev/null
+++ b/include/linux/usb/pd_ado.h
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2017 Dialog Semiconductor
+ *
+ * Author: Adam Thomson <adam.thomson.opensou...@diasemi.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __LINUX_USB_PD_ADO_H
+#define __LINUX_USB_PD_ADO_H
+
+/* ADO : Alert Data Object */
+#define ADO_TYPE_SHIFT 24
+#define ADO_TYPE_MASK  0xff
+#define ADO_FIXED_BATT_SHIFT   20
+#define ADO_FIXED_BATT_MASK0xf
+#define ADO_HOT_SWAP_BATT_SHIFT16
+#define ADO_HOT_SWAP_BATT_MASK 0xf
+
+#define ADO_TYPE_BATT_STATUS_CHANGEBIT(1)
+#define ADO_TYPE_OCP   BIT(2)
+#define ADO_TYPE_OTP   BIT(3)
+#define ADO_TYPE_OP_COND_CHANGEBIT(4)
+#define ADO_TYPE_SRC_INPUT_CHANGE  BIT(5)
+#define ADO_TYPE_OVP   BIT(6)
+
+static inline unsigned int ado_type(u32 ado)
+{
+   return (ado >> ADO_TYPE_SHIFT) & ADO_TYPE_MASK;
+}
+
+static inline unsigned int ado_fixed_batt(u32 ado)
+{
+   return (ado >> ADO_FIXED_BATT_SHIFT) & ADO_FIXED_BATT_MASK;
+}
+
+static inline unsigned int ado_hot_swap_batt(u32 ado)
+{
+   return (ado >> ADO_HOT_SWAP_BATT_SHIFT) & ADO_HOT_SWAP_BATT_MASK;
+}
+#endif /* __LINUX_USB_PD_ADO_H */
-- 
1.9.1

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

[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.

So with all of that covered, please feel free to rip this apart as you see fit.

Note: Code changes are based on linux-next tag 'next-20171017' to pick up
the move out of staging of TCPM related code.

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 type for USB PD PPS chargers
  typec: tcpm: Represent source supply through power_supply class
  typec: tcpm: Add support for sink PPS related messages

 drivers/power/supply/power_supply_sysfs.c |   2 +-
 drivers/usb/typec/Kconfig |   1 +
 drivers/usb/typec/fusb302/Kconfig |   2 +-
 drivers/usb/typec/fusb302/fusb302.c   |  63 +--
 drivers/usb/typec/tcpm.c  | 816 +-
 include/linux/power_supply.h  |   1 +
 include/linux/usb/pd.h| 162 +-
 include/linux/usb/pd_ado.h|  49 ++
 include/linux/usb/pd_ext_sdb.h|  40 ++
 include/linux/usb/tcpm.h  |   2 +-
 10 files changed, 1041 insertions(+), 97 deletions(-)
 create mode 100644 include/linux/usb/pd_ado.h
 create mode 100644 include/linux/usb/pd_ext_sdb.h

-- 
1.9.1

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 include/linux/usb/pd.h | 162 +
 1 file changed, 151 insertions(+), 11 deletions(-)

diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index e00051c..77c6cd6 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,38 @@ 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_HEADER_EXT_HDR  BIT(15)
 #define PD_HEADER_CNT_SHIFT12
 #define PD_HEADER_CNT_MASK 0x7
 #define PD_HEADER_ID_SHIFT 9
@@ -59,18 +91,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, 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) |\
+(PD_REV30 << 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), (id), (cnt), (0)))
 
 static inline unsigned int pd_header_cnt(u16 header)
 {
@@ -102,16 +135,66 @@ static inline unsigned int pd_header_msgid_le(__le16 
header)
return pd_header_msgid(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)
+{
+   return pd_ext_header_data_size(le16_to_cpu(ext_header));
+}
+
 #define PD_MAX_PAYLOAD 7
+#define PD_EXT_MAX_LEGACY_DATA 26
+#define PD_EXT_MAX_CHUNK_DATA  26
+#define PD_EXT_MAX_DA

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 include/linux/usb/pd_ext_sdb.h | 40 
 1 file changed, 40 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..6d6da31
--- /dev/null
+++ b/include/linux/usb/pd_ext_sdb.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2017 Dialog Semiconductor
+ *
+ * Author: Adam Thomson <adam.thomson.opensou...@diasemi.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __LINUX_USB_PD_EXT_SDB_H
+#define __LINUX_USB_PD_EXT_SDB_H
+
+/* SDB : Status Data Block */
+enum pd_ext_sdb_fields {
+   EXT_SDB_INTERNAL_TEMP = 0,
+   EXT_SDB_PRESENT_INPUT,
+   EXT_SDB_PRESENT_BATT_INPUT,
+   EXT_SDB_EVENT_FLAGS,
+   EXT_SDB_TEMP_STATUS,
+   EXT_SDB_DATA_SIZE,
+};
+
+/* Event Flags */
+#define EXT_SDB_EVENT_OCP  BIT(1)
+#define EXT_SDB_EVENT_OTP  BIT(2)
+#define EXT_SDB_EVENT_OVP  BIT(3)
+#define EXT_SDB_EVENT_CF_CV_MODE   BIT(4)
+
+#define EXT_SDB_PPS_EVENTS (EXT_SDB_EVENT_OCP |\
+EXT_SDB_EVENT_OTP |\
+EXT_SDB_EVENT_OVP)
+
+#endif /* __LINUX_USB_PD_EXT_SDB_H */
-- 
1.9.1

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/Kconfig   |   1 +
 drivers/usb/typec/fusb302/Kconfig   |   2 +-
 drivers/usb/typec/fusb302/fusb302.c |  63 +-
 drivers/usb/typec/tcpm.c| 225 +++-
 4 files changed, 228 insertions(+), 63 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 465d7da..b9cd806 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -8,6 +8,7 @@ config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
select TYPEC
+   select POWER_SUPPLY
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
 config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C && POWER_SUPPLY
+   depends on I2C
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/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index e790b67..8e68cb2 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -109,11 +108,6 @@ 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;
@@ -882,13 +876,11 @@ 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);
@@ -904,11 +896,6 @@ 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;
 }
 
@@ -1694,43 +1681,6 @@ 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,
-};
-
-static 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

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/tcpm.c | 441 +--
 include/linux/usb/tcpm.h |   2 +-
 2 files changed, 429 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 8483d3e..c4045cc 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -56,6 +56,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),   \
@@ -175,6 +176,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
 };
 
+struct pd_pps_data {
+   u16 min_volt;
+   u16 max_volt;
+   u16 max_curr;
+   u16 out_volt;
+   u16 op_curr;
+   bool supported;
+   bool active;
+};
+
 struct tcpm_port {
struct device *dev;
 
@@ -268,6 +279,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;
@@ -284,8 +296,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];
@@ -503,6 +520,13 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_apdo_min_voltage(pdo),
+ pdo_apdo_max_voltage(pdo),
+ pdo_apdo_max_current(pdo));
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -1259,6 +1283,10 @@ static void vdm_state_machine_work(struct work_struct 
*work)
 /*
  * PD (data, control) command handling functions
  */
+
+static int tcpm_pd_send_control(struct tcpm_port *port,
+   enum pd_ctrl_msg_type type);
+
 static void tcpm_pd_data_request(struct tcpm_port *port,
 const struct pd_message *msg)
 {
@@ -1323,6 +1351,15 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
}
 }
 
+static void tcpm_pps_complete(struct tcpm_port *port, int result)
+{
+   if (port->pps_pending) {
+   port->pps_status = result;
+   port->pps_pending = false;
+   complete(>pps_complete);
+   }
+}
+
 static void tcpm_pd_ctrl_request(struct tcpm_port *port,
 const struct pd_message *msg)
 {
@@ -1399,6 +1436,11 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
next_state = SNK_WAIT_CAPABILITIES;
tcpm_set_state(port, next_state, 0);
break;
+   case SNK_NEGOTIATE_PPS_CAPABILITIES:
+   port->pps_status = (type == PD_CTRL_WAIT ?
+   -EAGAIN : -EOPNOTSUPP);
+   tcpm_set_state(port, SNK_READY, 0);
+   break;
case DR_SWAP_SEND:
port->swap_status = (type == PD_CTRL_WAIT ?
 -EAGAIN : -EOPNOTSUPP);
@@ -1421,6 +1463,13 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
case PD_CTRL_ACCEPT:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
+   port->pps_data.active = false;
+   tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
+   break;
+   case SNK_NEGOTIATE_PPS_CAPABILITIES:
+   port->pps_data.active = true;
+   port->pps_data.out_volt = port->supply_voltage;
+   port->pps_data.op_curr = port->current_limit;
  

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

[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 <adam.thomson.opensou...@diasemi.com>
---
 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 bf3c93a..d12304e 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -28,7 +28,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -122,6 +124,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)
@@ -152,6 +159,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,
 };
@@ -1288,10 +1296,42 @@ static void vdm_state_machine_work(struct work_struct 
*work)
 /*
  * 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 = ado_type(p0);
+
+   if (!type) {
+   tcpm_log(port, "Alert message received with no type");
+   return;
+   }
+
+   /* Just handling non-battery alerts for now */
+   if (!(type & 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)
 {
@@ -1350,6 +1390,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:
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   /* Currently unsupported */
+   break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1432,6 +1480,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 */
@@ -1548,12 +1597,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");
+   

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

[Adam Thomson]

On 01 November 2017 20:09, Jack Pham wrote:

> Hi Adam,
>
> On Wed, Nov 01, 2017 at 05:03:09PM +0000, Adam Thomson wrote:
> > This commit adds definitions for PD Rev 3.0 messages, including
> > APDO PPS and extended message support for TCPM.
> >
> > Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> > ---
> >  include/linux/usb/pd.h | 162
> +
> >  1 file changed, 151 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
> > index e00051c..77c6cd6 100644
> > --- a/include/linux/usb/pd.h
> > +++ b/include/linux/usb/pd.h
>
> 
>
> >  #define PD_REV10   0x0
> >  #define PD_REV20   0x1
> > +#define PD_REV30   0x2
> >
> > +#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 +91,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, 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) |\
> > +(PD_REV30 << PD_HEADER_REV_SHIFT) |\
>
> You are making a hardcoded change for the Spec Rev field of every
> outgoing message to be 3.0. However, this needs to be flexible in order
> to support backwards compatibility when communicating with a 2.0 peer.
> The revision "negotiation" would need to be done at the time the first
> Request is sent such that both source & sink settle on the highest
> supported revision of both. (PD 3.0 spec section 6.2.1.1.5)

Thanks for the prompt comments. Much appreciated.

This is a fair point. The existing code was hard coded to Rev 2.0 but this
should really be based on capabilities of both sides, if we're truly following
the spec. Will take a look at this and try to address the problem.

>
> >  (((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), (id), (cnt), (0)))
> >
> >  static inline unsigned int pd_header_cnt(u16 header)
> >  {
> > @@ -102,16 +135,66 @@ static inline unsigned int pd_header_msgid_le(__le16
> header)
> > return pd_header_msgid(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_

RE: [RFC PATCH 5/7] power: supply: Add type for USB PD PPS chargers

[Adam Thomson]

On 06 November 2017 13:26, Sebastian Reichel wrote:

> Hi,
> 
> On Wed, Nov 01, 2017 at 05:03:13PM +0000, Adam Thomson wrote:
> > This adds a type to represent USB PPS chargers as defined in the
> > USB Power Delivery Specification Revision 3.0 V1.1
> >
> > Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> 
> Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
> 
> -- Sebastian
> 

Thanks for reviewing

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

[Adam Borowski]

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
> 
> if (!refcount_inc_not_zero(>maps)) {
> ...
> refcount_inc(>maps);
> }
> 
> i.e., it calls refcount_inc() to increment the refcount when it is known
> to be zero, which is explicitly forbidden by the API. Instead, use
> refcount_set() to set it to 1.
> 
> Signed-off-by: Ard Biesheuvel 
> ---

Awesome!  Works for me.

> Apologies if this was already found and fixed. I don't usually follow
> the DRM or nouveau mailing lists.

I see nothing relevant in dri-devel and nouveau archives, except my
complaint (GTX 560 Ti (GF114)):
https://lists.freedesktop.org/archives/nouveau/2017-December/029264.html
and Richard Narron seconding it (MSI GeForce 210):
https://lists.freedesktop.org/archives/nouveau/2017-December/029276.html

>  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> index 1ba7289684aa..db48a1daca0c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
>   iobj->base.memory.ptrs = _instobj_fast;
>   else
>   iobj->base.memory.ptrs = _instobj_slow;
> - refcount_inc(>maps);
> + refcount_set(>maps, 1);
>   }
>  
>   mutex_unlock(>subdev.mutex);
> -- 

I'm just a dumb user here, my tags don't carry a weight, but Tested-by:.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

[PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes

[Adam Ford]

Many node labels in the device tree (like serial0, serial1, etc) are being
redefined, so let's modernize the device tree by using phandles to
extend the existing nodes.  This helps reduce the whitespace.

Signed-off-by: Adam Ford <aford...@gmail.com>
---
V3:  Rebase against 4.18/dt and fix subject.

V2: Rename subject per feedback from Sekhar.
Extend notes from tps6507x
Add empty line after each node

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 339cae353302..3c486d8675b8 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,143 +27,6 @@
spi0 = 
};
 
-   soc@1c0 {
-   pmx_core: pinmux@14120 {
-   status = "okay";
-
-   mcasp0_pins: pinmux_mcasp0_pins {
-   pinctrl-single,bits = <
-   /*
-* AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
-* AFSR, AMUTE
-*/
-   0x00 0x 0x
-   /* AXR11, AXR12 */
-   0x04 0x00011000 0x000ff000
-   >;
-   };
-   nand_pins: nand_pins {
-   pinctrl-single,bits = <
-   /* EMA_WAIT[0], EMA_OE, EMA_WE, 
EMA_CS[4], EMA_CS[3] */
-   0x1c 0x10110110  0xf0ff0ff0
-   /*
-* EMA_D[0], EMA_D[1], EMA_D[2],
-* EMA_D[3], EMA_D[4], EMA_D[5],
-* EMA_D[6], EMA_D[7]
-*/
-   0x24 0x  0x
-   /* EMA_A[1], EMA_A[2] */
-   0x30 0x0110  0x0ff0
-   >;
-   };
-   };
-   serial0: serial@42000 {
-   status = "okay";
-   };
-   serial1: serial@10c000 {
-   status = "okay";
-   };
-   serial2: serial@10d000 {
-   status = "okay";
-   };
-   rtc0: rtc@23000 {
-   status = "okay";
-   };
-   i2c0: i2c@22000 {
-   status = "okay";
-   clock-frequency = <10>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-
-   tps: tps@48 {
-   reg = <0x48>;
-   };
-   tlv320aic3106: tlv320aic3106@18 {
-   #sound-dai-cells = <0>;
-   compatible = "ti,tlv320aic3106";
-   reg = <0x18>;
-   status = "okay";
-
-   /* Regulators */
-   IOVDD-supply = <_reg>;
-   /* Derived from VBAT: Baseboard 3.3V / 1.8V */
-   AVDD-supply = <>;
-   DRVDD-supply = <>;
-   DVDD-supply = <>;
-   };
-   tca6416: gpio@20 {
-   compatible = "ti,tca6416";
-   reg = <0x20>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-   };
-   wdt: wdt@21000 {
-   status = "okay";
-   };
-   mmc0: mmc@4 {
-   max-frequency = <5000>;
-   bus-width = <4>;
-   status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   };
-   spi1: spi@30e000 {
-   status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins _cs0_pin>;
-   flash: m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "m25p64";
-   spi-max-frequency =

RE: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

[Adam Thomson]

On 03 May 2018 08:59, Akshu Agrawal wrote:

> Non-dts based systems can use ACPI DSDT to pass on the mclk
> to da7219.
> This enables da7219 mclk to be linked to system clock.
> Enable/Disable of the mclk is already handled in the codec so
> platform drivers don't have to explicitly do handling of mclk.
> 
> Signed-off-by: Akshu Agrawal 
> ---
> v2: Fixed kbuild error
> v3: Add corresponding clk_put for clk_get
>  include/sound/da7219.h|  2 ++
>  sound/soc/codecs/da7219.c | 10 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/sound/da7219.h b/include/sound/da7219.h
> index 1bfcb16..df7ddf4 100644
> --- a/include/sound/da7219.h
> +++ b/include/sound/da7219.h
> @@ -38,6 +38,8 @@ struct da7219_pdata {
> 
>   const char *dai_clks_name;
> 
> + const char *mclk_name;
> +
>   /* Mic */
>   enum da7219_micbias_voltage micbias_lvl;
>   enum da7219_mic_amp_in_sel mic_amp_in_sel;
> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
> index 980a6a8..ecd46fc 100644
> --- a/sound/soc/codecs/da7219.c
> +++ b/sound/soc/codecs/da7219.c
> @@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct
> snd_soc_component *compone
>   dev_warn(dev, "Using default clk name: %s\n",
>pdata->dai_clks_name);
> 
> + device_property_read_string(dev, "dlg,mclk-name", >mclk_name);
> +

Personally am still not keen on this. To me the use of a device_property_*
function suggests the same property resides in both DT and ACPI, but here we're
only using this for the ACPI case. DT has no want or need for this. I still feel
we should look at something more generic in the clock framework, although I do
agree with Mark that this should be properly specced.

>   if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) >= 0)
>   pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, of_val32);
>   else
> @@ -1905,7 +1907,10 @@ static int da7219_probe(struct snd_soc_component
> *component)
>   da7219_handle_pdata(component);
> 
>   /* Check if MCLK provided */
> - da7219->mclk = devm_clk_get(component->dev, "mclk");
> + if (da7219->pdata->mclk_name)
> + da7219->mclk = clk_get(NULL, da7219->pdata->mclk_name);
> + if (!da7219->mclk)
> + da7219->mclk = devm_clk_get(component->dev, "mclk");
>   if (IS_ERR(da7219->mclk)) {
>   if (PTR_ERR(da7219->mclk) != -ENOENT) {
>   ret = PTR_ERR(da7219->mclk);
> @@ -1971,6 +1976,9 @@ static void da7219_remove(struct snd_soc_component
> *component)
>   clkdev_drop(da7219->dai_clks_lookup);
>  #endif
> 
> + if (da7219->pdata->mclk_name)
> + clk_put(da7219->mclk);
> +
>   /* Supplies */
>   regulator_bulk_disable(DA7219_NUM_SUPPLIES, da7219->supplies);
>  }
> --
> 1.9.1

Re: [PATCH] scsi: 3w-9xxx: fix a missing-check bug

[adam radford]

On Sat, May 5, 2018 at 8:43 PM, Wenwen Wang <wang6...@umn.edu> wrote:
> In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the
> userspace pointer 'argp' and saved to the kernel object 'driver_command'.
> Then a security check is performed on the data buffer size indicated by
> 'driver_command', which is 'driver_command.buffer_length'. If the security
> check is passed, the entire ioctl command is copied again from the 'argp'
> pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
> are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
> pointer resides in userspace, a malicious userspace process can race to
> change the buffer size between the two copies. This way, the user can
> bypass the security check and inject invalid data buffer size. This can
> cause potential security issues in the following execution.
>
> This patch checks the buffer size obtained in the second copy. An error
> code -EINVAL will be returned if it is not same as the original one in the
> first copy.
>
> Signed-off-by: Wenwen Wang <wang6...@umn.edu>
> ---
>  drivers/scsi/3w-9xxx.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index b42c9c4..8bc43db 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -684,6 +684,12 @@ static long twa_chrdev_ioctl(struct file *file, unsigned 
> int cmd, unsigned long
> if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
> sizeof(TW_Ioctl_Buf_Apache) - 1))
> goto out3;
>
> +   if (tw_ioctl->driver_command.buffer_length
> +!= driver_command.buffer_length) {
> +   retval = TW_IOCTL_ERROR_OS_EINVAL;
> +   goto out3;
> +   }
> +
> /* See which ioctl we are doing */
> switch (cmd) {
> case TW_IOCTL_FIRMWARE_PASS_THROUGH:
> --
> 2.7.4
>

Drop this patch and create a new one that checks for:  if
!capable(CAP_SYS_ADMIN) in twa_chrdev_ioctl() (like 3w-sas.c does) and
I'll ack it.

-Adam

Re: [PATCH] scsi: 3ware: fix a missing-check bug

[adam radford]

On Sat, May 5, 2018 at 10:50 PM, Wenwen Wang <wang6...@umn.edu> wrote:
> In twl_chrdev_ioctl(), the ioctl driver command is firstly copied from the
> userspace pointer 'argp' and saved to the kernel object 'driver_command'.
> Then a security check is performed on the data buffer size indicated by
> 'driver_command', which is 'driver_command.buffer_length'. If the security
> check is passed, the entire ioctl command is copied again from the 'argp'
> pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
> are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
> pointer resides in userspace, a malicious userspace process can race to
> change the buffer size between the two copies. This way, the user can
> bypass the security check and inject invalid data buffer size. This can
> cause potential security issues in the following execution.
>
> This patch checks the buffer size obtained in the second copy. An error
> code -EINVAL will be returned if it is not same as the original one in the
> first copy.
>
> Signed-off-by: Wenwen Wang <wang6...@umn.edu>
> ---
>  drivers/scsi/3w-sas.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index cf9f2a0..ea41969 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -757,6 +757,11 @@ static long twl_chrdev_ioctl(struct file *file, unsigned 
> int cmd, unsigned long
> /* Now copy down the entire ioctl */
> if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
> sizeof(TW_Ioctl_Buf_Apache) - 1))
> goto out3;
> +   if (tw_ioctl->driver_command.buffer_length !=
> +   driver_command.buffer_length) {
> +   retval = -EINVAL;
> +   goto out3;
> +   }
>
> /* See which ioctl we are doing */
> switch (cmd) {
> --
> 2.7.4
>

1. Returning -EINVAL after the copy_from_user() doesn't prevent any
invalid copy down to kernel mode from happening.
2. twl_chrdev_open() checks for capable(CAP_SYS_ADMIN):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/3w-sas.c#n834

I don't see the point in this patch.

-Adam

Re: [PATCH] scsi: 3w-xxxx: fix a missing-check bug

[adam radford]

On Sat, May 5, 2018 at 10:48 PM, Wenwen Wang <wang6...@umn.edu> wrote:
> In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from
> the userspace pointer 'argp' and saved to the kernel object
> 'data_buffer_length'. Then a security check is performed on it to make sure
> that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise,
> an error code -EINVAL is returned. If the security check is passed, the
> entire ioctl command is copied again from the 'argp' pointer and saved to
> the kernel object 'tw_ioctl'. Then, various operations are performed on
> 'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer resides in
> userspace, a malicious userspace process can race to change the buffer
> length between the two copies. This way, the user can bypass the security
> check and inject invalid data buffer length. This can cause potential
> security issues in the following execution.
>
> This patch checks the buffer length obtained in the second copy. An error
> code -EINVAL will be returned if it is not same as the original one in the
> first copy.
>
> Signed-off-by: Wenwen Wang <wang6...@umn.edu>
> ---
>  drivers/scsi/3w-.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
> index 33261b6..ef79194 100644
> --- a/drivers/scsi/3w-.c
> +++ b/drivers/scsi/3w-.c
> @@ -919,6 +919,10 @@ static long tw_chrdev_ioctl(struct file *file, unsigned 
> int cmd, unsigned long a
> /* Now copy down the entire ioctl */
> if (copy_from_user(tw_ioctl, argp, data_buffer_length + 
> sizeof(TW_New_Ioctl) - 1))
> goto out2;
> +   if (tw_ioctl->data_buffer_length != data_buffer_length) {
> +   retval = -EINVAL;
> +   goto out2;
> +   }
>
> passthru = (TW_Passthru *)_ioctl->firmware_command;
>
> --
> 2.7.4
>

I would drop this patch and check for !capable(CAP_SYS_ADMIN) in
tw_chrdev_open() instead.

-Adam

Re: [PATCH v2] scsi: 3w-9xxx: fix a missing-check bug

[adam radford]

On Mon, May 7, 2018 at 5:46 PM, Wenwen Wang <wang6...@umn.edu> wrote:
> In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the
> userspace pointer 'argp' and saved to the kernel object 'driver_command'.
> Then a security check is performed on the data buffer size indicated by
> 'driver_command', which is 'driver_command.buffer_length'. If the security
> check is passed, the entire ioctl command is copied again from the 'argp'
> pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
> are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
> pointer resides in userspace, a malicious userspace process can race to
> change the buffer size between the two copies. This way, the user can
> bypass the security check and inject invalid data buffer size. This can
> cause potential security issues in the following execution.
>
> This patch checks for capable(CAP_SYS_ADMIN) in twa_chrdev_open()t o avoid
> the above issues.
>
> Signed-off-by: Wenwen Wang <wang6...@umn.edu>
> ---
>  drivers/scsi/3w-9xxx.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index b42c9c4..99ba4a7 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -882,6 +882,11 @@ static int twa_chrdev_open(struct inode *inode, struct 
> file *file)
> unsigned int minor_number;
> int retval = TW_IOCTL_ERROR_OS_ENODEV;
>
> +   if (!capable(CAP_SYS_ADMIN)) {
> +   retval = -EACCES;
> +   goto out;
> +   }
> +
> minor_number = iminor(inode);
> if (minor_number >= twa_device_extension_count)
> goto out;
> --
> 2.7.4
>

Acked-by: Adam Radford <aradf...@gmail.com>

Re: [PATCH v2] scsi: 3w-xxxx: fix a missing-check bug

[adam radford]

On Mon, May 7, 2018 at 5:54 PM, Wenwen Wang <wang6...@umn.edu> wrote:
> In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from
> the userspace pointer 'argp' and saved to the kernel object
> 'data_buffer_length'. Then a security check is performed on it to make sure
> that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise,
> an error code -EINVAL is returned. If the security check is passed, the
> entire ioctl command is copied again from the 'argp' pointer and saved to
> the kernel object 'tw_ioctl'. Then, various operations are performed on
> 'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer resides in
> userspace, a malicious userspace process can race to change the buffer
> length between the two copies. This way, the user can bypass the security
> check and inject invalid data buffer length. This can cause potential
> security issues in the following execution.
>
> This patch checks for capable(CAP_SYS_ADMIN) in tw_chrdev_open() to avoid
> the above issues.
>
> Signed-off-by: Wenwen Wang <wang6...@umn.edu>
> ---
>  drivers/scsi/3w-.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
> index 33261b6..f6179e3 100644
> --- a/drivers/scsi/3w-.c
> +++ b/drivers/scsi/3w-.c
> @@ -1033,6 +1033,9 @@ static int tw_chrdev_open(struct inode *inode, struct 
> file *file)
>
> dprintk(KERN_WARNING "3w-: tw_ioctl_open()\n");
>
> +   if (!capable(CAP_SYS_ADMIN))
> +   return -EACCES;
> +
> minor_number = iminor(inode);
> if (minor_number >= tw_device_extension_count)
> return -ENODEV;
> --
> 2.7.4
>

Acked-by: Adam Radford <aradf...@gmail.com>

Re: [PATCH v3 2/3] fs: Convert kiocb rw_hint from enum to u16

[Adam Manzanares]

On 5/9/18 11:21 AM, Theodore Y. Ts'o wrote:
> On Wed, May 09, 2018 at 08:23:00AM -0600, Jens Axboe wrote:
>> Streams is essentially the only thing ki_hint is currently used for,
>> with the write life time hints mapping to a stream. The idea for the
>> user side API was to have other things than just write life time hints.
>>
>> Since Adam wants to do priorities, he'd either need to pack into the
>> existing ki_hint, or do this patch does, which is make it smaller and
>> add a new member. I think the latter is cleaner.
> 
> Fair enough; but maybe we can use a u8 instead of a u16?  65,535
> priorities still seem like way more than would ever make sense.  I
> think 256 priorities is still way to many, but it's simpler while
> still reserving number of bits for future se.

The intention was to mimic the ioprio_set system call, which uses 3 bits 
for a prio class and 13 bits for a prio_value.

IDK what is the right amount of bits to use, but the existing use of 
bits seemed flexible enough to support many types of applications and 
devices.
> 
>  - Ted
> 

Re: [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes

[Adam Ford]

On Thu, May 10, 2018 at 10:19 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Thursday 10 May 2018 08:38 PM, Adam Ford wrote:
>> On Thu, May 10, 2018 at 4:10 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>> On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
>>>> Many node labels in the device tree (like serial0, serial1, etc) are being
>>>> redefined, so let's modernize the device tree by using phandles to
>>>> extend the existing nodes.  This helps reduce the whitespace.
>>>>
>>>> Signed-off-by: Adam Ford <aford...@gmail.com>
>>>
>>> I applied this without the pmic changes. I am not convinced about those.
>>> The tps node is already being referred to as phandle. I am not sure
>>> referring to each individual regulator using phandle is needed. Other
>>> files like am335x-evm.dts don't do it as well.
>>
>> I tested the regulator values and names after booting to see if the
>> names and values matched the expected values. They did, so I am
>> fairly confident it would have worked.
>
> Not doubting that. But I am not sure if thats the "norm". Do you see any
> other device-tree file doing this?

The omap3 boards do this.  For example, the beagle-xm board includes
the twl4030 files

#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"

These files setup the PMIC regulators, but the beagle-xm modifies the
PMIC settings phandles.

 {
regulator-name = "usb_1v8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
};

I was trying to mimic this behavior when I did it for the da850-evm,
however, it seems like a moot point we merge the
 tp6507x.dtsi contents into the da850-evm.dts.

>
>>
>>>
>>> Another thing is whether we really need the tp6507x.dtsi file. It does
>>> not seem to contain much and also da850-evm.dts is the only file
>>> including it. So it seems pretty pointless to me.
>>
>> Do you want me to do a patch that removes the  tp6507x.dtsi file and
>> just sets up the
>> PMIC from scratch within the da850-evm file?
>
> I am fine with the plan, but not something urgent, IMO.

I'm going to try and revisit the LCD again first, but I'll try to do
them both this weekend if I can get some time.

>
>>
>>>
>>> Here is what I committed.
>>
>> Thank you.  I think looks cleaner this way, and more consistent with
>> many of the other platforms and boards.
>
> Yes.
>
> Thanks,
> Sekhar

Thank you,

adam

Re: [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes

[Adam Ford]

On Thu, May 10, 2018 at 4:10 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
>> Many node labels in the device tree (like serial0, serial1, etc) are being
>> redefined, so let's modernize the device tree by using phandles to
>> extend the existing nodes.  This helps reduce the whitespace.
>>
>> Signed-off-by: Adam Ford <aford...@gmail.com>
>
> I applied this without the pmic changes. I am not convinced about those.
> The tps node is already being referred to as phandle. I am not sure
> referring to each individual regulator using phandle is needed. Other
> files like am335x-evm.dts don't do it as well.

I tested the regulator values and names after booting to see if the
names and values matched the expected values. They did, so I am
fairly confident it would have worked.

>
> Another thing is whether we really need the tp6507x.dtsi file. It does
> not seem to contain much and also da850-evm.dts is the only file
> including it. So it seems pretty pointless to me.

Do you want me to do a patch that removes the  tp6507x.dtsi file and
just sets up the
PMIC from scratch within the da850-evm file?

>
> Here is what I committed.

Thank you.  I think looks cleaner this way, and more consistent with
many of the other platforms and boards.

adam
>
> Thanks,
> Sekhar
>
> ---8<---
> commit ae62a32d6019a8225e2c32e631b8b0d039151131 (refs/heads/v4.18/dt)
> Author: Adam Ford <aford...@gmail.com>
> AuthorDate: Mon May 7 07:37:21 2018 -0500
> Commit: Sekhar Nori <nsek...@ti.com>
> CommitDate: Thu May 10 14:01:15 2018 +0530
>
> ARM: dts: da850-evm: use phandles to extend nodes
>
> Many node labels in the device tree (like serial0, serial1, etc) are being
> redefined, so let's modernize the device tree by using phandles to
> extend the existing nodes.  This helps reduce the whitespace.
>
> Signed-off-by: Adam Ford <aford...@gmail.com>
> [nsek...@ti.com: drop tps6507x related changes]
> Signed-off-by: Sekhar Nori <nsek...@ti.com>
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 339cae353302..9389f95f4094 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -27,143 +27,6 @@
> spi0 = 
> };
>
> -   soc@1c0 {
> -   pmx_core: pinmux@14120 {
> -   status = "okay";
> -
> -   mcasp0_pins: pinmux_mcasp0_pins {
> -   pinctrl-single,bits = <
> -   /*
> -* AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
> -* AFSR, AMUTE
> -*/
> -   0x00 0x 0x
> -   /* AXR11, AXR12 */
> -   0x04 0x00011000 0x000ff000
> -   >;
> -   };
> -   nand_pins: nand_pins {
> -   pinctrl-single,bits = <
> -   /* EMA_WAIT[0], EMA_OE, EMA_WE, 
> EMA_CS[4], EMA_CS[3] */
> -   0x1c 0x10110110  0xf0ff0ff0
> -   /*
> -* EMA_D[0], EMA_D[1], EMA_D[2],
> -* EMA_D[3], EMA_D[4], EMA_D[5],
> -* EMA_D[6], EMA_D[7]
> -*/
> -   0x24 0x  0x
> -   /* EMA_A[1], EMA_A[2] */
> -   0x30 0x0110  0x0ff0
> -   >;
> -   };
> -   };
> -   serial0: serial@42000 {
> -   status = "okay";
> -   };
> -   serial1: serial@10c000 {
> -   status = "okay";
> -   };
> -   serial2: serial@10d000 {
> -   status = "okay";
> -   };
> -   rtc0: rtc@23000 {
> -   status = "okay";
> -   };
> -   i2c0: i2c@22000 {
> -   status = "okay";
> -   clock-frequency = <10>;
> -   pinctrl-names = "default";
> -  

Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework​

[Adam Ford]

On Wed, May 9, 2018 at 12:25 PM, David Lechner <da...@lechnology.com> wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final four patches add device tree clock support to the one SoC that
> supports it.
>
> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
> board file).
>

I am not sure if I did something wrong, but I attempted to build and I
wasn't able to boot the da850-evm.dtb your repo common-clk-v11,
however the legacy board file boot was OK.

make davinci_all_defconfig ARCH=arm
make zImage modules da850-evm.dtb ARCH=arm CROSS_COMPILE=arm-linux- -j8

3140416 bytes read in 1464 ms (2 MiB/s)
20353 bytes read in 15 ms (1.3 MiB/s)
## Flattened Device Tree blob at c060
   Booting using the fdt blob at 0xc060
   Loading Device Tree to c7e57000, end c7e5ef80 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

(and hang)

If you have some suggestions, I am try them as I get time.

adam

>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
>   series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
>   what they need to do to make this work, but I haven't figured out how to
>   test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
>   sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, 
> like
> cpufreq-dt) in the "common-clk-v10" branch of 
> https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for

[PATCH v3 2/3] fs: Convert kiocb rw_hint from enum to u16

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

In order to avoid kiocb bloat for per command iopriority support, rw_hint
is converted from enum to a u16. Added a guard around ki_hint assigment.

Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
---
 include/linux/fs.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 760d8da1b6c7..7a90ce387e00 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -284,6 +284,8 @@ enum rw_hint {
WRITE_LIFE_EXTREME  = RWH_WRITE_LIFE_EXTREME,
 };
 
+#define MAX_KI_HINT((1 << 16) - 1) /* ki_hint type is u16 */
+
 #define IOCB_EVENTFD   (1 << 0)
 #define IOCB_APPEND(1 << 1)
 #define IOCB_DIRECT(1 << 2)
@@ -299,7 +301,7 @@ struct kiocb {
void (*ki_complete)(struct kiocb *iocb, long ret, long ret2);
void*private;
int ki_flags;
-   enum rw_hintki_hint;
+   u16 ki_hint;
 } __randomize_layout;
 
 static inline bool is_sync_kiocb(struct kiocb *kiocb)
@@ -1927,12 +1929,21 @@ static inline enum rw_hint file_write_hint(struct file 
*file)
 
 static inline int iocb_flags(struct file *file);
 
+/* ki_hint changed from enum to u16, make sure rw_hint fits into u16 */
+static inline u16 ki_hint_valid(enum rw_hint hint)
+{
+   if (hint > MAX_KI_HINT)
+   return 0;
+
+   return hint;
+}
+
 static inline void init_sync_kiocb(struct kiocb *kiocb, struct file *filp)
 {
*kiocb = (struct kiocb) {
.ki_filp = filp,
.ki_flags = iocb_flags(filp),
-   .ki_hint = file_write_hint(filp),
+   .ki_hint = ki_hint_valid(file_write_hint(filp)),
};
 }
 
-- 
2.15.1

[PATCH v3 1/3] block: add ioprio_check_cap function

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

Aio per command iopriority support introduces a second interface between
userland and the kernel capable of passing iopriority. The aio interface also
needs the ability to verify that the submitting context has sufficient
priviledges to submit IOPRIO_RT commands. This patch creates the
ioprio_check_cap function to be used by the ioprio_set system call and also by
the aio interface.

Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
---
 block/ioprio.c | 22 --
 include/linux/ioprio.h |  2 ++
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/ioprio.c b/block/ioprio.c
index 6f5d0b6625e3..f9821080c92c 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -61,15 +61,10 @@ int set_task_ioprio(struct task_struct *task, int ioprio)
 }
 EXPORT_SYMBOL_GPL(set_task_ioprio);
 
-SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio)
+int ioprio_check_cap(int ioprio)
 {
int class = IOPRIO_PRIO_CLASS(ioprio);
int data = IOPRIO_PRIO_DATA(ioprio);
-   struct task_struct *p, *g;
-   struct user_struct *user;
-   struct pid *pgrp;
-   kuid_t uid;
-   int ret;
 
switch (class) {
case IOPRIO_CLASS_RT:
@@ -92,6 +87,21 @@ SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, 
ioprio)
return -EINVAL;
}
 
+   return 0;
+}
+
+SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio)
+{
+   struct task_struct *p, *g;
+   struct user_struct *user;
+   struct pid *pgrp;
+   kuid_t uid;
+   int ret;
+
+   ret = ioprio_check_cap(ioprio);
+   if (ret)
+   return ret;
+
ret = -ESRCH;
rcu_read_lock();
switch (which) {
diff --git a/include/linux/ioprio.h b/include/linux/ioprio.h
index 627efac73e6d..4a28cec49ec3 100644
--- a/include/linux/ioprio.h
+++ b/include/linux/ioprio.h
@@ -77,4 +77,6 @@ extern int ioprio_best(unsigned short aprio, unsigned short 
bprio);
 
 extern int set_task_ioprio(struct task_struct *task, int ioprio);
 
+extern int ioprio_check_cap(int ioprio);
+
 #endif
-- 
2.15.1

[PATCH v3 3/3] fs: Add aio iopriority support for block_dev

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the
newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field.

When a bio is created for an aio request by the block dev we set the priority
value of the bio to the user supplied value.

Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
---
 fs/aio.c | 16 
 fs/block_dev.c   |  2 ++
 include/linux/fs.h   |  2 ++
 include/uapi/linux/aio_abi.h |  1 +
 4 files changed, 21 insertions(+)

diff --git a/fs/aio.c b/fs/aio.c
index 88d7927ffbc6..f43d1d3a2e39 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1597,6 +1597,22 @@ static int io_submit_one(struct kioctx *ctx, struct iocb 
__user *user_iocb,
req->common.ki_flags |= IOCB_EVENTFD;
}
 
+   if (iocb->aio_flags & IOCB_FLAG_IOPRIO) {
+   /*
+* If the IOCB_FLAG_IOPRIO flag of aio_flags is set, then
+* aio_reqprio is interpreted as an I/O scheduling
+* class and priority.
+*/
+   ret = ioprio_check_cap(iocb->aio_reqprio);
+   if (ret) {
+   pr_debug("aio ioprio check cap error\n");
+   goto out_put_req;
+   }
+
+   req->common.ki_ioprio = iocb->aio_reqprio;
+   req->common.ki_flags |= IOCB_IOPRIO;
+   }
+
ret = kiocb_set_rw_flags(>common, iocb->aio_rw_flags);
if (unlikely(ret)) {
pr_debug("EINVAL: aio_rw_flags\n");
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 7ec920e27065..970bef79caa6 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -355,6 +355,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
*iter, int nr_pages)
bio->bi_write_hint = iocb->ki_hint;
bio->bi_private = dio;
bio->bi_end_io = blkdev_bio_end_io;
+   if (iocb->ki_flags & IOCB_IOPRIO)
+   bio->bi_ioprio = iocb->ki_ioprio;
 
ret = bio_iov_iter_get_pages(bio, iter);
if (unlikely(ret)) {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7a90ce387e00..3415e83f6350 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -294,6 +294,7 @@ enum rw_hint {
 #define IOCB_SYNC  (1 << 5)
 #define IOCB_WRITE (1 << 6)
 #define IOCB_NOWAIT(1 << 7)
+#define IOCB_IOPRIO(1 << 8)
 
 struct kiocb {
struct file *ki_filp;
@@ -302,6 +303,7 @@ struct kiocb {
void*private;
int ki_flags;
u16 ki_hint;
+   u16 ki_ioprio; /* See linux/ioprio.h */
 } __randomize_layout;
 
 static inline bool is_sync_kiocb(struct kiocb *kiocb)
diff --git a/include/uapi/linux/aio_abi.h b/include/uapi/linux/aio_abi.h
index a04adbc70ddf..d4593a6062ef 100644
--- a/include/uapi/linux/aio_abi.h
+++ b/include/uapi/linux/aio_abi.h
@@ -54,6 +54,7 @@ enum {
  *   is valid.
  */
 #define IOCB_FLAG_RESFD(1 << 0)
+#define IOCB_FLAG_IOPRIO   (1 << 1)
 
 /* read() from /dev/aio returns these structures. */
 struct io_event {
-- 
2.15.1

[PATCH v3 0/3] AIO add per-command iopriority

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

This is the per-I/O equivalent of the ioprio_set system call.
See the following link for performance implications on a SATA HDD:
https://lkml.org/lkml/2016/12/6/495

First patch factors ioprio_check_cap function out of ioprio_set system call to 
also be used by the aio ioprio interface.

Second patch converts kiocb ki_hint field to a u16 to avoid kiocb bloat.

Third patch passes ioprio hint from aio iocb to kiocb and enables block_dev 
usage of the per I/O ioprio feature.

v2: merge patches
use IOCB_FLAG_IOPRIO
validate intended use with IOCB_IOPRIO
add linux-api and linux-block to cc

v3: add ioprio_check_cap function
convert kiocb ki_hint to u16
use ioprio_check_cap when adding ioprio to kiocb in aio.c

Adam Manzanares (3):
  block: add ioprio_check_cap function
  fs: Convert kiocb rw_hint from enum to u16
  fs: Add aio iopriority support for block_dev

 block/ioprio.c   | 22 --
 fs/aio.c | 16 
 fs/block_dev.c   |  2 ++
 include/linux/fs.h   | 17 +++--
 include/linux/ioprio.h   |  2 ++
 include/uapi/linux/aio_abi.h |  1 +
 6 files changed, 52 insertions(+), 8 deletions(-)

-- 
2.15.1

RE: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

[Adam Thomson]

On 07 May 2018 05:50, Agrawal, Akshu wrote:

Apologies for the delay in response. Please see comments below.

> On 5/4/2018 2:45 PM, Adam Thomson wrote:
> > On 03 May 2018 08:59, Akshu Agrawal wrote:
> >
> >> Non-dts based systems can use ACPI DSDT to pass on the mclk
> >> to da7219.
> >> This enables da7219 mclk to be linked to system clock.
> >> Enable/Disable of the mclk is already handled in the codec so
> >> platform drivers don't have to explicitly do handling of mclk.
> >>
> >> Signed-off-by: Akshu Agrawal <akshu.agra...@amd.com>
> >> ---
> >> v2: Fixed kbuild error
> >> v3: Add corresponding clk_put for clk_get
> >>  include/sound/da7219.h|  2 ++
> >>  sound/soc/codecs/da7219.c | 10 +-
> >>  2 files changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/sound/da7219.h b/include/sound/da7219.h
> >> index 1bfcb16..df7ddf4 100644
> >> --- a/include/sound/da7219.h
> >> +++ b/include/sound/da7219.h
> >> @@ -38,6 +38,8 @@ struct da7219_pdata {
> >>
> >>const char *dai_clks_name;
> >>
> >> +  const char *mclk_name;
> >> +
> >>/* Mic */
> >>enum da7219_micbias_voltage micbias_lvl;
> >>enum da7219_mic_amp_in_sel mic_amp_in_sel;
> >> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
> >> index 980a6a8..ecd46fc 100644
> >> --- a/sound/soc/codecs/da7219.c
> >> +++ b/sound/soc/codecs/da7219.c
> >> @@ -1624,6 +1624,8 @@ static struct da7219_pdata
> *da7219_fw_to_pdata(struct
> >> snd_soc_component *compone
> >>dev_warn(dev, "Using default clk name: %s\n",
> >> pdata->dai_clks_name);
> >>
> >> +  device_property_read_string(dev, "dlg,mclk-name", >mclk_name);
> >> +
> >
> > Personally am still not keen on this. To me the use of a device_property_*
> > function suggests the same property resides in both DT and ACPI, but here 
> > we're
> > only using this for the ACPI case. DT has no want or need for this. I still 
> > feel
> > we should look at something more generic in the clock framework, although I 
> > do
> > agree with Mark that this should be properly specced.
> >
> 
> I am not an expert in field of ACPI, IMO forming a Spec and changing
> ACPI to have DT like clock framework is good to have but a bigger change
> which should be taken up later.

That's fair enough, but I wonder who will take that on. Really would be
beneficial to have something generic on the ACPI side.
 
> The current code of handling of mclk in the driver is usable only by DT.
> The device_property (though ACPI specific) makes this code, a common
> code for DT and ACPI based devices.
> 
> https://www.kernel.org/doc/Documentation/acpi/DSD-properties-rules.txt
> "Still, for the sake of code re-use, it may make sense to provide as
> much of the configuration data as possible in the form of device
> properties and complement that with an ACPI-specific mechanism suitable
> for the use case at hand.."

Given that on the DT side there's the expectation that the generic 'clock-names'
property might be provided to the driver, could we not reuse that rather than
introducing 'dlg,mclk-name' and diverging DT and ACPI properties?

> 
> Thanks,
> Akshu

[PATCH] typec: tcpm: Provide of_node pointer as part of psy_cfg

[Adam Thomson]

For supply registration, provide of_node pointer of the port device,
via the power_supply_config structure, to allow other psy drivers
to add us as a supplier using the 'power-supplies' DT property.

Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
---
 drivers/usb/typec/tcpm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 72996cc..e7c0b95 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4500,6 +4500,7 @@ static int devm_tcpm_psy_register(struct tcpm_port *port)
char *psy_name;
 
psy_cfg.drv_data = port;
+   psy_cfg.of_node = port->dev->of_node;
psy_name = devm_kzalloc(port->dev, psy_name_len, GFP_KERNEL);
if (!psy_name)
return -ENOMEM;
-- 
1.9.1

[PATCH v5 4/5] fs: blkdev set bio prio from kiocb prio

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

Now that kiocb has an ioprio field copy this over to the bio when it is
created from the kiocb.

Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
---
 fs/block_dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 7ec920e27065..da1e94d2bb75 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -355,6 +355,7 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
*iter, int nr_pages)
bio->bi_write_hint = iocb->ki_hint;
bio->bi_private = dio;
bio->bi_end_io = blkdev_bio_end_io;
+   bio->bi_ioprio = iocb->ki_ioprio;
 
ret = bio_iov_iter_get_pages(bio, iter);
if (unlikely(ret)) {
-- 
2.15.1

[PATCH v5 1/5] block: add ioprio_check_cap function

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

Aio per command iopriority support introduces a second interface between
userland and the kernel capable of passing iopriority. The aio interface also
needs the ability to verify that the submitting context has sufficient
priviledges to submit IOPRIO_RT commands. This patch creates the
ioprio_check_cap function to be used by the ioprio_set system call and also by
the aio interface.

Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
Reviewed-by: Christoph Hellwig <h...@lst.de>
---
 block/ioprio.c | 22 --
 include/linux/ioprio.h |  2 ++
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/ioprio.c b/block/ioprio.c
index 6f5d0b6625e3..f9821080c92c 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -61,15 +61,10 @@ int set_task_ioprio(struct task_struct *task, int ioprio)
 }
 EXPORT_SYMBOL_GPL(set_task_ioprio);
 
-SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio)
+int ioprio_check_cap(int ioprio)
 {
int class = IOPRIO_PRIO_CLASS(ioprio);
int data = IOPRIO_PRIO_DATA(ioprio);
-   struct task_struct *p, *g;
-   struct user_struct *user;
-   struct pid *pgrp;
-   kuid_t uid;
-   int ret;
 
switch (class) {
case IOPRIO_CLASS_RT:
@@ -92,6 +87,21 @@ SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, 
ioprio)
return -EINVAL;
}
 
+   return 0;
+}
+
+SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio)
+{
+   struct task_struct *p, *g;
+   struct user_struct *user;
+   struct pid *pgrp;
+   kuid_t uid;
+   int ret;
+
+   ret = ioprio_check_cap(ioprio);
+   if (ret)
+   return ret;
+
ret = -ESRCH;
rcu_read_lock();
switch (which) {
diff --git a/include/linux/ioprio.h b/include/linux/ioprio.h
index 627efac73e6d..4a28cec49ec3 100644
--- a/include/linux/ioprio.h
+++ b/include/linux/ioprio.h
@@ -77,4 +77,6 @@ extern int ioprio_best(unsigned short aprio, unsigned short 
bprio);
 
 extern int set_task_ioprio(struct task_struct *task, int ioprio);
 
+extern int ioprio_check_cap(int ioprio);
+
 #endif
-- 
2.15.1

[PATCH v5 0/5] AIO add per-command iopriority

[adam . manzanares]

From: Adam Manzanares <adam.manzana...@wdc.com>

This is the per-I/O equivalent of the ioprio_set system call.
See the following link for performance implications on a SATA HDD:
https://lkml.org/lkml/2016/12/6/495

First patch factors ioprio_check_cap function out of ioprio_set system call to
also be used by the aio ioprio interface.

Second patch converts kiocb ki_hint field to a u16 to avoid kiocb bloat.

Third patch passes ioprio hint from aio iocb to kiocb and inititalizes kiocb
ioprio value appropriately when it is not explicitly set.

Fourth patch enables the feature for blkdev.

Fifth patch enables the feature for iomap direct IO

Note: this work is based on top of linux-vfs/for-next

v2: merge patches
use IOCB_FLAG_IOPRIO
validate intended use with IOCB_IOPRIO
add linux-api and linux-block to cc

v3: add ioprio_check_cap function
convert kiocb ki_hint to u16
use ioprio_check_cap when adding ioprio to kiocb in aio.c

v4: handle IOCB_IOPRIO in aio_prep_rw
note patch 3 depends on patch 1 in commit msg

v5: rename ki_hint_valid -> ki_hint_validate 
remove ki_hint_validate comment and whitespace
remove IOCB_IOPRIO flag
initialize kiocb to have no priority 

Adam Manzanares (5):
  block: add ioprio_check_cap function
  fs: Convert kiocb rw_hint from enum to u16
  fs: Add aio iopriority support
  fs: blkdev set bio prio from kiocb prio
  fs: iomap dio set bio prio from kiocb prio

 block/ioprio.c   | 22 --
 drivers/block/loop.c |  3 +++
 fs/aio.c | 16 
 fs/block_dev.c   |  1 +
 fs/iomap.c   |  1 +
 include/linux/fs.h   | 16 ++--
 include/linux/ioprio.h   |  2 ++
 include/uapi/linux/aio_abi.h |  1 +
 8 files changed, 54 insertions(+), 8 deletions(-)

-- 
2.15.1