Re: [PATCH] sched: reset sysctl_sched_time_avg to default when
Peter,
V2 sent, tested okay on stable 4.1, re-factor a little, could apply
to v4.13-rc5,
please review.
[root@ ~]# sysctl kernel.sched_time_avg_ms
kernel.sched_time_avg_ms = 1000
[root@ ~]# sysctl kernel.sched_time_avg_ms=0
sysctl: setting key "kernel.sched_time_avg_ms": Invalid argument
kernel.sched_time_avg_ms = 0
[root@ ~]# sysctl kernel.sched_time_avg_ms
kernel.sched_time_avg_ms = 1000
[root@ ~]# sysctl kernel.sched_time_avg_ms=900
kernel.sched_time_avg_ms = 900
[root@ ~]# sysctl kernel.sched_time_avg_ms
kernel.sched_time_avg_ms = 900
Thanks,
Ethan
On Sat, Sep 2, 2017 at 8:33 AM, Ethan Zhao wrote:
> Yep, that is the first place I considered to set the limit, but that would
> break KABI ?
>
> Thanks,
> Ethan
>
> On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra wrote:
>> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote:
>>> System will hang if user set sysctl_sched_time_avg to 0 by
>>>
>>> [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
>>>
>>> Stack traceback for pid 0
>>> 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
>>> 883f7ccc3ae8 0018 810c4dd0
>>> 00017800 883f7ccc3d78 0003 883f7ccc3bf8
>>> 810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
>>> Call Trace:
>>> [] ? update_group_capacity+0x110/0x200
>>> [] ? update_sd_lb_stats+0x109/0x600
>>> [] ? find_busiest_group+0x47/0x530
>>> [] ? load_balance+0x194/0x900
>>> [] ? update_rq_clock.part.83+0x1a/0xe0
>>> [] ? rebalance_domains+0x152/0x290
>>> [] ? run_rebalance_domains+0xdc/0x1d0
>>> [] ? __do_softirq+0xfb/0x320
>>> [] ? irq_exit+0x125/0x130
>>> [] ? scheduler_ipi+0x97/0x160
>>> [] ? smp_reschedule_interrupt+0x29/0x30
>>> [] ? reschedule_interrupt+0x6e/0x80
>>> [] ? cpuidle_enter_state+0xcc/0x230
>>> [] ? cpuidle_enter_state+0x9c/0x230
>>> [] ? cpuidle_enter+0x17/0x20
>>> [] ? cpu_startup_entry+0x38c/0x420
>>> [] ? start_secondary+0x173/0x1e0
>>>
>>> Because divide-by-zero error happens in function
>>>
>>> update_group_capacity()
>>> update_cpu_capacity()
>>> scale_rt_capacity()
>>> {
>>> ...
>>> total = sched_avg_period() + delta;
>>> used = div_u64(avg, total);
>>> ...
>>> }
>>>
>>> Seems this issue could be reproduced on all I tried stable 4.1 - last
>>> kernel.
>>>
>>> To fix this issue, reset sysctl_sched_time_avg to default value
>>> MSEC_PER_SEC if user input invalid value in function
>>>
>>> sched_avg_period()
>>>
>>> Reported-by: James Puthukattukaran
>>> Signed-off-by: Ethan Zhao
>>> ---
>>> Tested on stable 4.1, compiled on stable 4.13-rc5
>>> kernel/sched/sched.h | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>>> index eeef1a3..b398560 100644
>>> --- a/kernel/sched/sched.h
>>> +++ b/kernel/sched/sched.h
>>> @@ -1620,6 +1620,9 @@ static inline void rq_last_tick_reset(struct rq *rq)
>>>
>>> static inline u64 sched_avg_period(void)
>>> {
>>> + if (unlikely(sysctl_sched_time_avg <= 0))
>>> + sysctl_sched_time_avg = MSEC_PER_SEC;
>>> +
>>
>> Sight, no.. you can set limits in the sysctl table.
Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup
Hi Bjorn,
>>> Bluetooth BD address can be retrieved in the same way as
>>> for wcnss-wlan MAC address. This patch mainly stores the
>>> local-mac-address property and sets the BD address during
>>> hci device setup.
>>>
>>> Signed-off-by: Loic Poulain
>>> Signed-off-by: Bjorn Andersson
>>> ---
>>> drivers/bluetooth/btqcomsmd.c | 28
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
>>> index d00c4fdae924..443bb2099329 100644
>>> --- a/drivers/bluetooth/btqcomsmd.c
>>> +++ b/drivers/bluetooth/btqcomsmd.c
>>> @@ -26,6 +26,7 @@
>>> struct btqcomsmd {
>>> struct hci_dev *hdev;
>>>
>>> + const bdaddr_t *addr;
>>> struct rpmsg_endpoint *acl_channel;
>>> struct rpmsg_endpoint *cmd_channel;
>>> };
>>> @@ -100,6 +101,27 @@ static int btqcomsmd_close(struct hci_dev *hdev)
>>> return 0;
>>> }
>>>
>>> +static int btqcomsmd_setup(struct hci_dev *hdev)
>>> +{
>>> + struct btqcomsmd *btq = hci_get_drvdata(hdev);
>>> + struct sk_buff *skb;
>>> +
>>> + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
>>> + if (IS_ERR(skb))
>>> + return PTR_ERR(skb);
>>> + kfree_skb(skb);
>>> +
>>> + if (btq->addr) {
>>> + bdaddr_t bdaddr;
>>> +
>>> + /* btq->addr stored with most significant byte first */
>>> + baswap(&bdaddr, btq->addr);
>>> + return qca_set_bdaddr_rome(hdev, &bdaddr);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int btqcomsmd_probe(struct platform_device *pdev)
>>> {
>>> struct btqcomsmd *btq;
>>> @@ -123,6 +145,11 @@ static int btqcomsmd_probe(struct platform_device
>>> *pdev)
>>> if (IS_ERR(btq->cmd_channel))
>>> return PTR_ERR(btq->cmd_channel);
>>>
>>> + btq->addr = of_get_property(pdev->dev.of_node, "local-mac-address",
>>> + &ret);
>>> + if (ret != sizeof(bdaddr_t))
>>> + btq->addr = NULL;
>>> +
>>> hdev = hci_alloc_dev();
>>> if (!hdev)
>>> return -ENOMEM;
>>> @@ -135,6 +162,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
>>> hdev->open = btqcomsmd_open;
>>> hdev->close = btqcomsmd_close;
>>> hdev->send = btqcomsmd_send;
>>> + hdev->setup = btqcomsmd_setup;
>>> hdev->set_bdaddr = qca_set_bdaddr_rome;
>>
>> I do not like this patch. Why not just set HCI_QUIRK_INVALID_BDADDR
>> and let a userspace tool deal with reading the BD_ADDR from some
>> storage.
>>
>
> That's what we currently have, but we regularly get complaints from
> developers using our board (DB410c).
at least not in the upstream driver. It does not use HCI_QUIRK_INVALID_BDADDR
to tell the system that its BD_ADDR is not valid. Which is something you still
need to do if local-mac-address would not be found.
What BD_ADDR is actually returned by default. Can someone send me a “btmon -w
trace.log” for an init procedure of this chip?
> We're maintaining a Debian-based and an OpenEmbedded-based build and at
> least in the past btmgmt was not available in these - so we would have
> to maintain both a custom BlueZ package and then some scripts to inject
> the appropriate mac address.
>
> Beyond these reference builds our users tend to build their own system
> images and I was hoping that they would not be forced to have a custom
> hook running each time hci0 is registered.
Frankly this has never been about btmgmt usage. That tool is really just for us
to test the interface. What was needed is that we create a small daemon that
can have backends for accessing the various OTPs. Or in dev mode just generate
a random OUI from an unused OUI range. I would have put that into bluetoothd,
but it seemed not a good idea since many companies were secret about their OTP
access. So I assumed they build there own quick solution since mgmt API is
fully documented and you only need to listen for Unconfigured Index event, send
Set Public Address and leave. So something super simple.
For a LE only controller without a BD_ADDR, we recently added a pool of static
addresses that it will generate and program. However that is specific since LE
is capable of operating without a public address.
We could actually downgrade a dual-mode controller without a BD_ADDR into a
single mode controller. That will automatically start using static addresses
and be fully operational. That might be useful for people who get a dual-mode
controller, but only care about LE. I have seen devices that only use the LE
portion.
>> Frankly I do not get this WiFI MAC address or BD_ADDR stored in DT. I
>> assumed the DT is suppose to describe hardware and not some value that
>> is normally retrieved for OTP or alike.
>>
>
> While I share your skepticism here I find it way superior over the
> various cases where this information is hard coded in some firmware file
> that has to be patched for each device - in particular when considering
> the out-of-tre
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument
Hi Kees, On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook wrote: > On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni wrote: ... > >> BTW Kees, also in next version I won't remove the >> capable(CAP_NET_ADMIN) check from [1] >> even if there is the new request_module_cap(), I would like it to be >> in a different patches, this way we go incremental >> and maybe it is better to merge what we have now ? and follow up >> later, and of course if other maintainers agree too! > > Yes, incremental. I would suggest first creating the API changes to > move a basic require_cap test into the LSM (which would drop the > open-coded capable() checks in the net code), and then add the > autoload logic in the following patches. That way the "infrastructure" > changes happen separately and do not change any behaviors, but moves > the caps test down where its wanted in the LSM, before then augmenting > the logic. > >> I just need a bit of free time to check again everything and will send >> a v5 with all requested changes. > > Great, thank you! > So sorry was busy these last months, I picked it again, will send v5 after the merge window. Kees I am looking on a way to integrate a test for it, we should use something like the example here [1] or maybe something else ? and which module to use ? I still did not sort this out, if anyone has some suggestions, thank you in advance! [1] http://openwall.com/lists/kernel-hardening/2017/05/22/7 -- tixxdz
RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 31, 2017 4:55 AM > ... > On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: > > > On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: > > If we allow multiple host side transports, virtio host side support and > > vmci should be able to coexist regardless of the order of initialization. > > That sounds good to me. > > This means af_vsock.c needs to be aware of CID allocation. Currently the > vhost_vsock.ko driver handles this itself (it keeps a list of CIDs and > checks that they are not used twice). It should be possible to move > that state into af_vsock.c so we have pairs. > > I'm currently working on NFS over AF_VSOCK and sock_diag support (for > ss(8) and netstat-like tools). > > Multi-transport support is lower priority for me at the moment. I'm > happy to review patches though. If there is no progress on this by the > end of the year then I will have time to work on it. I understand. Thank you both for sharing the details about the plan! > Are either of you are in Prague, Czech Republic on October 25-27 for > Linux Kernel Summit, Open Source Summit Europe, Embedded Linux > Conference Europe, KVM Forum, or MesosCon Europe? > > Stefan I regret I won't be there this year. Thanks, -- Dexuan
Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro
On Fri, Sep 01, 2017 at 08:51:55PM -0700, Joe Perches wrote:
> On Fri, 2017-09-01 at 18:35 -0700, David Miller wrote:
> > From: Thomas Meyer
> > Date: Thu, 31 Aug 2017 16:18:15 +0200
> >
> > > Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> > > candidates.
> > > Maybe a coccinelle can catch all of those.
>
Hi,
> Umm: try scripts/coccinelle/misc/array_size.cocci
Yes, I found out/remembered after I submitted above patch... I used to
run most of the cocci spatches (some just run too long) after each rc1 release,
but lost interest/time. nobody seems to
do this regularly, at least for existing spatches.
See 6 patches with Message-ID 20170901212907.5662-1-tho...@m3y3r.de
> Until then, maybe a perl script?
>
> $ git grep --name-only sizeof.*/.*sizeof drivers/net | \
> xargs perl -p -i -e
> 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\/\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)/ARRAY_SIZE(\1)/g'
>
> gives:
>
> $ git diff --stat drivers/net
> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/fw.c | 4 +--
> drivers/net/ethernet/mellanox/mlx4/main.c | 8 +++---
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 186
> +++---
> 5 files changed, 101 insertions(+), 101 deletions(-)
Which makes me wonder why cocci didn't found above places...
Also cocci includes linux/kernel.h if not already present.
I will give above regex a try for the whole kernel tree and check for
false positives.
with kind regards
thomas
Re: printk: what is going on with additional newlines?
Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 1:41 PM, Tetsuo Handa > wrote: > >> > >> A private buffer has none of those issues. > > > > Yes, I posted "[PATCH] printk: Add best-effort printk() buffering." at > > http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp > > . > > No, this is exactly what I *don't* want, because it takes over printk() > itself. > > And that's problematic, because nesting happens for various reasons. > > For example, you try to handle that nesting with printk_context(), and > nothing when an interrupt happens. > > But that is fundamentally broken. > > Just to give an example: what if an interrupt happens, it does this > buffering thing, then it gets interrupted by *another* interrupt, and > now the printk from that other interrupt gets incorrectly nested > together with the first one, because your "printk_context()" gives > them the same context? My assumption was that (1) task context can be preempted by soft IRQ context, hard IRQ context and NMI context. (2) soft IRQ context can be preempted by hard IRQ context and NMI context. (3) hard IRQ context can be preempted by NMI context. (4) An kernel-oops event can interrupt task context, soft IRQ context, hard IRQ context and NMI context, but the interrupted context can not continue execution of vprintk_default() after returning from the kernel-oops event even if the kernel-oops event occurred in schedulable context and panic_on_oops == 0. and thus my "printk_context()" gives them different context. But my assumption was wrong that soft IRQ context can be preempted by different soft IRQ context (e.g. SoftIRQ1 can be preempted by SoftIRQ2 while running handler for SoftIRQ1, and SoftIRQ2 can be preempted by SoftIRQ3 while running handler for SoftIRQ2, and so on) hard IRQ context can be preempted by different hard IRQ context (e.g. HardIRQ1 can be preempted by HardIRQ2 while running handler for HardIRQ1, and HardIRQ2 can be preempted by HardIRQ3 while running handler for HardIRQ2, and so on) ? Then, we need to recognize how many IRQs are nested. I just tried to distinguish context using one "unsigned long" value by embedding IRQ status into lower bits of "struct task_struct *". I can change to distinguish context using multiple "unsigned long" values. > > And it really doesn't have to even be interrupts. Look at what happens > if you take a page fault in kernel space. Same exact deal. Both are > sleeping contexts. Is merging messages from outside a page fault and inside a page fault so serious? That would happen only if memory access which might cause a page fault occurs between get_printk_buffer() and put_printk_buffer(), and I think that such user is rare. > > So I really think that the only thing that knows what the "context" is > is the person who does the printing. So if you want to create a > printing buffer, it should be explicit. You allocate the buffer ahead > of time (perhaps on the stack, possibly using actual allocations), and > you use that explicit context. If my assumption was wrong, isn't it dangerous from stack usage point of view that we try to call kmalloc() (or allocate from stack memory) for prbuf_init() for each nested level because it is theoretically possible that a different IRQ jumps in while kmalloc() is in progress (or stack memory is in use)? > > Yes, it means that you don't do "printk()". You do an actual > "buf_print()" or similar. > > Linus > My worry is that there are so many functions which will need to receive "struct seq_buf *" argument (from tail of __dump_stack() to head of out_of_memory(), including e.g. cpuset_print_current_mems_allowed()) that patches for passing "struct seq_buf *" argument becomes so large and difficult to synchronize. I tried to pass such argument to relevant functions before I propose "[PATCH] printk: Add best-effort printk() buffering." patch, but I came to conclusion that passing such argument is too complicated and too much bloat compared to merit. If we teach printk subsystem that "I want to use buffering" via get_printk_buffer(), we don't need to scatter around "struct seq_buf *" argument throughout the kernel. Using kmalloc() for prbuf_init() also introduces problems such as (a) we need to care about safe GFP flags (i.e. GFP_ATOMIC or GFP_KERNEL or something else which cannot be managed by current_gfp_context()) based on locking context (b) allocations can fail, and printing allocation failure messages when printing original messages is disturbing (c) allocation stall/failure messages are printed under memory pressure, but stack memory is not large enough to store messages related allocation stall/failure messages and thus I want to use "statically allocated buffer" like workqueue's rescuer kernel thread which can be used under memory pressure. Linus Torvalds wrote at http://lkml.kernel.org/r/CA+55aFxmL
Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup
Hi Rob,
>>> Bluetooth BD address can be retrieved in the same way as
>>> for wcnss-wlan MAC address. This patch mainly stores the
>>> local-mac-address property and sets the BD address during
>>> hci device setup.
>>>
>>> Signed-off-by: Loic Poulain
>>> Signed-off-by: Bjorn Andersson
>>> ---
>>> drivers/bluetooth/btqcomsmd.c | 28
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
>>> index d00c4fdae924..443bb2099329 100644
>>> --- a/drivers/bluetooth/btqcomsmd.c
>>> +++ b/drivers/bluetooth/btqcomsmd.c
>>> @@ -26,6 +26,7 @@
>>> struct btqcomsmd {
>>> struct hci_dev *hdev;
>>>
>>> + const bdaddr_t *addr;
>>> struct rpmsg_endpoint *acl_channel;
>>> struct rpmsg_endpoint *cmd_channel;
>>> };
>>> @@ -100,6 +101,27 @@ static int btqcomsmd_close(struct hci_dev *hdev)
>>> return 0;
>>> }
>>>
>>> +static int btqcomsmd_setup(struct hci_dev *hdev)
>>> +{
>>> + struct btqcomsmd *btq = hci_get_drvdata(hdev);
>>> + struct sk_buff *skb;
>>> +
>>> + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
>>> + if (IS_ERR(skb))
>>> + return PTR_ERR(skb);
>>> + kfree_skb(skb);
>>> +
>>> + if (btq->addr) {
>>> + bdaddr_t bdaddr;
>>> +
>>> + /* btq->addr stored with most significant byte first */
>>> + baswap(&bdaddr, btq->addr);
>>> + return qca_set_bdaddr_rome(hdev, &bdaddr);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int btqcomsmd_probe(struct platform_device *pdev)
>>> {
>>> struct btqcomsmd *btq;
>>> @@ -123,6 +145,11 @@ static int btqcomsmd_probe(struct platform_device
>>> *pdev)
>>> if (IS_ERR(btq->cmd_channel))
>>> return PTR_ERR(btq->cmd_channel);
>>>
>>> + btq->addr = of_get_property(pdev->dev.of_node, "local-mac-address",
>>> + &ret);
>>> + if (ret != sizeof(bdaddr_t))
>>> + btq->addr = NULL;
>>> +
>>> hdev = hci_alloc_dev();
>>> if (!hdev)
>>> return -ENOMEM;
>>> @@ -135,6 +162,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
>>> hdev->open = btqcomsmd_open;
>>> hdev->close = btqcomsmd_close;
>>> hdev->send = btqcomsmd_send;
>>> + hdev->setup = btqcomsmd_setup;
>>> hdev->set_bdaddr = qca_set_bdaddr_rome;
>>
>> I do not like this patch. Why not just set HCI_QUIRK_INVALID_BDADDR and let
>> a userspace tool deal with reading the BD_ADDR from some storage.
>>
>> Frankly I do not get this WiFI MAC address or BD_ADDR stored in DT. I
>> assumed the DT is suppose to describe hardware and not some value that is
>> normally retrieved for OTP or alike.
>
> Use of "local-mac-address" for ethernet at least has existed as long
> at OpenFirmware I think. For some platforms, DT is the only OTP. And
> sometimes, the bootloader (like u-boot) stores MAC addresses and then
> populates them on boot.
>
> Seems like if we just let userspace deal with it, then we're back to a
> btattach tool with every platform's specific way of reading the MAC
> address.
for Bluetooth that is not true. We have Set Public Address command that is
uniquely handling this and the HCI_QUIRK_INVALID_BDADDR address does the right
magic to allow userspace to identify a missing address. It is done nicely and
correctly and works fine.
Mind you this is even used when there actually is a BD_ADDR, but the device
manufacturer wants to have one from its own OUI range compared to the chip
manufacturer’s OUI range.
If DT is really the only place for the BD_ADDR and the bootloader kinda does
add / merge it into the DT, then by all means that is fine. However if it is
not, then this feature is dangerous since it can lead to multiple devices with
the same address. I rather have these devices leave the kernel in unconfigured
mode. And then force a userspace tool to use Set Public Address to bring it
into configured mode.
Regards
Marcel
Re: RFC: Revert move default dialect from CIFS to to SMB3
On Fri, 2017-09-01 at 20:56 -0700, Linus Torvalds wrote: > On Fri, Sep 1, 2017 at 7:16 PM, Steve French wrote: > > > > The default was SMB1 (CIFS) and was recently changed to SMB3. > > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1" > > etc. on mount. > > > > We just put together a patch to better explain the default changes > > (with additional warning messages) as suggested. > > > > SMB3 is significantly better than SMB2.1 (supporting encrypted shares > > and sessions for example, and requiring support for "secure negotiate") > > and some servers require SMB3 minimum as a result, > > The default shouldn't be about "best and most secure", but "most > convenient, while still not actively *IN*secure" > > So "some servers require 3.0" may be true, but if it's also the case > that "most servers still don't do 3.0 at all", then it's a "some" vs > "most". > > Which is the most common one? That should be the default. > > I realize that eventually we'll have auto-negotiation, but that's > clearly not for 4.13. So in the meantime the only issue is what the > right default should be without auto-negotiation. > > So it should be about what the failure rate is. If trying for smb3 has > a high failure rate because people simply don't have that yet, then > making that the default was clearly the wrong choice. > > Because being "better" is immaterial if it doesn't work. My quick research shows: SMB 2.1 but not SMB3 is on: Windows 7 Windows 8 Windows 2008 Windows 2012 Samba 3.6 and earlier (SMB1 only by default) SMB3 is on: Windows 8.1 Windows 2012 R2 Windows 10 Windows 2016 Samba 4.0 and above (released 2012) I'm not sure exactly which Mac versions. Some breakage will be old (and quite recent) NAS and routers that use SMB1 and often very old Samba, but most of those only do SMB1. In terms of 'actively *IN*secure', it really depends what you mean by that. That is, like all big changes, the movement against SMB1 has had multiple motivations: - a desire no longer to expose really old code in Windows (recently exploited) - a desire to retire an old and complex protocol - SMB3 having proper secure negotiation (I'll leave it to Steve to explain the difference between SMB2 and 3 in that respect, I'm not so current on the details). I hope this help, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Linux 4.9.47
I'm announcing the release of the 4.9.47 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/mmu.c | 16 ++--- arch/arm64/kernel/fpsimd.c |2 arch/arm64/mm/fault.c|5 + arch/x86/include/asm/io.h|4 - drivers/net/wireless/intersil/p54/fwio.c |2 drivers/scsi/isci/remote_node_context.c |3 + drivers/scsi/sg.c| 49 ++--- drivers/staging/wilc1000/linux_wlan.c| 34 +++- kernel/gcov/base.c |6 ++ kernel/gcov/gcc_4_7.c|4 + kernel/locking/spinlock_debug.c | 86 +-- lib/lz4/lz4hc_compress.c |2 13 files changed, 73 insertions(+), 142 deletions(-) Arnd Bergmann (3): scsi: isci: avoid array subscript warning staging: wilc1000: simplify vif[i]->ndev accesses x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl Dave Martin (1): arm64: fpsimd: Prevent registers leaking across exec Greg Kroah-Hartman (2): lz4: fix bogus gcc warning Linux 4.9.47 Hannes Reinecke (2): scsi: sg: protect accesses to 'reserved' page array scsi: sg: reset 'res_in_use' after unlinking reserved array Jiri Slaby (1): p54: memset(0) whole array Mark Rutland (1): arm64: mm: abort uaccess retries upon fatal signal Martin Liska (1): gcov: support GCC 7.1 Suzuki K Poulose (1): kvm: arm/arm64: Fix race in resetting stage2 PGD Waiman Long (1): locking/spinlock/debug: Remove spinlock lockup detection code signature.asc Description: PGP signature
Re: Linux 4.9.47
diff --git a/Makefile b/Makefile
index 846ef1b57a02..a0abbfc15a49 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 46
+SUBLEVEL = 47
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 710511cadd50..0c060c5e844a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -829,22 +829,22 @@ void stage2_unmap_vm(struct kvm *kvm)
* Walks the level-1 page table pointed to by kvm->arch.pgd and frees all
* underlying level-2 and level-3 tables before freeing the actual level-1
table
* and setting the struct pointer to NULL.
- *
- * Note we don't need locking here as this is only called when the VM is
- * destroyed, which can only be done once.
*/
void kvm_free_stage2_pgd(struct kvm *kvm)
{
- if (kvm->arch.pgd == NULL)
- return;
+ void *pgd = NULL;
spin_lock(&kvm->mmu_lock);
- unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ if (kvm->arch.pgd) {
+ unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ pgd = kvm->arch.pgd;
+ kvm->arch.pgd = NULL;
+ }
spin_unlock(&kvm->mmu_lock);
/* Free the HW pgd, one page at a time */
- free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
- kvm->arch.pgd = NULL;
+ if (pgd)
+ free_pages_exact(pgd, S2_PGD_SIZE);
}
static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
*cache,
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 394c61db5566..1d5890f19ca3 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
void fpsimd_flush_thread(void)
{
+ preempt_disable();
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ preempt_enable();
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0e90c7e0279c..fec5b1ce97f8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -373,8 +373,11 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/*
* Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d34bd370074b..6c5020163db0 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port)
\
static inline void outs##bwl(int port, const void *addr, unsigned long count) \
{ \
asm volatile("rep; outs" #bwl \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
} \
\
static inline void ins##bwl(int port, void *addr, unsigned long count) \
{ \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
}
BUILDIO(b, b, char)
diff --git a/drivers/net/wireless/intersil/p54/fwio.c
b/drivers/net/wireless/intersil/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/intersil/p54/fwio.c
+++ b/drivers/net/wireless/intersil/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
- memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+ memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
sizeof(struct p54_pa_curve_data_sample) *
min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum
scis_sds_remot
Re: Linux 4.4.86
diff --git a/Makefile b/Makefile
index 0f3d843f42a7..1207bf6a0e7a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 85
+SUBLEVEL = 86
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 4c46c54a3ad7..6638903f0cb9 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
void fpsimd_flush_thread(void)
{
+ preempt_disable();
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ preempt_enable();
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a4b466424a32..7fabf49f2aeb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -313,8 +313,11 @@ retry:
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/*
* Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad07853..9016b4b70375 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port)
\
static inline void outs##bwl(int port, const void *addr, unsigned long count) \
{ \
asm volatile("rep; outs" #bwl \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
} \
\
static inline void ins##bwl(int port, void *addr, unsigned long count) \
{ \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
}
BUILDIO(b, b, char)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index cc91ae832ffb..6fd7b50c5747 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -635,7 +635,8 @@ hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
"enabling oneshot unclaimed register reporting. "
"Please use i915.mmio_debug=N for more
information.\n");
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
- i915.mmio_debug = mmio_debug_once--;
+ i915.mmio_debug = mmio_debug_once;
+ mmio_debug_once = false;
}
}
diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
index f325663c27c5..4b58e8aaf5c5 100644
--- a/drivers/i2c/busses/i2c-jz4780.c
+++ b/drivers/i2c/busses/i2c-jz4780.c
@@ -786,10 +786,6 @@ static int jz4780_i2c_probe(struct platform_device *pdev)
jz4780_i2c_writew(i2c, JZ4780_I2C_INTM, 0x0);
- i2c->cmd = 0;
- memset(i2c->cmd_buf, 0, BUFSIZE);
- memset(i2c->data_buf, 0, BUFSIZE);
-
i2c->irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(&pdev->dev, i2c->irq, jz4780_i2c_irq, 0,
dev_name(&pdev->dev), i2c);
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
- memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+ memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
sizeof(struct p54_pa_curve_data_sample) *
min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum
scis_sds_remote_node_context_states state)
{
static con
Linux 4.4.86
I'm announcing the release of the 4.4.86 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 - arch/arm64/kernel/fpsimd.c |2 + arch/arm64/mm/fault.c |5 ++- arch/x86/include/asm/io.h |4 +- drivers/gpu/drm/i915/intel_uncore.c |3 + drivers/i2c/busses/i2c-jz4780.c |4 -- drivers/net/wireless/p54/fwio.c |2 - drivers/scsi/isci/remote_node_context.c |3 + drivers/scsi/lpfc/lpfc_els.c|5 ++- drivers/scsi/sg.c | 49 ++-- fs/btrfs/volumes.c |2 - include/linux/lightnvm.h|1 kernel/gcov/base.c |6 +++ kernel/gcov/gcc_4_7.c |4 +- sound/pci/au88x0/au88x0_core.c | 14 +++-- 15 files changed, 63 insertions(+), 43 deletions(-) Arnd Bergmann (2): scsi: isci: avoid array subscript warning x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl Colin Ian King (1): btrfs: remove duplicate const specifier Dave Martin (1): arm64: fpsimd: Prevent registers leaking across exec Florian Meier (1): gcov: add support for gcc version >= 6 Greg Kroah-Hartman (2): drm/i915: fix compiler warning in drivers/gpu/drm/i915/intel_uncore.c Linux 4.4.86 Hannes Reinecke (2): scsi: sg: protect accesses to 'reserved' page array scsi: sg: reset 'res_in_use' after unlinking reserved array James Smart (1): lpfc: Fix Device discovery failures during switch reboot test. Javier González (1): lightnvm: initialize ppa_addr in dev_to_generic_addr() Jiri Slaby (1): p54: memset(0) whole array Mark Rutland (1): arm64: mm: abort uaccess retries upon fatal signal Martin Liska (1): gcov: support GCC 7.1 Takashi Iwai (1): ALSA: au88x0: Fix zero clear of stream->resources Wolfram Sang (1): i2c: jz4780: drop superfluous init signature.asc Description: PGP signature
Linux 3.18.69
I'm announcing the release of the 3.18.69 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 - arch/arm64/kernel/fpsimd.c |3 + arch/arm64/mm/fault.c |5 ++- arch/x86/boot/compressed/misc.c | 14 arch/x86/include/asm/io.h |4 +- arch/x86/tools/relocs.c | 39 +--- drivers/base/dma-contiguous.c |2 - drivers/clk/clk-si5351.c| 10 +++--- drivers/net/wireless/p54/fwio.c |2 - drivers/scsi/isci/remote_node_context.c |3 + drivers/scsi/sg.c | 49 +- include/linux/bitmap.h | 36 +++--- include/linux/cma.h | 13 include/linux/dma-contiguous.h |4 +- kernel/gcov/base.c | 12 +++ kernel/gcov/gcc_4_7.c |6 +++ lib/bitmap.c| 24 -- mm/cma.c| 52 mm/page_alloc.c |6 ++- sound/pci/au88x0/au88x0_core.c | 14 +++- 20 files changed, 208 insertions(+), 92 deletions(-) Ard Biesheuvel (1): arm64: flush FP/SIMD state correctly after execve() Arnd Bergmann (2): scsi: isci: avoid array subscript warning x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl Danesh Petigara (1): mm: cma: fix CMA aligned offset calculation Dave Martin (1): arm64: fpsimd: Prevent registers leaking across exec Florian Meier (1): gcov: add support for gcc version >= 6 George G. Davis (1): mm: cma: fix totalcma_pages to include DT defined CMA regions Greg Kroah-Hartman (1): Linux 3.18.69 Gregory Fong (1): mm: cma: align to physical address, not CMA region position Hannes Reinecke (2): scsi: sg: protect accesses to 'reserved' page array scsi: sg: reset 'res_in_use' after unlinking reserved array Jan Beulich (1): x86-64: Handle PC-relative relocations on per-CPU data Jiri Slaby (1): p54: memset(0) whole array Krzysztof Kozlowski (1): clk: si5351: Constify clock names and struct regmap_config Lorenzo Stoakes (1): gcov: add support for GCC 5.1 Mark Rutland (1): arm64: mm: abort uaccess retries upon fatal signal Markus Trippelsdorf (1): x86/tools: Fix gcc-7 warning in relocs.c Martin Liska (1): gcov: support GCC 7.1 Michal Nazarewicz (1): lib: bitmap: add alignment offset for bitmap_find_next_zero_area() Pintu Kumar (1): mm: cma: split cma-reserved in dmesg log Rohit Vaswani (1): mm: cma: fix incorrect type conversion for size during dma allocation Sasha Levin (1): mm: cma: constify and use correct signness in mm/cma.c Takashi Iwai (1): ALSA: au88x0: Fix zero clear of stream->resources Thierry Reding (1): mm/cma: make kmemleak ignore CMA regions signature.asc Description: PGP signature
Re: Linux 3.18.69
diff --git a/Makefile b/Makefile
index 0d7f1e91e910..49237a0442cd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 68
+SUBLEVEL = 69
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 3dca15634e69..7b4e9ea0b1a4 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -156,8 +156,11 @@ void fpsimd_thread_switch(struct task_struct *next)
void fpsimd_flush_thread(void)
{
+ preempt_disable();
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
+ fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ preempt_enable();
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 6094c64b3380..df0f5347029f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -253,8 +253,11 @@ retry:
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/*
* Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 0c33a7c67ea5..a950864a64da 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -260,7 +260,7 @@ static void handle_relocations(void *output, unsigned long
output_len)
/*
* Process relocations: 32 bit relocations first then 64 bit after.
-* Two sets of binary relocations are added to the end of the kernel
+* Three sets of binary relocations are added to the end of the kernel
* before compression. Each relocation table entry is the kernel
* address of the location which needs to be updated stored as a
* 32-bit value which is sign extended to 64 bits.
@@ -270,6 +270,8 @@ static void handle_relocations(void *output, unsigned long
output_len)
* kernel bits...
* 0 - zero terminator for 64 bit relocations
* 64 bit relocation repeated
+* 0 - zero terminator for inverse 32 bit relocations
+* 32 bit inverse relocation repeated
* 0 - zero terminator for 32 bit relocations
* 32 bit relocation repeated
*
@@ -286,6 +288,16 @@ static void handle_relocations(void *output, unsigned long
output_len)
*(uint32_t *)ptr += delta;
}
#ifdef CONFIG_X86_64
+ while (*--reloc) {
+ long extended = *reloc;
+ extended += map;
+
+ ptr = (unsigned long)extended;
+ if (ptr < min_addr || ptr > max_addr)
+ error("inverse 32-bit relocation outside of kernel!\n");
+
+ *(int32_t *)ptr -= delta;
+ }
for (reloc--; *reloc; reloc--) {
long extended = *reloc;
extended += map;
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8a1e0c..a882087d34f2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -297,13 +297,13 @@ static inline unsigned type in##bwl##_p(int port)
\
static inline void outs##bwl(int port, const void *addr, unsigned long count) \
{ \
asm volatile("rep; outs" #bwl \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
} \
\
static inline void ins##bwl(int port, void *addr, unsigned long count) \
{ \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
}
BUILDIO(b, b, char)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index a5efb21d5228..73eb7fd4aec4 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -20,7 +20,10 @@ struct relocs {
static struct relocs relocs16;
static struct relocs relocs32;
+#if ELF_BITS == 64
+static struct relocs relocs32neg;
static struct relocs relocs64;
+#endif
struct section {
Elf_Shdr shdr;
@@ -762,11 +765,16 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel,
ElfW(Sym) *sym,
switch (r_type) {
case R_X86_64_NONE:
+ /* NONE can be ignored. */
+
Re: [RFC 0/4] mmc: sdhci-msm: Add CQE support for sdhci-msm
On 8/31/2017 2:09 PM, Adrian Hunter wrote: On 30/08/17 16:04, Ritesh Harjani wrote: Hi All, Please ignore the previous patch series from a wrong email address. Stupid gitconfig issue. Apologies for the spam. This is RFC patch series based on top of ulfh_mmc/cmdq branch which is based upon Adrian's CMDQ patch series. Below patch series enables CQE for sdhci-msm platform. This has been tested on internal 8996 MTP which has CMDQ support. Fixes w.r.t. CMDQ:- There are some patches identified which were required atleast on MSM platform. I am not sure if these are required for any other CQE platform or not. Patchset 1, 3 & 4 commit text describes the problems. Performance related:- I gave one small shot for performance and the numbers were not looking good. So, unless I have tested for performance completely, I should not discuss on performance numbers as of now with this patchset. I can try doing some more performance testing and post the results - though this may take some while. You might also need custom Send Status Configuration. Yes, I will check that once. I think for the single job I/O this may not would have matter much. But sure, I will check on this, if re-configuring is needed. I used below test script for random read/write test. *randwrite-test-script* [global] bs=32k size=1g rw=randwrite direct=1 directory=/data/fiotest Random write results can vary a lot. It is important to know if the eMMC has lots of un-mapped blocks or not. e.g. for ext4 is the "-o discard" option being used. I find I get more consistent results if I always have discards enabled. [file1] filename=singlefile1 *randread-test-script* [global] bs=32k size=1g rw=randread directory=/data/fiotest If you don't set numjobs > 1 then there is little benefit of the queue. Also still need direct=1 Yes, silly me. But still I got lower results with single job then. But anyways let me again check this out. Thanks. [file1] filename=singlefile1 @Adrian, Thanks a lot for pursuing and bringing CMDQ patch series to it's final stages :) Ritesh Harjani (4): mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU mmc: sdhci-msm: Add CQHCI support for sdhci-msm mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable. mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy IRQs on CQE halt .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/cqhci.c | 7 +- drivers/mmc/host/sdhci-msm.c | 121 - 4 files changed, 125 insertions(+), 5 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC 4/4] mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy IRQs on CQE halt
On 8/31/2017 1:05 PM, Adrian Hunter wrote:
On 30/08/17 16:04, Ritesh Harjani wrote:
There is a case when enabling the legacy IRQs and halting CQE is
resuling into a command response interrupt without any command in
progress. This patch handles such case here.
Error signature without this patch:-
mmc0: Got command interrupt 0x0001 even though no command operation
was in progress.
Signed-off-by: Ritesh Harjani
Seems fine, but this is a necessary part of enabling i.e. put all the
sdhci-msm changes into one patch.
Yes, sure.
---
drivers/mmc/host/sdhci-msm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index baa3409..8fdc2c0 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1124,10 +1124,21 @@ void sdhci_msm_cqe_enable(struct mmc_host *mmc)
void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
{
struct sdhci_host *host = mmc_priv(mmc);
+ unsigned long flags;
+ u32 ctrl;
if (host->flags & SDHCI_USE_64_BIT_DMA)
host->desc_sz = 16;
+ spin_lock_irqsave(&host->lock, flags);
+
Could use a comment here.
Ok. Thanks.
+ ctrl = sdhci_readl(host, SDHCI_INT_ENABLE);
+ ctrl |= SDHCI_INT_RESPONSE;
+ sdhci_writel(host, ctrl, SDHCI_INT_ENABLE);
+ sdhci_writel(host, SDHCI_INT_RESPONSE, SDHCI_INT_STATUS);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
sdhci_cqe_disable(mmc, recovery);
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.
Re: [RFC 3/4] mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.
On 8/31/2017 12:12 PM, Adrian Hunter wrote:
On 30/08/17 16:04, Ritesh Harjani wrote:
When CMDQ is halted the HW expects descriptor size to
be same which is using in CMDQ mode.
Thus adjust the desc_sz of sdhci accordingly.
Without this patch below command gives ADMA error
when CQE is enabled.
cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
Signed-off-by: Ritesh Harjani
---
drivers/mmc/host/sdhci-msm.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 346cdfb..baa3409 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -,9 +,29 @@ static u32 sdhci_msm_cqe_irq(struct sdhci_host *host,
u32 intmask)
return 0;
}
+void sdhci_msm_cqe_enable(struct mmc_host *mmc)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+
+ if (host->flags & SDHCI_USE_64_BIT_DMA)
+ host->desc_sz = 12;
This has no effect.
Yes, I added it for the sake of completion.
Sure I will check on this.
+
+ sdhci_cqe_enable(mmc);
+}
+
+void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+
+ if (host->flags & SDHCI_USE_64_BIT_DMA)
+ host->desc_sz = 16;
You can't change the descriptor size this way. If you need 128-bit ADMA
descriptors it must be done in sdhci_setup_host().
Let me again check on this once. I will get back then.
Thanks.
+
+ sdhci_cqe_disable(mmc, recovery);
+}
+
static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
- .enable = sdhci_cqe_enable,
- .disable= sdhci_cqe_disable,
+ .enable = sdhci_msm_cqe_enable,
+ .disable= sdhci_msm_cqe_disable,
};
#ifdef CONFIG_MMC_CQHCI
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.
Re: [RFC 2/4] mmc: sdhci-msm: Add CQHCI support for sdhci-msm
On 8/31/2017 12:55 PM, Adrian Hunter wrote:
On 30/08/17 16:04, Ritesh Harjani wrote:
This adds CQHCI support for sdhci-msm platforms.
Signed-off-by: Ritesh Harjani
---
.../devicetree/bindings/mmc/sdhci-msm.txt | 1 +
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-msm.c | 90 +-
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 0576264..897294f 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -5,6 +5,7 @@ and the properties used by the sdhci-msm driver.
Required properties:
- compatible: Should contain "qcom,sdhci-msm-v4".
+- compatible: "qcom,sdhci-msm-cqe" - Optional in case the controller support
CQE.
- reg: Base address and length of the register in the following order:
- Host controller register map (required)
- SD Core register map (required)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b8c9ea5..a2524c7 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -430,6 +430,7 @@ config MMC_SDHCI_MSM
tristate "Qualcomm SDHCI Controller Support"
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on MMC_SDHCI_PLTFM
+ select MMC_CQHCI
help
This selects the Secure Digital Host Controller Interface (SDHCI)
support present in Qualcomm SOCs. The controller supports
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index df66724..346cdfb 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -23,6 +23,7 @@
#include
#include "sdhci-pltfm.h"
+#include "cqhci.h"
#define CORE_MCI_VERSION 0x50
#define CORE_VERSION_MAJOR_SHIFT 28
@@ -1092,8 +1093,87 @@ static void sdhci_msm_set_clock(struct sdhci_host *host,
unsigned int clock)
__sdhci_msm_set_clock(host, clock);
}
+/*\
+ * *
+ * MSM Command Queue Engine (CQE)*
+ * *
+\*/
+
+static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, u32 intmask)
+{
+ int cmd_error = 0;
+ int data_error = 0;
+
+ if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
+ return intmask;
+
+ cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ return 0;
+}
+
+static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
+ .enable = sdhci_cqe_enable,
+ .disable= sdhci_cqe_disable,
+};
+
+#ifdef CONFIG_MMC_CQHCI
If you select MMC_CQHCI then this #ifdef is not needed
Yes. Thanks.
+static int sdhci_msm_cqe_add_host(struct sdhci_host *host,
+ struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+ struct cqhci_host *cq_host;
+ bool dma64;
+ int ret;
+
+ ret = sdhci_setup_host(host);
+ if (ret)
+ return ret;
+
+ cq_host = cqhci_pltfm_init(pdev);
+ if (IS_ERR(cq_host)) {
+ ret = PTR_ERR(cq_host);
+ dev_err(&pdev->dev, "cqhci-pltfm init: failed: %d\n", ret);
+ goto cleanup;
+ }
+
+ msm_host->mmc->caps2 |= MMC_CAP2_CQE;
If DCMD works you need MMC_CAP2_CQE_DCMD also
Yes, I could not test DCMD. Sure I will check it once.
+ cq_host->ops = &sdhci_msm_cqhci_ops;
+
+ dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
+ if (dma64)
+ cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
+
+ ret = cqhci_init(cq_host, host->mmc, dma64);
+ if (ret) {
+ dev_err(&pdev->dev, "%s: CQE init: failed (%d)\n",
mmc_hostname(host->mmc),
+ ret);
+ goto cleanup;
+ }
+
+ ret = __sdhci_add_host(host);
+ if (ret)
+ goto cleanup;
+
+ dev_info(&pdev->dev, "%s: CQE init: success\n",
mmc_hostname(host->mmc));
+ return ret;
+
+cleanup:
+ sdhci_cleanup_host(host);
+ return ret;
+}
+#else
+static void sdhci_msm_cqe_add_host(struct sdhci_host *host,
+ struct platform_device *pdev)
+{
+ dev_warn(&pdev->dev, "CQE config not enabled, defaulting to sdhci\n");
+ return sdhci_add_host(host);
+}
+#endif /* CONFIG_MMC_CQHCI */
+
static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
+ { .compatible = "qcom,sdhci-msm-cqe" },
Re: [RFC 1/4] mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU
On 8/31/2017 11:31 AM, Adrian Hunter wrote: On 30/08/17 16:04, Ritesh Harjani wrote: Without this patch the CQHCI registers are getting reset again. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/cqhci.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c index 8650a13..2a7351c 100644 --- a/drivers/mmc/host/cqhci.c +++ b/drivers/mmc/host/cqhci.c @@ -262,6 +262,9 @@ static void __cqhci_enable(struct cqhci_host *cq_host) cqhci_writel(cq_host, cqcfg, CQHCI_CFG); + cqcfg |= CQHCI_ENABLE; + cqhci_writel(cq_host, cqcfg, CQHCI_CFG); That doesn't follow the flow in the specification B.6.1. Command Queuing Initialization Sequence. Also in B.3.5 Task List, the spec. says "Changing the value of TDLBA is not allowed when command queue mode is enabled." So you will need to add a quirk for this. Sure. thanks. + cqhci_writel(cq_host, lower_32_bits(cq_host->desc_dma_base), CQHCI_TDLBA); cqhci_writel(cq_host, upper_32_bits(cq_host->desc_dma_base), @@ -271,10 +274,6 @@ static void __cqhci_enable(struct cqhci_host *cq_host) cqhci_set_irqs(cq_host, 0); - cqcfg |= CQHCI_ENABLE; - - cqhci_writel(cq_host, cqcfg, CQHCI_CFG); - mmc->cqe_on = true; if (cq_host->ops->enable) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n
Hi Linus, I think Sergei or someone else was mentioning that before a while ago, but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that will scare people. What do you recommend doing for code that might be built with or without CONFIG_GPIOLIB, should we just encapsulate the part that deals with GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The particular piece of code that I just saw this with is drivers/net/phy/mdio_bus.c. Thanks! -- Florian
Re: [PATCH 13/13] thermal/drivers/hisi: Remove mutex_lock in the code
On Wed, Aug 30, 2017 at 10:47:37AM +0200, Daniel Lezcano wrote:
> The mutex is used to protect against writes in the configuration register.
>
> That happens at probe time, with no possible race yet.
>
> Then when the module is unloaded and at suspend/resume.
>
> When the module is unloaded, it is an userspace operation, thus via a process.
> Suspending the system goes through the freezer to suspend all the tasks
> synchronously before continuing. So it is not possible to hit the suspend ops
> in this driver while we are unloading it.
>
> The resume is the same situation than the probe.
>
> In other words, even if there are several places where we write the
> configuration register, there is no situation where we can write it at the
> same
> time, so far as I can judge
After applied your previous patches, configuration reigster accessing
only happens in the probe and resume functions. So shouldn't have
chance to access it at the same time.
BTW, I verified this patch with system suspend/resume, so far it works
well after system resume back.
> Signed-off-by: Daniel Lezcano
Reviewed-by: Leo Yan
Tested-by: Leo Yan
> ---
> drivers/thermal/hisi_thermal.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b1b086ab..b9e8ee2 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -51,7 +51,6 @@ struct hisi_thermal_sensor {
> };
>
> struct hisi_thermal_data {
> - struct mutex thermal_lock;/* protects register data */
> struct platform_device *pdev;
> struct clk *clk;
> struct hisi_thermal_sensor sensor;
> @@ -196,14 +195,10 @@ static inline void hisi_thermal_hdak_set(void __iomem
> *addr, int value)
>
> static void hisi_thermal_disable_sensor(struct hisi_thermal_data *data)
> {
> - mutex_lock(&data->thermal_lock);
> -
> /* disable sensor module */
> hisi_thermal_enable(data->regs, 0);
> hisi_thermal_alarm_enable(data->regs, 0);
> hisi_thermal_reset_enable(data->regs, 0);
> -
> - mutex_unlock(&data->thermal_lock);
> }
>
> static int hisi_thermal_get_temp(void *__data, int *temp)
> @@ -340,7 +335,6 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> if (!data)
> return -ENOMEM;
>
> - mutex_init(&data->thermal_lock);
> data->pdev = pdev;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> --
> 2.7.4
>
Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
On Fri, 2017-09-01 at 13:22 -0700, Kees Cook wrote: > Using .text.unlikely for refcount exceptions isn't safe because gcc may > move entire functions into .text.unlikely (e.g. in6_dev_get()), which > would cause any uses of a protected refcount_t function to stay inline > with the function, triggering the protection unconditionally: > > .section.text.unlikely,"ax",@progbits > .type in6_dev_get, @function > in6_dev_getx: > .LFB4673: > .loc 2 4128 0 > .cfi_startproc > ... > lock; incl 480(%rbx) > js 111f > .pushsection .text.unlikely > 111:lea 480(%rbx), %rcx > 112:.byte 0x0f, 0xff > .popsection > 113: > > This creates a unique .text section and adds an additional test to the > exception handler to WARN in the case of having none of OF, SF, nor ZF > set so we can see things like this more easily in the future. Closure: gcc-4.8.5 now builds a functional kernel as well, so that aspect of this bug was just a larger a dose of the same toxin. Question below. diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h > index ff871210b9f2..4e44250e7d0d 100644 > --- a/arch/x86/include/asm/refcount.h > +++ b/arch/x86/include/asm/refcount.h > @@ -15,7 +15,7 @@ > * back to the regular execution flow in .text. > */ > #define _REFCOUNT_EXCEPTION \ > - ".pushsection .text.unlikely\n" \ > + ".pushsection .text..refcount\n"\ Why two dots? (.text.refcount_ex?) -Mike
Re: RFC: Revert move default dialect from CIFS to to SMB3
On Fri, Sep 1, 2017 at 7:16 PM, Steve French wrote: > > The default was SMB1 (CIFS) and was recently changed to SMB3. > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1" > etc. on mount. > > We just put together a patch to better explain the default changes > (with additional warning messages) as suggested. > > SMB3 is significantly better than SMB2.1 (supporting encrypted shares > and sessions for example, and requiring support for "secure negotiate") > and some servers require SMB3 minimum as a result, The default shouldn't be about "best and most secure", but "most convenient, while still not actively *IN*secure" So "some servers require 3.0" may be true, but if it's also the case that "most servers still don't do 3.0 at all", then it's a "some" vs "most". Which is the most common one? That should be the default. I realize that eventually we'll have auto-negotiation, but that's clearly not for 4.13. So in the meantime the only issue is what the right default should be without auto-negotiation. So it should be about what the failure rate is. If trying for smb3 has a high failure rate because people simply don't have that yet, then making that the default was clearly the wrong choice. Because being "better" is immaterial if it doesn't work. Linus
Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro
On Fri, 2017-09-01 at 18:35 -0700, David Miller wrote:
> From: Thomas Meyer
> Date: Thu, 31 Aug 2017 16:18:15 +0200
>
> > Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> > candidates.
> > Maybe a coccinelle can catch all of those.
Umm: try scripts/coccinelle/misc/array_size.cocci
Until then, maybe a perl script?
$ git grep --name-only sizeof.*/.*sizeof drivers/net | \
xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\/\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)/ARRAY_SIZE(\1)/g'
gives:
$ git diff --stat drivers/net
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 4 +--
drivers/net/ethernet/mellanox/mlx4/main.c | 8 +++---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 186
+++---
5 files changed, 101 insertions(+), 101 deletions(-)
Re: [PATCH 11/13] thermal/drivers/hisi: Convert long to int
On Wed, Aug 30, 2017 at 10:47:35AM +0200, Daniel Lezcano wrote:
> There is no point to specify the temperature as long variable, the int is
> enough.
>
> Replace all long variables to int, so making the code consistent.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Leo Yan
> ---
> drivers/thermal/hisi_thermal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 68b625c..9eee82b 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -83,12 +83,12 @@ static inline int hisi_thermal_step_to_temp(int step)
> return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
> }
>
> -static inline long hisi_thermal_temp_to_step(long temp)
> +static inline int hisi_thermal_temp_to_step(int temp)
> {
> return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
> }
>
> -static inline long hisi_thermal_round_temp(int temp)
> +static inline int hisi_thermal_round_temp(int temp)
> {
> return hisi_thermal_step_to_temp(
> hisi_thermal_temp_to_step(temp));
> --
> 2.7.4
>
Re: tunnels: Don't apply GRO to multiple layers of encapsulation.
On Thu, Aug 31, 2017 at 6:58 AM, wrote: > [ resend due to mail problems at my end ] > > Hi Jesse, > > The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971, > "tunnels: Don't apply GRO to multiple layers of encapsulation", > to linux-4.1.y seems to have missed a line. > > The 4.1 commit is 066b300e5be43cb61697539e2a3a9aac5afb422f. > > The potentially missing line is: > > - .gro_receive= ipv6_gro_receive, > + .gro_receive= sit_gro_receive, > > > I am not experiencing any bad symptoms. I simply noticed > that the patch introduced a new function, sit_gro_receive, > without introducing any users, and that same patch in > linux-4.4.y does have a user. Thanks for pointing that out. The line you mentioned should indeed be there and seems to have been missed in the backport. The backport was actually done by Sasha, not by me - would you mind sending a patch to him or working with him to fix it?
Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings
From: Haiyang Zhang Date: Fri, 1 Sep 2017 14:30:03 -0700 > This patch set cleans up some unused variables, unnecessary checks. > Also fixed some limit checking of channel number. Series applied.
Re: [PATCH 10/13] thermal/drivers/hisi: Rename and remove unused field
On Wed, Aug 30, 2017 at 10:47:34AM +0200, Daniel Lezcano wrote:
> Rename the 'sensors' field to 'sensor' as we describe only one sensor.
> Remove the 'sensor_temp' as it is no longer used.
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Leo Yan
Tested-by: Leo Yan
> ---
> drivers/thermal/hisi_thermal.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b038d8a..68b625c 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -47,8 +47,6 @@
> struct hisi_thermal_sensor {
> struct hisi_thermal_data *thermal;
> struct thermal_zone_device *tzd;
> -
> - long sensor_temp;
> uint32_t id;
> uint32_t thres_temp;
> };
> @@ -57,9 +55,9 @@ struct hisi_thermal_data {
> struct mutex thermal_lock;/* protects register data */
> struct platform_device *pdev;
> struct clk *clk;
> - struct hisi_thermal_sensor sensors;
> - int irq;
> + struct hisi_thermal_sensor sensor;
> void __iomem *regs;
> + int irq;
> };
>
> /*
> @@ -229,7 +227,7 @@ static const struct thermal_zone_of_device_ops
> hisi_of_thermal_ops = {
> static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
> {
> struct hisi_thermal_data *data = dev;
> - struct hisi_thermal_sensor *sensor = &data->sensors;
> + struct hisi_thermal_sensor *sensor = &data->sensor;
> int temp;
>
> hisi_thermal_alarm_clear(data->regs, 1);
> @@ -240,7 +238,7 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq,
> void *dev)
> dev_crit(&data->pdev->dev, "THERMAL ALARM: %d > %d\n",
>temp, sensor->thres_temp);
>
> - thermal_zone_device_update(data->sensors.tzd,
> + thermal_zone_device_update(data->sensor.tzd,
> THERMAL_EVENT_UNSPECIFIED);
>
> } else if (temp < sensor->thres_temp) {
> @@ -303,7 +301,7 @@ static int hisi_thermal_setup(struct hisi_thermal_data
> *data)
> {
> struct hisi_thermal_sensor *sensor;
>
> - sensor = &data->sensors;
> + sensor = &data->sensor;
>
> /* disable module firstly */
> hisi_thermal_reset_enable(data->regs, 0);
> @@ -376,7 +374,7 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> }
>
> ret = hisi_thermal_register_sensor(pdev, data,
> -&data->sensors,
> +&data->sensor,
> HISI_DEFAULT_SENSOR);
> if (ret) {
> dev_err(&pdev->dev, "failed to register thermal sensor: %d\n",
> @@ -398,7 +396,7 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - hisi_thermal_toggle_sensor(&data->sensors, true);
> + hisi_thermal_toggle_sensor(&data->sensor, true);
>
> return 0;
> }
> @@ -406,7 +404,7 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> static int hisi_thermal_remove(struct platform_device *pdev)
> {
> struct hisi_thermal_data *data = platform_get_drvdata(pdev);
> - struct hisi_thermal_sensor *sensor = &data->sensors;
> + struct hisi_thermal_sensor *sensor = &data->sensor;
>
> hisi_thermal_toggle_sensor(sensor, false);
> hisi_thermal_disable_sensor(data);
> --
> 2.7.4
>
Re: [PATCH 09/13] thermal/drivers/hisi: Remove costly sensor inspection
On Wed, Aug 30, 2017 at 10:47:33AM +0200, Daniel Lezcano wrote:
> The sensor is all setup, bind, resetted, acked, etc... every single second.
>
> That was the way to workaround a problem with the interrupt bouncing again and
> again.
>
> With the following changes, we fix all in one:
>
> - Do the setup, one time, at probe time
>
> - Add the IRQF_ONESHOT, ack the interrupt in the threaded handler
>
> - Remove the interrupt handler
>
> - Set the correct value for the LAG register
>
> - Remove all the irq_enabled stuff in the code as the interruption
>handling is fixed
>
> - Remove the 3ms delay
>
> - Reorder the initialization routine to be in the right order
>
> It ends up to a nicer code and more efficient, the 3-5ms delay is removed from
> the get_temp() path.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 203
> +++--
> 1 file changed, 93 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 3e03908..b038d8a 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -39,6 +39,7 @@
> #define HISI_TEMP_BASE (-6)
> #define HISI_TEMP_RESET (10)
> #define HISI_TEMP_STEP (784)
> +#define HISI_TEMP_LAG(3500)
So I am curious what's the reason to select 3.5'c for lag value? Is
this a heuristics result?
> #define HISI_MAX_SENSORS 4
> #define HISI_DEFAULT_SENSOR 2
> @@ -58,8 +59,6 @@ struct hisi_thermal_data {
> struct clk *clk;
> struct hisi_thermal_sensor sensors;
> int irq;
> - bool irq_enabled;
> -
> void __iomem *regs;
> };
>
> @@ -97,9 +96,40 @@ static inline long hisi_thermal_round_temp(int temp)
> hisi_thermal_temp_to_step(temp));
> }
>
> +/*
> + * The lag register contains 5 bits encoding the temperature in steps.
> + *
> + * Each time the temperature crosses the threshold boundary, an
> + * interrupt is raised. It could be when the temperature is going
> + * above the threshold or below. However, if the temperature is
> + * fluctuating around this value due to the load, we can receive
> + * several interrupts which may not desired.
> + *
> + * We can setup a temperature representing the delta between the
> + * threshold and the current temperature when the temperature is
> + * decreasing.
> + *
> + * For instance: the lag register is 5°C, the threshold is 65°C, when
> + * the temperature reaches 65°C an interrupt is raised and when the
> + * temperature decrease to 65°C - 5°C another interrupt is raised.
> + *
> + * A very short lag can lead to an interrupt storm, a long lag
> + * increase the latency to react to the temperature changes. In our
> + * case, that is not really a problem as we are polling the
> + * temperature.
So here means if we set a long lag value and the interrupt is delayed,
sometimes we even don't receive the interrupt; but this is acceptable
due we are polling the temperature so we still can get the updated
temperature value, right?
> + *
> + * [0:4] : lag register
> + *
> + * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> + *
> + * Min : 0x00 : 0.0 °C
> + * Max : 0x1F : 24.3 °C
> + *
> + * The 'value' parameter is in milliCelsius.
> + */
> static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> {
> - writel(value, addr + TEMP0_LAG);
> + writel((value / HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
> }
>
> static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> @@ -167,71 +197,6 @@ static inline void hisi_thermal_hdak_set(void __iomem
> *addr, int value)
> writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
> }
>
> -static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> - struct hisi_thermal_sensor *sensor)
> -{
> - long val;
> -
> - mutex_lock(&data->thermal_lock);
> -
> - /* disable interrupt */
> - hisi_thermal_alarm_enable(data->regs, 0);
> - hisi_thermal_alarm_clear(data->regs, 1);
> -
> - /* disable module firstly */
> - hisi_thermal_enable(data->regs, 0);
> -
> - /* select sensor id */
> - hisi_thermal_sensor_select(data->regs, sensor->id);
> -
> - /* enable module */
> - hisi_thermal_enable(data->regs, 1);
> -
> - usleep_range(3000, 5000);
> -
> - val = hisi_thermal_get_temperature(data->regs);
> -
> - mutex_unlock(&data->thermal_lock);
> -
> - return val;
> -}
> -
> -static void hisi_thermal_enable_bind_irq_sensor
> - (struct hisi_thermal_data *data)
> -{
> - struct hisi_thermal_sensor *sensor;
> -
> - mutex_lock(&data->thermal_lock);
> -
> - sensor = &data->sensors;
> -
> - /* setting the hdak time */
> - hisi_thermal_hdak_set(data->regs, 0);
> -
> - /* disable module fir
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables
On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh wrote: > Hi Boris, > > On 08/30/2017 12:46 PM, Borislav Petkov wrote: >> >> On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: >>> >>> I was trying to avoid mixing early and no-early set_memory_decrypted() >>> but if >>> feedback is: use early_set_memory_decrypted() only if its required >>> otherwise >>> use set_memory_decrypted() then I can improve the logic in next rev. >>> thanks >> >> >> Yes, I think you should use the early versions when you're, well, >> *early* :-) But get rid of that for_each_possible_cpu() and do it only >> on the current CPU, as this is a per-CPU path anyway. If you need to >> do it on *every* CPU and very early, then you need a separate function >> which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. >> > > I am trying to implement your feedback and now remember why I choose to > use early_set_memory_decrypted() and for_each_possible_cpu loop. These > percpu variables are static. Hence before clearing the C-bit we must > perform the in-place decryption so that original assignment is preserved > after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() > -- which can be used to perform the in-place decryption but we do not have > similar routine for non-early cases. In order to address your feedback, > we have to add similar functions. So far, we have not seen the need for > having such functions except this cases. The approach we have right now > works just fine and not sure if its worth adding new functions. > > Thoughts ? > > [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of > memory Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED? ISTM the "HV shared" bit is incidental.
Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
On Fri, Sep 1, 2017 at 2:43 PM, Ard Biesheuvel
wrote:
> On 1 September 2017 at 21:22, Kees Cook wrote:
>> Using .text.unlikely for refcount exceptions isn't safe because gcc may
>> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
>> would cause any uses of a protected refcount_t function to stay inline
>> with the function, triggering the protection unconditionally:
>>
>> .section.text.unlikely,"ax",@progbits
>> .type in6_dev_get, @function
>> in6_dev_getx:
>> .LFB4673:
>> .loc 2 4128 0
>> .cfi_startproc
>> ...
>> lock; incl 480(%rbx)
>> js 111f
>> .pushsection .text.unlikely
>> 111:lea 480(%rbx), %rcx
>> 112:.byte 0x0f, 0xff
>> .popsection
>> 113:
>>
>> This creates a unique .text section and adds an additional test to the
>> exception handler to WARN in the case of having none of OF, SF, nor ZF
>> set so we can see things like this more easily in the future.
>>
>> Reported-by: Mike Galbraith
>> Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount
>> overflow protection")
>> Signed-off-by: Kees Cook
>> ---
>> arch/x86/Kconfig | 2 +-
>> arch/x86/include/asm/refcount.h | 2 +-
>> arch/x86/mm/extable.c | 7 ++-
>> include/asm-generic/vmlinux.lds.h | 1 +
>> 4 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eaa8ff41f424..c6acdcdb3fc6 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -56,7 +56,7 @@ config X86
>> select ARCH_HAS_MMIO_FLUSH
>> select ARCH_HAS_PMEM_APIif X86_64
>> # Causing hangs/crashes, see the commit that added this change for
>> details.
>> - select ARCH_HAS_REFCOUNTif BROKEN
>> + select ARCH_HAS_REFCOUNT
>> select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
>> select ARCH_HAS_SET_MEMORY
>> select ARCH_HAS_SG_CHAIN
>> diff --git a/arch/x86/include/asm/refcount.h
>> b/arch/x86/include/asm/refcount.h
>> index ff871210b9f2..4e44250e7d0d 100644
>> --- a/arch/x86/include/asm/refcount.h
>> +++ b/arch/x86/include/asm/refcount.h
>> @@ -15,7 +15,7 @@
>> * back to the regular execution flow in .text.
>> */
>> #define _REFCOUNT_EXCEPTION\
>> - ".pushsection .text.unlikely\n" \
>> + ".pushsection .text..refcount\n"\
>
> You could also use a .subsection here: those are always emitted out of
> line, but into the same section.
I considered it (especially after looking to see how you handled it in
the arm64 port) but decided against it in favor of collecting them all
at the end with .text.unlikely.
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH 08/13] thermal/drivers/hisi: Fix configuration register setting
On Wed, Aug 30, 2017 at 10:47:32AM +0200, Daniel Lezcano wrote:
> The TEMP0_CFG configuration register contains different field to set up the
> temperature controller. However in the code, nothing prevents a setup to
> overwrite the previous one: eg. writing the hdak value overwrites the sensor
> selection, the sensor selection overwrites the hdak value.
>
> In order to prevent such thing, use a regmap-like mechanism by reading the
> value before, set the corresponding bits and write the result.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index d77a938..3e03908 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -132,19 +132,39 @@ static inline void hisi_thermal_enable(void __iomem
> *addr, int value)
> writel(value, addr + TEMP0_EN);
> }
>
> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> {
> - writel((sensor << 12), addr + TEMP0_CFG);
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> }
>
> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +/*
> + * Temperature configuration register - Sensor selection
> + *
> + * Bits [19:12]
> + *
> + * 0x0: local sensor (default)
> + * 0x1: remote sensor 1 (ACPU cluster 1)
> + * 0x2: remote sensor 2 (ACPU cluster 0)
> + * 0x3: remote sensor 3 (G3D)
> + */
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> {
> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> + writel(readl(addr + TEMP0_CFG) | (sensor << 12), addr + TEMP0_CFG);
nitpick: maybe it's better to firstly clear related bits and then set
value?
> }
>
> +/*
> + * Temperature configuration register - Hdak conversion polling interval
> + *
> + * Bits [5:4]
> + *
> + * 0x0 : 0.768 ms
> + * 0x1 : 6.144 ms
> + * 0x2 : 49.152 ms
> + * 0x3 : 393.216 ms
> + */
> static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> {
> - writel(value, addr + TEMP0_CFG);
> + writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
Ditto.
> }
>
> static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> --
> 2.7.4
>
Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers
On Sat, Sep 02, 2017 at 10:09:15AM +0800, Leo Yan wrote:
> On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> > Hopefully, the function name can help to clarify the semantic of the
> > operations
> > when writing in the register.
> >
> > Signed-off-by: Daniel Lezcano
> > ---
> > drivers/thermal/hisi_thermal.c | 96
> > +++---
> > 1 file changed, 72 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> > index 6f0dab1..d77a938 100644
> > --- a/drivers/thermal/hisi_thermal.c
> > +++ b/drivers/thermal/hisi_thermal.c
> > @@ -26,6 +26,7 @@
> >
> > #include "thermal_core.h"
> >
> > +#define TEMP0_LAG (0x0)
> > #define TEMP0_TH (0x4)
> > #define TEMP0_RST_TH (0x8)
> > #define TEMP0_CFG (0xC)
> > @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
> > hisi_thermal_temp_to_step(temp));
> > }
> >
> > +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> > +{
> > + writel(value, addr + TEMP0_LAG);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> > +{
> > + writel(value, addr + TEMP0_INT_CLR);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> > +{
> > + writel(value, addr + TEMP0_INT_EN);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> > +{
> > + writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> > +{
> > +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> > +{
> > +writel(value, addr + TEMP0_RST_MSK);
> > +}
> > +
> > +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> > +{
> > + writel(value, addr + TEMP0_EN);
> > +}
> > +
> > +static inline void hisi_thermal_sensor_select(void __iomem *addr, int
> > sensor)
> > +{
> > + writel((sensor << 12), addr + TEMP0_CFG);
> > +}
> > +
> > +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> > +{
> > + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> > +}
> > +
> > +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> > +{
> > + writel(value, addr + TEMP0_CFG);
> > +}
>
> hdak and sensor id setting share the same one register, so it's
> possible to overwrite their value with each other. And for hdak
> setting, it should offset 4 bits.
>
> The issues are exists in old code yet but not introduce by this
> patch. Could fix these issues as well in this patch?
Have seen the mentioned issues have been fixed in patch 0008. So have
no more question at here.
[...]
Thanks,
Leo Yan
Re: RFC: Revert move default dialect from CIFS to to SMB3
On Fri, Sep 1, 2017 at 2:45 PM, Linus Torvalds wrote: > On Fri, Sep 1, 2017 at 11:23 AM, L. A. Walsh wrote: >>Why be incompatible with the majority of Windows installations? >> I.e. If you really want to up security from 1.0 (not adverse to that), >> then why not go to 2.1 as used by Win7? Win7 is still in support >> from MS -- and they haven't indicated a need to upgrade to 3.x for >> security reasons. 3.x may have new security features, no argument, but >> that doesn't mean 2.1, is insecure. > > I'm certainly ok with changing the default to 2.1 if that helps people. > > Is that actually likely to help the people who now see problems with > the existing 3.0 default? > > I don't know the exact security issue details with cifs, but I _think_ > it was explicitly _only_ smb-1.0, right? The default was SMB1 (CIFS) and was recently changed to SMB3. The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1" etc. on mount. We just put together a patch to better explain the default changes (with additional warning messages) as suggested. SMB3 is significantly better than SMB2.1 (supporting encrypted shares and sessions for example, and requiring support for "secure negotiate") and some servers require SMB3 minimum as a result, but it was agreed at the last test event to eventually support multi-dialect negotiation (for which SMB2.1 e.g. Windows 7, would be the oldest and least secure dialect we would support) but in this interim stage we had to pick one, and the improvements in SMB3 (over SMB2.1) tipped the balance. In 4.14 we will likely have the ability to more securely do multi-dialect negotiation, and this issue of SMB2.1 vs. SMB3 will be moot as the server will choose its most recent dialect. -- Thanks, Steve
Re: [PATCH v3 2/5] dt-bindings: input: Add document bindings for mtk-pmic-keys
On Thu, 2017-08-31 at 14:52 -0500, Rob Herring wrote:
> On Fri, Aug 25, 2017 at 02:32:30PM +0800, Chen Zhong wrote:
> > This patch adds the device tree binding documentation for the MediaTek
> > pmic keys found on PMIC MT6397/MT6323.
> >
> > Signed-off-by: Chen Zhong
> > ---
> > .../devicetree/bindings/input/mtk-pmic-keys.txt| 38
> >
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > new file mode 100644
> > index 000..100ec44
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > @@ -0,0 +1,38 @@
> > +MediaTek MT6397/MT6323 PMIC Keys Device Driver
> > +
> > +There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
> > +and homekey. The key functions are defined as the subnode of the function
> > +node provided by MT6397/MT6323 PMIC that is being defined as one kind
> > +of Muti-Function Device (MFD)
> > +
> > +For MT6397/MT6323 MFD bindings see:
> > +Documentation/devicetree/bindings/mfd/mt6397.txt
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
> > +- linux,keycodes: Specifies the numeric keycode values to
> > + be used for reporting keys presses. The array can
> > + contain up to 2 entries.
> > +
> > +Optional Properties:
> > +- wakeup-source: each key can be used as a wakeup source.
>
> wakeup-source is defined as a boolean.
Hi Rob,
Could I modify it as this?
mediatek,wakeup-keys = <1>, <0>;
wakeup-source;
Thanks.
>
> > +- mediatek,long-press-mode: Long press key shutdown setting, 1 for
> > + pwrkey only, 2 for pwrkey/homekey together, others for disabled.
> > +- debounce-interval: Long press key shutdown debouncing interval time
> > + in seconds. 0/1/2/3 for 8/11/14/5 seconds. If not specified defaults to
> > 0.
> > +
> > +Example:
> > +
> > + pmic: mt6397 {
> > + compatible = "mediatek,mt6397";
> > +
> > + ...
> > +
> > + mt6397keys: mt6397keys {
> > + compatible = "mediatek,mt6397-keys";
> > + linux,keycodes = , ;
> > + wakeup-source = <1>, <0>;
> > + mediatek,long-press-mode = <1>;
> > + debounce-interval = <0>;
> > + };
> > + };
> > --
> > 1.7.9.5
> >
Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver
On 08/25/2017 10:51 AM, Al Cooper wrote: > Add a new USB Phy driver for Broadcom STB SoCs. This driver > supports Broadcom STB ARM SoCs. This driver in > combination with the Broadcom STB ohci, ehci and xhci > drivers will enable USB1.1, USB2.0 and USB3.0 support. > This Phy driver also supports the Broadcom BDC gadget > driver. Thanks Al! Kishon, feel free to merge everything through your tree there should not be any conflicts with drivers/soc/bcm/brcmstb/common.c and include/linux/soc/brcmstb/brcmstb.h. > > Changes since v4: > - MIPS support was dropped, so remove MIPS specific code > in the brcmusb_readl/brcmusb_writel routines. > - Use readl/writel instead of readl_relaxed/writel_relaxed. > - Remove double blank lines between some functions. > - Remove support for obselete phy phandle argument. > > Changes since v3: > - Removed MIPS support because there is such a small > amount of code that is common to both ARM and MIPS. > I'll create a separate MIPS driver in the future. > - Have the Kconfig selection for this driver also select > "CONFIG_SOC_BRCMSTB" which contains needed functions. > - Change device tree properties to use "brcm,has_xhci" and > "brcm,has_eohci" to determine if the phy contains > a xhci phy, and e/ohci phy or both. > - Change the phy xlate routine to return an error instead > of NULL for a requested phy that doesn't exist. > - Moved some probe functionality into it's own funtion to > simplify the many "if (has_xhci)" statements. > > Changes since v2: > - Fix kbuild errors by changing Kconfig so the driver > only builds for ARCH_BRCMSTB || BMIPS_GENERIC systems > > Changes since v1: > - Rebased to next > - Add Kconfig entry to build the driver > - Commented all delays > - Split out sysfs functionality in separate patch > - Removed parsing of old obselete device tree properties > - Changed device property "device" to "dr_mode" using > standard values "host" and "peripheral" along with new > values "drd" and "typec-pd" > - Add ability to handle the standard PHY_TYPE_USB2 and > PHY_TYPE_USB3 arguments passed in by phy consumers. > - Moved phy_provider_register() to end of probe routine > > Al Cooper (4): > soc: brcmstb: Add Product ID and Family ID helper functions > dt-bindings: Add Broadcom STB USB PHY binding document > phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver > phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or > device > > .../bindings/phy/brcm,brcmstb-usb-phy.txt | 43 + > MAINTAINERS|7 + > drivers/phy/broadcom/Kconfig | 13 + > drivers/phy/broadcom/Makefile |3 + > drivers/phy/broadcom/phy-brcm-usb-init.c | 1007 > > drivers/phy/broadcom/phy-brcm-usb-init.h | 50 + > drivers/phy/broadcom/phy-brcm-usb.c| 458 + > drivers/soc/bcm/brcmstb/common.c | 12 + > include/linux/soc/brcmstb/brcmstb.h| 10 + > 9 files changed, 1603 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt > create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.c > create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.h > create mode 100644 drivers/phy/broadcom/phy-brcm-usb.c > -- Florian
Re: [PATCH V5 1/4] soc: brcmstb: Add Product ID and Family ID helper functions
On 08/25/2017 10:51 AM, Al Cooper wrote:
> Signed-off-by: Al Cooper
Acked-by: Florian Fainelli
> ---
> drivers/soc/bcm/brcmstb/common.c| 12
> include/linux/soc/brcmstb/brcmstb.h | 10 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/soc/bcm/brcmstb/common.c
> b/drivers/soc/bcm/brcmstb/common.c
> index b6195fd..184dbf5 100644
> --- a/drivers/soc/bcm/brcmstb/common.c
> +++ b/drivers/soc/bcm/brcmstb/common.c
> @@ -40,6 +40,18 @@ bool soc_is_brcmstb(void)
> return of_match_node(brcmstb_machine_match, root) != NULL;
> }
>
> +u32 brcmstb_get_family_id(void)
> +{
> + return family_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_family_id);
> +
> +u32 brcmstb_get_product_id(void)
> +{
> + return product_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_product_id);
> +
> static const struct of_device_id sun_top_ctrl_match[] = {
> { .compatible = "brcm,bcm7125-sun-top-ctrl", },
> { .compatible = "brcm,bcm7346-sun-top-ctrl", },
> diff --git a/include/linux/soc/brcmstb/brcmstb.h
> b/include/linux/soc/brcmstb/brcmstb.h
> index 337ce41..23e4dc9 100644
> --- a/include/linux/soc/brcmstb/brcmstb.h
> +++ b/include/linux/soc/brcmstb/brcmstb.h
> @@ -1,10 +1,20 @@
> #ifndef __BRCMSTB_SOC_H
> #define __BRCMSTB_SOC_H
>
> +#define BRCM_ID(reg) ((u32)reg >> 28 ? (u32)reg >> 16 : (u32)reg >> 8)
> +#define BRCM_REV(reg)((u32)reg & 0xff)
> +
> /*
> * Bus Interface Unit control register setup, must happen early during boot,
> * before SMP is brought up, called by machine entry point.
> */
> void brcmstb_biuctrl_init(void);
>
> +/*
> + * Helper functions for getting family or product id from the
> + * SoC driver.
> + */
> +u32 brcmstb_get_family_id(void);
> +u32 brcmstb_get_product_id(void);
> +
> #endif /* __BRCMSTB_SOC_H */
>
--
Florian
Re: [PATCH 2/2] ARM: dts: Add the PWM node to Cygnus
On 08/31/2017 01:10 PM, Scott Branden wrote:
> pwm node is correct.
>
>
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This is connected up to the backlight on 911360_entphn, which we'll
>> need for a panel driver. For now, leave the node disabled in the
>> shared dtsi.
>>
>> Signed-off-by: Eric Anholt
> Acked-by: Scott Branden
Applied to devicetree/next:
https://github.com/Broadcom/stblinux/commit/31807d46f85c4d86ef3b6df9c5a4e69d35f75bc0
>> ---
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 74f73ff24aec..b9a654d733ae 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -585,6 +585,14 @@
>> status = "disabled";
>> };
>> +pwm: pwm@180aa500 {
>> +compatible = "brcm,kona-pwm";
>> +reg = <0x180aa500 0xc4>;
>> +#pwm-cells = <3>;
>> +clocks = <&asiu_clks BCM_CYGNUS_ASIU_PWM_CLK>;
>> +status = "disabled";
>> +};
>> +
>> keypad: keypad@180ac000 {
>> compatible = "brcm,bcm-keypad";
>> reg = <0x180ac000 0x14c>;
>
--
Florian
Re: [PATCH 1/2] ARM: dts: Add the CLCD controller to Cygnus.
On 08/31/2017 01:16 PM, Scott Branden wrote:
> Hi Eric,
>
> mode is correct, location in file needs to be moved.
>
>
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This doesn't yet enable it on any particular platform, as we still
>> need a panel driver for bcm911360_entphn.
>>
>> Signed-off-by: Eric Anholt
>> ---
>>
>> These bits are just carving off a little bit of my 911360_entphn panel
>> series, to reduce conflicts when rebasing (which I just did for
>> testing pl111 changes for cygnus regressions). I'm waiting to get my
>> current RPi panel driver in before working on the 911360 panel again.
>>
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 7c957ea06c66..74f73ff24aec 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -575,6 +575,16 @@
>> status = "disabled";
>> };
>> +clcd: clcd@180a {
> please place in correct address ordered location in file
I moved it right above the v3d node to keep the nodes ordered by unit
address, please check the result here:
https://github.com/Broadcom/stblinux/commit/4d1e42c6b9d28ce7b74d92258435f9d16834ae75
>> +compatible = "arm,pl111", "arm,primecell";
>> +reg = <0x180a 0x1000>;
>> +interrupts = ;
>> +interrupt-names = "combined";
>> +clocks = <&axi41_clk>, <&apb_clk>;
>> +clock-names = "clcdclk", "apb_pclk";
>> +status = "disabled";
>> +};
>> +
>> keypad: keypad@180ac000 {
>> compatible = "brcm,bcm-keypad";
>> reg = <0x180ac000 0x14c>;
>
--
Florian
Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers
On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> Hopefully, the function name can help to clarify the semantic of the
> operations
> when writing in the register.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 96
> +++---
> 1 file changed, 72 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 6f0dab1..d77a938 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -26,6 +26,7 @@
>
> #include "thermal_core.h"
>
> +#define TEMP0_LAG(0x0)
> #define TEMP0_TH (0x4)
> #define TEMP0_RST_TH (0x8)
> #define TEMP0_CFG(0xC)
> @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
> hisi_thermal_temp_to_step(temp));
> }
>
> +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_LAG);
> +}
> +
> +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_CLR);
> +}
> +
> +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_EN);
> +}
> +
> +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> +{
> + writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> +}
> +
> +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> +{
> +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> +}
> +
> +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> +{
> +writel(value, addr + TEMP0_RST_MSK);
> +}
> +
> +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_EN);
> +}
> +
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +{
> + writel((sensor << 12), addr + TEMP0_CFG);
> +}
> +
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +{
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> +}
> +
> +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_CFG);
> +}
hdak and sensor id setting share the same one register, so it's
possible to overwrite their value with each other. And for hdak
setting, it should offset 4 bits.
The issues are exists in old code yet but not introduce by this
patch. Could fix these issues as well in this patch?
> +
> static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
>struct hisi_thermal_sensor *sensor)
> {
> @@ -104,22 +155,21 @@ static long hisi_thermal_get_sensor_temp(struct
> hisi_thermal_data *data,
> mutex_lock(&data->thermal_lock);
>
> /* disable interrupt */
> - writel(0x0, data->regs + TEMP0_INT_EN);
> - writel(0x1, data->regs + TEMP0_INT_CLR);
> + hisi_thermal_alarm_enable(data->regs, 0);
> + hisi_thermal_alarm_clear(data->regs, 1);
>
> /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 0);
>
> /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>
> /* enable module */
> - writel(0x1, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 1);
>
> usleep_range(3000, 5000);
>
> - val = readl(data->regs + TEMP0_VALUE);
> - val = hisi_thermal_step_to_temp(val);
> + val = hisi_thermal_get_temperature(data->regs);
>
> mutex_unlock(&data->thermal_lock);
>
> @@ -136,29 +186,27 @@ static void hisi_thermal_enable_bind_irq_sensor
> sensor = &data->sensors;
>
> /* setting the hdak time */
> - writel(0x0, data->regs + TEMP0_CFG);
> + hisi_thermal_hdak_set(data->regs, 0);
>
> /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_RST_MSK);
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_reset_enable(data->regs, 0);
> + hisi_thermal_enable(data->regs, 0);
>
> /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>
> /* enable for interrupt */
> - writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FF00,
> -data->regs + TEMP0_TH);
> + hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
>
> - writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET),
> -data->regs + TEMP0_RST_TH);
> + hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
>
> /* enable module */
> - writel(0x1, data->regs + TEMP0_RST_MSK);
> - writel(0x1, data->regs + TEMP0_EN);
> -
> - writel(0x0, data->regs + TEMP0_INT_CLR);
>
Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
> Hi,
>
> On 01/09/17 02:19, Stefan Bruens wrote:
> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
> >> Hi,
> >>
> >> On 31/08/17 00:36, Stefan Brüns wrote:
> >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> >>> reduced amount of physical channels. Add the proper config data
> >>> and compatible string to support it.
> >>
> >> ...
> >>
> >>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> >>> index 5f4eee4513e5..6a17c5d63582 100644
> >>> --- a/drivers/dma/sun6i-dma.c
> >>> +++ b/drivers/dma/sun6i-dma.c
> >>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =
> >>> {
> >>>
> >>> .nr_max_vchans = 34,
> >>> .dmac_variant= DMAC_VARIANT_H3,
> >>>
> >>> };
> >>>
> >>> +
> >>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> >>> + .nr_max_channels = 8,
> >>> + .nr_max_requests = 27,
> >>> + .nr_max_vchans = 38,
> >>> + .dmac_variant= DMAC_VARIANT_H3,
> >>>
> >>> };
> >>>
[...]
> > There are also the incompatibilities in the "DMA channel configuration
> > register" (burst length; burst width; burst length field offset).
> >
> > We can either have 3 different compatible strings, or another property for
> > the register model.
>
> The latter is usually frowned upon, using separate compatible strings
> for each group of SoCs is the way to go here.
Just for clarification, I was not talking about a property in the devicetree,
but about a struct member in the config data, i.e. the .dmac_variant above.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi
hi brian, On 09/02/2017 08:47 AM, Brian Norris wrote: On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote: Currently we are using edev->dev drvdata to get rk3399-dmc data, but it would be inited to edev in devfreq_event_add_edev. So we need to clear the edev->dev drvdata before enabling dfi, to prevent dfi from getting the wrong rk3399-dmc data when the irq triggered too early. Your description doesn't match your code. You say you're clearing evdev->dev driver data but... Signed-off-by: Jeffy Chen --- drivers/devfreq/rk3399_dmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c index 1b89ebbad02c..12f9f03f349f 100644 --- a/drivers/devfreq/rk3399_dmc.c +++ b/drivers/devfreq/rk3399_dmc.c @@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev) rk3399_devfreq_dmc_profile.initial_freq = data->rate; + platform_set_drvdata(pdev, NULL); ...here you're only clearing the drvdata for the platform device. Is that a mistake? (Hint: that's not what you uploaded on the Chromium OS instance, where you presumably tested this.) And if you're really trying to do what your commit message says: We're having two different files fight over who owns the edev drvdata? That seems like a big no-no. We should work out who's the real owner of 'drvdata', and find some other solution for the others. sorry, indeed...it turns out the upstream dmc driver is not using dfi(it's simple_onfemand below ;)... so we don't need thus patch for upstream kernel...or maybe we should submit other cros patches(contains the one causes this issue, and this patch) Brian data->devfreq = devm_devfreq_add_device(dev, &rk3399_devfreq_dmc_profile, "simple_ondemand", -- 2.11.0
Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro
From: Thomas Meyer
Date: Thu, 31 Aug 2017 16:18:15 +0200
> Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> candidates.
> Maybe a coccinelle can catch all of those.
>
> Signed-off-by: Thomas Meyer
Applied, thanks.
Re: [PATCH][net-next] net: qualcomm: rmnet: remove unused variable priv
From: Colin King
Date: Thu, 31 Aug 2017 15:07:27 +0100
> From: Colin Ian King
>
> priv is being assigned but is never used, so remove it.
>
> Cleans up clang build warning:
> "warning: Value stored to 'priv' is never read"
>
> Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial
> implementation")
> Signed-off-by: Colin Ian King
Applied.
Re: [PATCH] net: phy: bcm7xxx: make array bcm7xxx_suspend_cfg static, reduces object code size
From: Colin King Date: Thu, 31 Aug 2017 14:57:15 +0100 > From: Colin Ian King > > Don't populate the array bcm7xxx_suspend_cfg A on the stack, instead > make it static. Makes the object code smaller by over 300 bytes: > > Before: >text data bss dec hex filename >6351 8146 0 1449738a1 drivers/net/phy/bcm7xxx.o > > After: >text data bss dec hex filename >5986 8210 0 141963774 drivers/net/phy/bcm7xxx.o > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH net-next v6] net: stmmac: Delete dead code for MDIO registration
From: Romain Perier
Date: Thu, 31 Aug 2017 15:53:03 +0200
> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging function in
> stmmac_mdio_register").
> It was previously showing information about the type of the IRQ, if it's
> polled, ignored or a normal interrupt. As we don't want information loss,
> I have moved this code to phy_attached_print().
>
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in
> stmmac_mdio_register")
> Signed-off-by: Romain Perier
You'll need to respin this against net-next as phy_attached_print() has had
some changes recently.
Thanks.
Re: [PATCH 23/25] ALSA/dummy: Replace tasklet with softirq hrtimer
On p 1 2017 20:58, Takashi Iwai wrote: >From 07d61ba2a1c0e06e914443225e194d99f2d8c58d Mon Sep 17 00:00:00 2001 From: Takashi Sakamoto Date: Fri, 1 Sep 2017 19:10:18 +0900 Subject: [PATCH] ALSA: dummy: avoid stall due to a call of hrtimer_cancel() on a callback of hrtimer A call of 'htrimer_cancel()' on a callback of hrtimer brings endless loop because 'struct hrtimer_clock_base.running' is not NULL on the callback. In hrtimer subsystem, this member is used to indicate the instance of hrtimer gets callbacks and there's a helper function, 'hrtimer_callback_running()' to check it. ALSA dummy driver uses hrtimer to emulate hardware interrupt per period of PCM buffer. When XRUN occurs on PCM substream, in a call of 'snd_pcm_period_elapsed()', 'struct snd_pcm_ops.stop()' is called to stop the substream. In current implementation, 'hrtimer_cancel()' is used to wait for cancellation of hrtimer. However, as described, this brings endless loop. It's not only about XRUN. When the stream finishes the draining, it stops the stream gracefully -- that is the very normal operation. I overlooked it. Thanks for your indication. For this problem, this commit uses 'hrtimer_callback_running()' to detect whether to be on a callback of hrtimer or not, then skip cancellation of hrtimer in hrtimer callbacks. Furthermore, at a case of XRUN, hrtimer callback returns HRTIMER_NORESTART after a call of 'snd_pcm_period_elapsed()' to discontinue hrtimr because cancellation is skipped. Signed-off-by: Takashi Sakamoto It's better to fold the fix into the original patch instead of introducing a bug and fixing it. Yep. I request the authors to include this fix. Well, in sound subsystem, there're a few drivers which uses hrtimer: - snd-pcsp - snd-sh-dac-audio - snd-soc-imx-pcm-fiq As a quick glance, 'snd-sh-dac-audio' includes the same bug, too. Additionally, 'snd-soc-imx-pcm-fiq' maintains hrtimer with loose manner in a point of state of PCM substream and it shall gain the same bug if improved. Later, I posted some patches for them. Thanks Takashi Sakamoto
Re: [PATCH] f2fs: avoid needless inode updates
Please ignore this patch. Thanks, On 09/01, Jaegeuk Kim wrote: > If i_size wan't change at all, we don't need to write inode during fsync. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/f2fs.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > index 4b993961d81d..0d76b572484a 100644 > --- a/fs/f2fs/f2fs.h > +++ b/fs/f2fs/f2fs.h > @@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct > inode *inode, int dsync) > spin_unlock(&sbi->inode_lock[DIRTY_META]); > return ret; > } > - if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) || > - file_keep_isize(inode) || > - i_size_read(inode) & PAGE_MASK) > - return false; > - return F2FS_I(inode)->last_disk_size == i_size_read(inode); > + if (F2FS_I(inode)->last_disk_size == i_size_read(inode)) > + return true; > + > + return is_inode_flag_set(inode, FI_AUTO_RECOVER) && > + !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK); > } > > static inline int f2fs_readonly(struct super_block *sb) > -- > 2.14.0.rc1.383.gd1ce394fe2-goog
Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi
On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote: > Currently we are using edev->dev drvdata to get rk3399-dmc data, but > it would be inited to edev in devfreq_event_add_edev. > > So we need to clear the edev->dev drvdata before enabling dfi, to > prevent dfi from getting the wrong rk3399-dmc data when the irq > triggered too early. Your description doesn't match your code. You say you're clearing evdev->dev driver data but... > Signed-off-by: Jeffy Chen > --- > > drivers/devfreq/rk3399_dmc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c > index 1b89ebbad02c..12f9f03f349f 100644 > --- a/drivers/devfreq/rk3399_dmc.c > +++ b/drivers/devfreq/rk3399_dmc.c > @@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device > *pdev) > > rk3399_devfreq_dmc_profile.initial_freq = data->rate; > > + platform_set_drvdata(pdev, NULL); ...here you're only clearing the drvdata for the platform device. Is that a mistake? (Hint: that's not what you uploaded on the Chromium OS instance, where you presumably tested this.) And if you're really trying to do what your commit message says: We're having two different files fight over who owns the edev drvdata? That seems like a big no-no. We should work out who's the real owner of 'drvdata', and find some other solution for the others. Brian > data->devfreq = devm_devfreq_add_device(dev, > &rk3399_devfreq_dmc_profile, > "simple_ondemand", > -- > 2.11.0 > >
Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote: > Hi, > > On 01/09/17 02:19, Stefan Bruens wrote: > > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote: > >> Hi, > >> > >> On 31/08/17 00:36, Stefan Brüns wrote: [...] > > > > For these 3 properties it likely is a good idea, but we would IMHO still > > have to care for the differences in the register settings: > > > > - A31 does not have a clock autogating register > > - A23 and A83t does have one at offset 0x20 > > - A64, H3, H5 and R40 have it at offset 0x28 > > Fair enough - I didn't look too closely at your new changes, especially > why it apparently worked before. > But as your list shows, we would only need one compatible string per > line - in the driver - to cover all SoCs (and possibly future SoCs!), > and do the rest via the properties. > We can't use the existing h3 compatible string or touch the already > existing SoCs and compatible strings, of course, but I guess > the A64, R40 and future SoCs could make use of a new (generic?) string. > > > There are also the incompatibilities in the "DMA channel configuration > > register" (burst length; burst width; burst length field offset). > > > > We can either have 3 different compatible strings, or another property for > > the register model. > > The latter is usually frowned upon, using separate compatible strings > for each group of SoCs is the way to go here. > > > For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction > > is a better option - it can encode the allowed DRQ numbers much better > > (e.g. for H3, the highest source DRQ is 24). The DRQ field in the channel > > configuration register is 5 bits, so the hightest port/DRQ number is 31. > > So looking more closely at the manual and the code my understanding is > that nr_max_requests is more or less some rough molly guard to prevent > wrong settings? Derived from the DRQ table in the manual? > So that trying to program port 28 on an H3 would fail? > But source port 25 or dest port 26 wouldn't be caught by this check, > though they would still be "illegal" according to the manual. (Which we > are not sure of, I guess, it may just not be documented) > So I wonder if this nr_max_requests is useful at all, and we should just > check that it fits into 5 bits and assume that the DT has superior > knowledge of what's allowed and what not. > Now I see what you mean with the bitmask (to cover those gaps), but I am > bit sceptical if that is actually useful. After all the DRQ number would > be coming from the DT, which we can surely trust. > > And nr_max_vchans seems to describe the sum of documented DRQs, to just > limit the memory allocation? So this could become just 64 to cover all > possible cases without SoC specific configuration at all? Yes, thats my understanding as well. Allocating a few excess channels would waste a few kBytes (AFAICS 304 bytes per channel on 64bit). > > For aw,max_channels my first thought is - why max? is it variable? is > > there a min_channels? My suggestion would be (in order of preference): > > "aw,channels", "aw,dma_channels", "aw,available_channels". > > Sure, actually looking at Documentation/devicetree/bindings/dma/dma.txt > I think we can even use the generic "dma-channels" property described > there. And possibly the same with "dma-requests", should we keep this. > > So summarizing this: > - We create a new compatible string, which drives an H3 compatible DMA > (clock autogating at 0x28, 64-bit data width capable). This name could > either be generic, or actually "allwinner,sun50i-a64-dma". > - This one sets nr_max_requests to 31 and nr_max_vchans to 64. > - Alternatively we expose those values in the DT as properties. > - We take the number of DMA channels from the (now required) > "dma-channels" property. > - We let the A64 (and R40?) use this new binding. > - Any future SoC which is close enough can then just piggy-back on this. > - Any future *changes* in the Allwinner DMA device which require driver > changes create a new compatible string, but still keep the above > semantics. Chances are that there are more than one SoC using this kind > of new DMA device, so they would work out of the box. > > Does that make sense? > I am happy to provide the code for that, based on your H3 rework. Sounds good for me. I will send a cleaned up series later. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Re: [PATCH] sched: reset sysctl_sched_time_avg to default when
Yep, that is the first place I considered to set the limit, but that would
break KABI ?
Thanks,
Ethan
On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote:
>> System will hang if user set sysctl_sched_time_avg to 0 by
>>
>> [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
>>
>> Stack traceback for pid 0
>> 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
>> 883f7ccc3ae8 0018 810c4dd0
>> 00017800 883f7ccc3d78 0003 883f7ccc3bf8
>> 810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
>> Call Trace:
>> [] ? update_group_capacity+0x110/0x200
>> [] ? update_sd_lb_stats+0x109/0x600
>> [] ? find_busiest_group+0x47/0x530
>> [] ? load_balance+0x194/0x900
>> [] ? update_rq_clock.part.83+0x1a/0xe0
>> [] ? rebalance_domains+0x152/0x290
>> [] ? run_rebalance_domains+0xdc/0x1d0
>> [] ? __do_softirq+0xfb/0x320
>> [] ? irq_exit+0x125/0x130
>> [] ? scheduler_ipi+0x97/0x160
>> [] ? smp_reschedule_interrupt+0x29/0x30
>> [] ? reschedule_interrupt+0x6e/0x80
>> [] ? cpuidle_enter_state+0xcc/0x230
>> [] ? cpuidle_enter_state+0x9c/0x230
>> [] ? cpuidle_enter+0x17/0x20
>> [] ? cpu_startup_entry+0x38c/0x420
>> [] ? start_secondary+0x173/0x1e0
>>
>> Because divide-by-zero error happens in function
>>
>> update_group_capacity()
>> update_cpu_capacity()
>> scale_rt_capacity()
>> {
>> ...
>> total = sched_avg_period() + delta;
>> used = div_u64(avg, total);
>> ...
>> }
>>
>> Seems this issue could be reproduced on all I tried stable 4.1 - last
>> kernel.
>>
>> To fix this issue, reset sysctl_sched_time_avg to default value
>> MSEC_PER_SEC if user input invalid value in function
>>
>> sched_avg_period()
>>
>> Reported-by: James Puthukattukaran
>> Signed-off-by: Ethan Zhao
>> ---
>> Tested on stable 4.1, compiled on stable 4.13-rc5
>> kernel/sched/sched.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index eeef1a3..b398560 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -1620,6 +1620,9 @@ static inline void rq_last_tick_reset(struct rq *rq)
>>
>> static inline u64 sched_avg_period(void)
>> {
>> + if (unlikely(sysctl_sched_time_avg <= 0))
>> + sysctl_sched_time_avg = MSEC_PER_SEC;
>> +
>
> Sight, no.. you can set limits in the sysctl table.
Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files
Hi Josh, On Tue, Aug 29, 2017 at 01:05:33PM -0500, Josh Poimboeuf wrote: > Many of the x86 crypto functions use RBP as a temporary register. This > breaks frame pointer convention, and breaks stack traces when unwinding > from an interrupt in the crypto code. > > Convert most* of them to leave RBP alone. > > These pass the crypto boot tests for me. Any further testing would be > appreciated! > > [*] There are still a few crypto files left that need fixing, but the > fixes weren't trivial and nobody reported unwinder warnings about > them yet, so I'm skipping them for now. > > Josh Poimboeuf (12): > x86/crypto: Fix RBP usage in blowfish-x86_64-asm_64.S > x86/crypto: Fix RBP usage in camellia-x86_64-asm_64.S > x86/crypto: Fix RBP usage in cast5-avx-x86_64-asm_64.S > x86/crypto: Fix RBP usage in cast6-avx-x86_64-asm_64.S > x86/crypto: Fix RBP usage in des3_ede-asm_64.S > x86/crypto: Fix RBP usage in sha1_avx2_x86_64_asm.S > x86/crypto: Fix RBP usage in sha1_ssse3_asm.S > x86/crypto: Fix RBP usage in sha256-avx-asm.S > x86/crypto: Fix RBP usage in sha256-avx2-asm.S > x86/crypto: Fix RBP usage in sha256-ssse3-asm.S > x86/crypto: Fix RBP usage in sha512-avx2-asm.S > x86/crypto: Fix RBP usage in twofish-avx-x86_64-asm_64.S > Thanks for fixing these! I don't have time to review these in detail, but I ran the crypto self-tests on the affected algorithms, and they all pass. I also benchmarked them before and after; the only noticable performance difference was that sha256-avx2 and sha512-avx2 became a few percent slower. I don't suppose there is a way around that? Otherwise it's probably not a big deal. For reference, this was the list of affected algorithms I used: shash: sha1-ssse3, sha1-avx, sha1-avx2, sha256-ssse3, sha256-avx, sha256-avx2, sha512-ssse3, sha512-avx, sha512-avx2 cipher: blowfish-asm, camellia-asm, des3_ede-asm skcipher: ecb-blowfish-asm, cbc-blowfish-asm, ctr-blowfish-asm, ecb-cast5-avx, cbc-cast5-avx, ctr-cast5-avx, ecb-cast6-avx, cbc-cast6-avx, ctr-cast6-avx, lrw-cast6-avx, xts-cast6-avx, ecb-camellia-asm, cbc-camellia-asm, ctr-camellia-asm, lrw-camellia-asm, xts-camellia-asm, ecb-des3_ede-asm, cbc-des3_ede-asm, ctr-des3_ede-asm, ecb-twofish-avx, cbc-twofish-avx, ctr-twofish-avx, lrw-twofish-avx, xts-twofish-avx Eric
[PATCH] f2fs: avoid needless inode updates
If i_size wan't change at all, we don't need to write inode during fsync. Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 4b993961d81d..0d76b572484a 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync) spin_unlock(&sbi->inode_lock[DIRTY_META]); return ret; } - if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) || - file_keep_isize(inode) || - i_size_read(inode) & PAGE_MASK) - return false; - return F2FS_I(inode)->last_disk_size == i_size_read(inode); + if (F2FS_I(inode)->last_disk_size == i_size_read(inode)) + return true; + + return is_inode_flag_set(inode, FI_AUTO_RECOVER) && + !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK); } static inline int f2fs_readonly(struct super_block *sb) -- 2.14.0.rc1.383.gd1ce394fe2-goog
Re: [GIT PULL] ARM: at91: DT for 4.14#2
On Wed, Aug 30, 2017 at 06:39:05PM +0200, Alexandre Belloni wrote: > Hi Olof, > > As discussed, this replaces the previous pull request. The only change > is the fixed up SoB. > > The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: > > Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.14-dt2 Merged now, thanks. -Olof
[GIT PULL] ARM: SoC fixes for 4.13
Hi Linus, Just a few final fixes for 4.13. See below for description. Please merge. Thanks, -Olof The following changes since commit 93a4c8355e0e448d83f31801b4c72f66e4360975: ARM: dts: exynos: add needs-hpd for Odroid-XU3/4 (2017-08-23 21:43:29 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git armsoc-fixes for you to fetch changes up to 6f71a925761e7843965a704eb6682ea337abb4a5: Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu into fixes (2017-09-01 16:37:02 -0700) ARM: SoC fixes for 4.13 A couple of late-arriving fixes before final 4.13: - A few reverts of DT bindings on Allwinner for their ethernet driver. Discussion didn't converge, and since bindings are considered ABI it makes sense to revert instead of having to support two bindings long-term. - A fix to enumerate GPIOs properly on Marvell Armada AP806 Maxime Ripard (3): dt-bindings: net: Revert sun8i dwmac binding arm64: dts: allwinner: Revert EMAC changes arm: dts: sunxi: Revert EMAC changes Olof Johansson (2): Merge tag 'sunxi-fixes-for-4.13-3' of https://git.kernel.org/.../sunxi/linux into fixes Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu into fixes Thomas Petazzoni (1): arm64: dts: marvell: fix number of GPIOs in Armada AP806 description .../devicetree/bindings/net/dwmac-sun8i.txt| 84 -- arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 9 --- arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 19 - arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 -- arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 --- arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 8 --- arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts| 5 -- arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 --- arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 22 -- arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 - arch/arm/boot/dts/sunxi-h3-h5.dtsi | 26 --- .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 16 - .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 15 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 17 - .../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 16 - arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 -- .../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts | 17 - .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 17 - .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 17 - arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 4 +- 20 files changed, 2 insertions(+), 349 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
[PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi
Currently we are using edev->dev drvdata to get rk3399-dmc data, but it would be inited to edev in devfreq_event_add_edev. So we need to clear the edev->dev drvdata before enabling dfi, to prevent dfi from getting the wrong rk3399-dmc data when the irq triggered too early. Signed-off-by: Jeffy Chen --- drivers/devfreq/rk3399_dmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c index 1b89ebbad02c..12f9f03f349f 100644 --- a/drivers/devfreq/rk3399_dmc.c +++ b/drivers/devfreq/rk3399_dmc.c @@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev) rk3399_devfreq_dmc_profile.initial_freq = data->rate; + platform_set_drvdata(pdev, NULL); data->devfreq = devm_devfreq_add_device(dev, &rk3399_devfreq_dmc_profile, "simple_ondemand", -- 2.11.0
Re: [RFC/PATCH] drivers/of/platform: Add powerpc 4xx embedded busses to default list
On Fri, 2017-09-01 at 10:24 -0500, Rob Herring wrote: > On Thu, Aug 31, 2017 at 10:51 PM, Benjamin Herrenschmidt > wrote: > > This allow to (slowly) migrate those embedded platforms > > to of_platform_default_populate() > > > > Signed-off-by: Benjamin Herrenschmidt > > --- > > > > I'm here to collect acks (or comments :-) I'd like this to go via > > the powerpc tree along with the patches converting some of the > > platforms. I'll be adding more bus types if/when I start tackling > > other powerpc embedded families but for now I'm dealing with 4xx. > > Glad to see it. So my end game is to remove the #ifndef CONFIG_PPC around of_platform_default_populate_init(void). However, for that to work, I need to add a way to disable that on some platforms. However, it might take time, especially when it comes to dealing with the old Macs or some more obscure embedded platforms. So in the meantime, I'm thinking adding some kind of runtime way of disabling this default populate. Would you be ok with that ? Something like: bool arch_wants_of_platform_defaults(void) With a weak implementation returning true. Cheers, Ben.
[PATCH 0/2] Add a devm_of_clk_add_hw_provider() API
This cleans up some open-coded versions of this API and makes it official. It's also another carrot to convert drivers to use the clk hw registration APIs instead of the clk registration APIs. Stephen Boyd (2): clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs clk: qcom: common: Migrate to devm_* APIs for resets and clk providers Documentation/driver-model/devres.txt | 1 + drivers/clk/clk.c | 52 +++ drivers/clk/qcom/common.c | 26 ++ include/linux/clk-provider.h | 13 + 4 files changed, 68 insertions(+), 24 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/2] clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs
Sometimes we only have one of_clk_del_provider() call in driver
error and remove paths, because we're missing a
devm_of_clk_add_hw_provider() API. Introduce the API so we can
convert drivers to use this and potentially reduce the amount of
code needed to remove providers in drivers.
Signed-off-by: Stephen Boyd
---
Documentation/driver-model/devres.txt | 1 +
drivers/clk/clk.c | 52 +++
include/linux/clk-provider.h | 13 +
3 files changed, 66 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 30e04f7a690d..6b5e5e642b49 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -237,6 +237,7 @@ CLOCK
devm_clk_get()
devm_clk_put()
devm_clk_hw_register()
+ devm_of_clk_add_hw_provider()
DMA
dmam_alloc_coherent()
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c8d83acda006..d50398a79cbc 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3177,6 +3177,37 @@ int of_clk_add_hw_provider(struct device_node *np,
}
EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);
+static void devm_of_clk_release_provider(struct device *dev, void *res)
+{
+ of_clk_del_provider(*(struct device_node **)res);
+}
+
+int devm_of_clk_add_hw_provider(struct device *dev,
+ struct clk_hw *(*get)(struct of_phandle_args *clkspec,
+ void *data),
+ void *data)
+{
+ struct device_node **ptr, *np;
+ int ret;
+
+ ptr = devres_alloc(devm_of_clk_release_provider, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return -ENOMEM;
+
+ np = dev->of_node;
+ ret = of_clk_add_hw_provider(np, get, data);
+ if (!ret) {
+ *ptr = np;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return ret;;
+}
+EXPORT_SYMBOL_GPL(devm_of_clk_add_hw_provider);
+
/**
* of_clk_del_provider() - Remove a previously registered clock provider
* @np: Device node pointer associated with clock provider
@@ -3198,6 +3229,27 @@ void of_clk_del_provider(struct device_node *np)
}
EXPORT_SYMBOL_GPL(of_clk_del_provider);
+static int devm_clk_provider_match(struct device *dev, void *res, void *data)
+{
+ struct device_node **np = res;
+
+ if (WARN_ON(!np || !*np))
+ return 0;
+
+ return *np == data;
+}
+
+void devm_of_clk_del_provider(struct device *dev)
+{
+ int ret;
+
+ ret = devres_release(dev, devm_of_clk_release_provider,
+devm_clk_provider_match, dev->of_node);
+
+ WARN_ON(ret);
+}
+EXPORT_SYMBOL(devm_of_clk_del_provider);
+
static struct clk_hw *
__of_clk_get_hw_from_provider(struct of_clk_provider *provider,
struct of_phandle_args *clkspec)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1fc113fbf955..5a002e64999b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -814,7 +814,12 @@ int of_clk_add_hw_provider(struct device_node *np,
struct clk_hw *(*get)(struct of_phandle_args
*clkspec,
void *data),
void *data);
+int devm_of_clk_add_hw_provider(struct device *dev,
+ struct clk_hw *(*get)(struct of_phandle_args
*clkspec,
+void *data),
+ void *data);
void of_clk_del_provider(struct device_node *np);
+void devm_of_clk_del_provider(struct device *dev);
struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
void *data);
struct clk_hw *of_clk_hw_simple_get(struct of_phandle_args *clkspec,
@@ -846,7 +851,15 @@ static inline int of_clk_add_hw_provider(struct
device_node *np,
{
return 0;
}
+static inline int devm_of_clk_add_hw_provider(struct device *dev,
+ struct clk_hw *(*get)(struct of_phandle_args
*clkspec,
+void *data),
+ void *data)
+{
+ return 0;
+}
static inline void of_clk_del_provider(struct device_node *np) {}
+static inline void devm_of_clk_del_provider(struct device *dev) {}
static inline struct clk *of_clk_src_simple_get(
struct of_phandle_args *clkspec, void *data)
{
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 2/2] clk: qcom: common: Migrate to devm_* APIs for resets and clk providers
Now that we have devm APIs for the reset controller and of clk hw
provider APIs we can remove the custom code here.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/common.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index d523991c945f..b35564c0493f 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -111,16 +111,6 @@ qcom_pll_set_fsm_mode(struct regmap *map, u32 reg, u8
bias_count, u8 lock_count)
}
EXPORT_SYMBOL_GPL(qcom_pll_set_fsm_mode);
-static void qcom_cc_del_clk_provider(void *data)
-{
- of_clk_del_provider(data);
-}
-
-static void qcom_cc_reset_unregister(void *data)
-{
- reset_controller_unregister(data);
-}
-
static void qcom_cc_gdsc_unregister(void *data)
{
gdsc_unregister(data);
@@ -248,13 +238,7 @@ int qcom_cc_really_probe(struct platform_device *pdev,
return ret;
}
- ret = of_clk_add_hw_provider(dev->of_node, qcom_cc_clk_hw_get, cc);
- if (ret)
- return ret;
-
- ret = devm_add_action_or_reset(dev, qcom_cc_del_clk_provider,
- pdev->dev.of_node);
-
+ ret = devm_of_clk_add_hw_provider(dev, qcom_cc_clk_hw_get, cc);
if (ret)
return ret;
@@ -266,13 +250,7 @@ int qcom_cc_really_probe(struct platform_device *pdev,
reset->regmap = regmap;
reset->reset_map = desc->resets;
- ret = reset_controller_register(&reset->rcdev);
- if (ret)
- return ret;
-
- ret = devm_add_action_or_reset(dev, qcom_cc_reset_unregister,
- &reset->rcdev);
-
+ ret = devm_reset_controller_register(dev, &reset->rcdev);
if (ret)
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 24/31] mips/sgi-ip22: Use separate static data field with with static timer
Acked-by: Ralf Baechle Ralf
Re: [PATCH v5 1/7] clk: at91: clk-generated: remove useless divisor loop
On 08/10, Quentin Schulz wrote: > The driver requests the current clk rate of each of its parent clocks to > decide whether a clock rate is suitable or not. It does not request > determine_rate from a parent clock which could request a rate change in > parent clock (i.e. there is no parent rate propagation). > > We know the rate we want (passed along req argument of the function) and > the parent clock rate, thus we know the closest rounded divisor, we > don't need to iterate over the available divisors to find the best one > for a given clock. > > Signed-off-by: Quentin Schulz > Acked-by: Boris Brezillon > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 23/31] mips/sgi-ip32: Use separate static data field with with static timer
Acked-by: Ralf Baechle Ralf
Re: [PATCH v5 3/7] clk: at91: add audio pll clock drivers
On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can directly drive a pad. As these two routes > have different enable bits and different dividers and divider formulas, > they are handled by two different drivers. Each of them could modify the > rate of the main audio pll parent. > > The main audio pll clock can output 620MHz to 700MHz. > > Signed-off-by: Nicolas Ferre > Signed-off-by: Quentin Schulz > Acked-by: Boris Brezillon > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 6/7] ASoC: atmel-classd: remove aclk clock from DT binding
On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > This binding is used by no board in mainline so it is safe to be > modified. > > Signed-off-by: Quentin Schulz > Acked-by: Mark Brown > Acked-by: Rob Herring > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 4/7] clk: at91: clk-generated: create function to find best_diff
On 08/10, Quentin Schulz wrote: > The way to find the best_diff and do the appropriate process afterwards > can be re-used. > > This patch prepares the driver for an upcoming patch that will allow > clk_generated to determine the rate of the audio_pll. > > Signed-off-by: Quentin Schulz > Acked-by: Boris Brezillon > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 7/7] ASoC: atmel-classd: remove aclk clock
On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > Thus, remove all mentions to aclk in classd driver and update macros and > variable names. > > Signed-off-by: Quentin Schulz > Acked-by: Mark Brown > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 2/7] dt-bindings: clk: at91: add audio plls to the compatible list
On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can directly drive a pad. As these two routes > have different enable bits and different dividers and divider formulas, > they are handled by two different drivers. > > This adds the audio plls (frac, pad and pmc) to the compatible list of > at91 clocks in DT binding. > > Signed-off-by: Quentin Schulz > Acked-by: Rob Herring > Acked-by: Boris Brezillon > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 5/7] clk: at91: clk-generated: make gclk determine audio_pll rate
On 08/10, Quentin Schulz wrote: > This allows gclk to determine audio_pll rate and set the parent rate > accordingly. > > However, there are multiple children clocks that could technically > change the rate of audio_pll (via gck). With the rate locking, the first > consumer to enable the clock will be the one definitely setting the rate > of the clock. > > Since audio IPs are most likely to request the same rate, we enforce > that the only clks able to modify gck rate are those of audio IPs. > > To remain consistent, we deny other clocks to be children of audio_pll. > > Signed-off-by: Quentin Schulz > Acked-by: Boris Brezillon > Acked-by: Nicolas Ferre > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables
Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: I was trying to avoid mixing early and no-early set_memory_decrypted() but if feedback is: use early_set_memory_decrypted() only if its required otherwise use set_memory_decrypted() then I can improve the logic in next rev. thanks Yes, I think you should use the early versions when you're, well, *early* :-) But get rid of that for_each_possible_cpu() and do it only on the current CPU, as this is a per-CPU path anyway. If you need to do it on *every* CPU and very early, then you need a separate function which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. I am trying to implement your feedback and now remember why I choose to use early_set_memory_decrypted() and for_each_possible_cpu loop. These percpu variables are static. Hence before clearing the C-bit we must perform the in-place decryption so that original assignment is preserved after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() -- which can be used to perform the in-place decryption but we do not have similar routine for non-early cases. In order to address your feedback, we have to add similar functions. So far, we have not seen the need for having such functions except this cases. The approach we have right now works just fine and not sure if its worth adding new functions. Thoughts ? [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of memory -Brijesh
Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions
Peter Zijlstra wrote:
> if (obj) {
> /* use obj */
> refcount_dec(&obj->refs); /* should never hit 0 */
> }
You've missed a bit: We need to tell the gc to run when we reduce the refcount
to 1:
if (obj) {
...
if (refcount_dec_return(&obj->refs) == 1)
schedule_gc();
}
David
Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
On 01/09/17 07:04, Maxime Ripard wrote:
> On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 31/08/17 00:36, Stefan Brüns wrote:
>>> The A64 SoC has the same dma engine as the H3 (sun8i), with a
>>> reduced amount of physical channels. Add the proper config data
>>> and compatible string to support it.
>>
>> ...
>>
>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
>>> index 5f4eee4513e5..6a17c5d63582 100644
>>> --- a/drivers/dma/sun6i-dma.c
>>> +++ b/drivers/dma/sun6i-dma.c
>>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
>>> .nr_max_vchans = 34,
>>> .dmac_variant= DMAC_VARIANT_H3,
>>> };
>>> +
>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
>>> + .nr_max_channels = 8,
>>> + .nr_max_requests = 27,
>>> + .nr_max_vchans = 38,
>>> + .dmac_variant= DMAC_VARIANT_H3,
>>> };
>>>
>>> static const struct of_device_id sun6i_dma_match[] = {
>>> @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] = {
>>> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
>>> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg
>>> },
>>> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
>>> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg
>>> },
>>> { /* sentinel */ }
>>> };
>>> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
>>
>> I was wondering if should use the opportunity to expose those values as
>> DT properties instead of hard-wiring them to a compatible string in the
>> driver every time we add support for a new SoC?
>> We could introduce a new compatible string (say: "allwinner,sunxi-dma"),
>> then describe properties for the number of channels and requests and
>> vchans and parse those from the DT at probe time.
>> With this we might be able to support future SoCs without Linux *driver*
>> changes, by just providing the right DT. This would have worked already
>> for instance for the A83T support, which just changed those values.
>>
>> For instance with this quick patch below (just compile tested, and without
>> your refactoring).
>> The DT node would then read something like:
>> dma: dma-controller@01c02000 {
>> compatible = "allwinner,sun50i-a64-dma",
>> "allwinner,sunxi-dma";
>> reg = <0x01c02000 0x1000>;
>> interrupts = ;
>> clocks = <&ccu CLK_BUS_DMA>;
>> resets = <&ccu RST_BUS_DMA>;
>> #dma-cells = <1>;
>> allwinner,max_channels = <8>;
>> allwinner,max_requests = <27>;
>> allwinner,max_vchans = <38>;
>> };
>
> We're still going to need a different compatible anyway, so it's not
> really like it would change anything.
Well, not for now, but possibly in the future. And we should start with
this at one point. If we would have had this type of binding already for
H3, we could have added the A64 support without driver changes just by a
DT change.
Cheers,
Andre.
Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
Hi,
On 01/09/17 02:19, Stefan Bruens wrote:
> On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
>> Hi,
>>
>> On 31/08/17 00:36, Stefan Brüns wrote:
>>> The A64 SoC has the same dma engine as the H3 (sun8i), with a
>>> reduced amount of physical channels. Add the proper config data
>>> and compatible string to support it.
>>
>> ...
>>
>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
>>> index 5f4eee4513e5..6a17c5d63582 100644
>>> --- a/drivers/dma/sun6i-dma.c
>>> +++ b/drivers/dma/sun6i-dma.c
>>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
>>>
>>> .nr_max_vchans = 34,
>>> .dmac_variant= DMAC_VARIANT_H3,
>>>
>>> };
>>>
>>> +
>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
>>> + .nr_max_channels = 8,
>>> + .nr_max_requests = 27,
>>> + .nr_max_vchans = 38,
>>> + .dmac_variant= DMAC_VARIANT_H3,
>>>
>>> };
>>>
>>> static const struct of_device_id sun6i_dma_match[] = {
>>>
>>> @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] =
>>> {>
>>> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg
> },
>>> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg
>>> },
>>> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
>>>
>>> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg
>>> },>
>>> { /* sentinel */ }
>>>
>>> };
>>> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
>>
>> I was wondering if should use the opportunity to expose those values as
>> DT properties instead of hard-wiring them to a compatible string in the
>> driver every time we add support for a new SoC?
>> We could introduce a new compatible string (say: "allwinner,sunxi-dma"),
>> then describe properties for the number of channels and requests and
>> vchans and parse those from the DT at probe time.
>> With this we might be able to support future SoCs without Linux *driver*
>> changes, by just providing the right DT. This would have worked already
>> for instance for the A83T support, which just changed those values.
>>
>> For instance with this quick patch below (just compile tested, and without
>> your refactoring).
>> The DT node would then read something like:
>> dma: dma-controller@01c02000 {
>> compatible = "allwinner,sun50i-a64-dma",
>> "allwinner,sunxi-dma";
>> reg = <0x01c02000 0x1000>;
>> interrupts = ;
>> clocks = <&ccu CLK_BUS_DMA>;
>> resets = <&ccu RST_BUS_DMA>;
>> #dma-cells = <1>;
>> allwinner,max_channels = <8>;
>> allwinner,max_requests = <27>;
>> allwinner,max_vchans = <38>;
>> };
>
> For these 3 properties it likely is a good idea, but we would IMHO still have
> to care for the differences in the register settings:
>
> - A31 does not have a clock autogating register
> - A23 and A83t does have one at offset 0x20
> - A64, H3, H5 and R40 have it at offset 0x28
Fair enough - I didn't look too closely at your new changes, especially
why it apparently worked before.
But as your list shows, we would only need one compatible string per
line - in the driver - to cover all SoCs (and possibly future SoCs!),
and do the rest via the properties.
We can't use the existing h3 compatible string or touch the already
existing SoCs and compatible strings, of course, but I guess
the A64, R40 and future SoCs could make use of a new (generic?) string.
> There are also the incompatibilities in the "DMA channel configuration
> register" (burst length; burst width; burst length field offset).
>
> We can either have 3 different compatible strings, or another property for
> the
> register model.
The latter is usually frowned upon, using separate compatible strings
for each group of SoCs is the way to go here.
> For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction is a
> better option - it can encode the allowed DRQ numbers much better (e.g. for
> H3, the highest source DRQ is 24). The DRQ field in the channel configuration
> register is 5 bits, so the hightest port/DRQ number is 31.
So looking more closely at the manual and the code my understanding is
that nr_max_requests is more or less some rough molly guard to prevent
wrong settings? Derived from the DRQ table in the manual?
So that trying to program port 28 on an H3 would fail?
But source port 25 or dest port 26 wouldn't be caught by this check,
though they would still be "illegal" according to the manual. (Which we
are not sure of, I guess, it may just not be documented)
So I wonder if this nr_max_requests is useful at all, and we should just
check that it fits into 5 bits and assume that the DT has superior
knowledge of what's allowed and what not.
Now I see what you mean with the bitmask (to cover those gaps), but I am
bit sceptical if that is actually useful. After all the DRQ number w
kmemleak not always catching stuff
Hi,
Recently kmemleak discovered a bug in my code where an allocated
trampoline for a ftrace function tracer wasn't freed due to an exit
path. The thing is, kmemleak was able to catch this 100% when it was
triggered by one of my ftrace selftests that happen at bootup. But when
I trigger the issue from user space after bootup finished, it would not
catch it.
Now I was thinking that it may be due to the fact that the trampoline
is allocated with module_alloc(), and that has some magic kasan goo in
it. But when forcing the issue with adding the following code:
void **pblah;
void *blah;
pblah = kmalloc(sizeof(*pblah), GFP_KERNEL);
blah = module_alloc(PAGE_SIZE);
*pblah = blah;
printk("allocated blah %p\n", blah);
kfree(pblah);
in a path that I could control, it would catch it only after doing it
several times. I was never able to have kmemleak catch the actual bug
from user space no matter how many times I triggered it.
# dmesg |grep kmemleak
[ 16.746832] kmemleak: Kernel memory leak detector initialized
[ 16.746888] kmemleak: Automatic memory scanning thread started
And then I would do:
# echo scan=on > /sys/kernel/debug/kmemleak
[do the test]
# echo scan > /sys/kernel/debug/kmemleak
Most of the times it found nothing. Even when I switched the above from
module_alloc() to kmalloc().
Is this normal?
-- Steve
[rcu:rcu/next 27/27] kernel/rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu/next
head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321
commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU
stall warnings while dumping trace
config: i386-randconfig-x000-201735 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from kernel/rcu/rcuperf.c:51:0:
kernel/rcu/rcuperf.c: In function 'rcu_perf_writer':
>> kernel/rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared (first
>> use in this function)
if (!rcu_cpu_stall_suppress) \
^
>> kernel/rcu/rcuperf.c:482:5: note: in expansion of macro 'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
kernel/rcu/rcu.h:225:8: note: each undeclared identifier is reported only
once for each function it appears in
if (!rcu_cpu_stall_suppress) \
^
>> kernel/rcu/rcuperf.c:482:5: note: in expansion of macro 'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
vim +/rcu_cpu_stall_suppress +225 kernel/rcu/rcu.h
214
215 /*
216 * Dump the ftrace buffer, but only one time per callsite per boot.
217 */
218 #define rcu_ftrace_dump(oops_dump_mode) \
219 do { \
220 static atomic_t ___rfd_beenhere = ATOMIC_INIT(0); \
221 \
222 if (!atomic_read(&___rfd_beenhere) && \
223 !atomic_xchg(&___rfd_beenhere, 1)) { \
224 tracing_off(); \
> 225 if (!rcu_cpu_stall_suppress) \
226 rcu_cpu_stall_suppress = 3; \
227 ftrace_dump(oops_dump_mode); \
228 if (rcu_cpu_stall_suppress == 3) \
229 rcu_cpu_stall_suppress = 0; \
230 } \
231 } while (0)
232
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] DSA support for Micrel KSZ8895
On 09/01/2017 05:15 AM, Pavel Machek wrote: > Hi! > > On Wed 2017-08-30 21:32:07, tristram...@microchip.com wrote: >>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote: > I may be confused here, but AFAICT: > > 1) Yes, it has standard layout when accessed over MDIO. Section 4.8 of the datasheet says: All the registers defined in this section can be also accessed via the SPI interface. Meaning all PHY registers can be access via the SPI interface. So you should be able to make a standard Linux MDIO bus driver which performs SPI reads. >>> >>> As far as I can tell (and their driver confirms) -- yes, all those >>> registers can be >>> accessed over the SPI, they are just shuffled around... hence MDIO >>> emulation code. I copied it from their code (see the copyrights) so no, I >>> don't >>> believe there's nicer solution. >>> >>> Best regards, >> >> Can you hold on your developing work on KSZ8895 driver? I am afraid your >> effort may be in vain. We at Microchip are planning to release DSA drivers >> for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863. >> > > Well, thanks for heads up... but its too late to stop now. I already > have working code, without the advanced features. No driver has landed yet nor has any driver been posted in a proper form or shape, so at this point neither of you are able to make any claims as to which one should be chosen. > > I don't know how far away you are with the development. You may want > to start from my driver (but its probably too late now). I would tend to favor Tristram's submission when we see it because he claims support for more devices and it is likely to be backed and maintained by Microchip in the future. I am sure there will be opportunity for you to contribute a lot to this driver. Of course, this all depends on the code quality and timing, but having two people work on the same things in parallel is just a complete waste of each other's time so we might as well wait for Tristram to post the said driver and define a plan of action from there? -- Florian
[rcu:rcu/next 27/27] kernel//rcu/rcutorture.c:1124:3: note: in expansion of macro 'rcu_ftrace_dump'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu/next
head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321
commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU
stall warnings while dumping trace
config: x86_64-randconfig-x016-201735 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from kernel//rcu/rcutorture.c:56:0:
kernel//rcu/rcutorture.c: In function 'rcu_torture_timer':
kernel//rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared (first
use in this function)
if (!rcu_cpu_stall_suppress) \
^
>> kernel//rcu/rcutorture.c:1124:3: note: in expansion of macro
>> 'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
kernel//rcu/rcu.h:225:8: note: each undeclared identifier is reported only
once for each function it appears in
if (!rcu_cpu_stall_suppress) \
^
>> kernel//rcu/rcutorture.c:1124:3: note: in expansion of macro
>> 'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
kernel//rcu/rcutorture.c: In function 'rcu_torture_reader':
kernel//rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared (first
use in this function)
if (!rcu_cpu_stall_suppress) \
^
kernel//rcu/rcutorture.c:1205:4: note: in expansion of macro
'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
kernel//rcu/rcutorture.c: In function 'rcu_torture_stats_print':
kernel//rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared (first
use in this function)
if (!rcu_cpu_stall_suppress) \
^
kernel//rcu/rcutorture.c:1335:3: note: in expansion of macro
'rcu_ftrace_dump'
rcu_ftrace_dump(DUMP_ALL);
^~~
vim +/rcu_ftrace_dump +1124 kernel//rcu/rcutorture.c
f34c8585e kernel/rcu/rcutorture.c Paul E. McKenney 2017-07-20 1074
b772e1dd4 kernel/rcutorture.c Josh Triplett2006-10-04 1075 /*
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1076 * RCU
torture reader from timer handler. Dereferences rcu_torture_current,
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1077 *
incrementing the corresponding element of the pipeline array. The
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1078 * counter
in the element should never be greater than 1, otherwise, the
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1079 * RCU
implementation is broken.
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1080 */
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1081 static
void rcu_torture_timer(unsigned long unused)
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1082 {
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1083 int idx;
917963d0b kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1084
unsigned long started;
6b80da42c kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1085
unsigned long completed;
51b1130eb kernel/rcu/rcutorture.c Paul E. McKenney 2014-01-27 1086 static
DEFINE_TORTURE_RANDOM(rand);
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1087 static
DEFINE_SPINLOCK(rand_lock);
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1088 struct
rcu_torture *p;
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1089 int
pipe_count;
524945351 kernel/rcutorture.c Paul E. McKenney 2012-11-14 1090
unsigned long long ts;
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1091
0729fbf3b kernel/rcutorture.c Paul E. McKenney 2008-06-25 1092 idx =
cur_ops->readlock();
917963d0b kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1093 if
(cur_ops->started)
917963d0b kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1094
started = cur_ops->started();
917963d0b kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1095 else
917963d0b kernel/rcu/rcutorture.c Paul E. McKenney 2014-11-21 1096
started = cur_ops->completed();
e4aa0da39 kernel/rcutorture.c Steven Rostedt 2013-02-04 1097 ts =
rcu_trace_clock_local();
632ee2001 kernel/rcutorture.c Paul E. McKenney 2010-02-22 1098 p =
rcu_dereference_check(rcu_torture_current,
632ee2001 kernel/rcutorture.c Paul E. McKenney 2010-02-22 1099
rcu_read_lock_bh_held() ||
632ee2001 kernel/rcutorture.c Paul E. McKenney 2010-02-22 1100
rcu_read_lock_sched_held() ||
5be5d1a11 kernel/rcu/rcutorture.c Paul E. McKenney 2015-06-30 1101
srcu_read_lock_held(srcu_ctlp) ||
5be5d1a11 kernel/rcu/rcutorture.c Paul E. McKenney 2015-06-30 1102
Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup
On Fri 01 Sep 13:47 PDT 2017, Marcel Holtmann wrote:
> Hi Bjorn,
>
> > Bluetooth BD address can be retrieved in the same way as
> > for wcnss-wlan MAC address. This patch mainly stores the
> > local-mac-address property and sets the BD address during
> > hci device setup.
> >
> > Signed-off-by: Loic Poulain
> > Signed-off-by: Bjorn Andersson
> > ---
> > drivers/bluetooth/btqcomsmd.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> > index d00c4fdae924..443bb2099329 100644
> > --- a/drivers/bluetooth/btqcomsmd.c
> > +++ b/drivers/bluetooth/btqcomsmd.c
> > @@ -26,6 +26,7 @@
> > struct btqcomsmd {
> > struct hci_dev *hdev;
> >
> > + const bdaddr_t *addr;
> > struct rpmsg_endpoint *acl_channel;
> > struct rpmsg_endpoint *cmd_channel;
> > };
> > @@ -100,6 +101,27 @@ static int btqcomsmd_close(struct hci_dev *hdev)
> > return 0;
> > }
> >
> > +static int btqcomsmd_setup(struct hci_dev *hdev)
> > +{
> > + struct btqcomsmd *btq = hci_get_drvdata(hdev);
> > + struct sk_buff *skb;
> > +
> > + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
> > + if (IS_ERR(skb))
> > + return PTR_ERR(skb);
> > + kfree_skb(skb);
> > +
> > + if (btq->addr) {
> > + bdaddr_t bdaddr;
> > +
> > + /* btq->addr stored with most significant byte first */
> > + baswap(&bdaddr, btq->addr);
> > + return qca_set_bdaddr_rome(hdev, &bdaddr);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int btqcomsmd_probe(struct platform_device *pdev)
> > {
> > struct btqcomsmd *btq;
> > @@ -123,6 +145,11 @@ static int btqcomsmd_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(btq->cmd_channel))
> > return PTR_ERR(btq->cmd_channel);
> >
> > + btq->addr = of_get_property(pdev->dev.of_node, "local-mac-address",
> > + &ret);
> > + if (ret != sizeof(bdaddr_t))
> > + btq->addr = NULL;
> > +
> > hdev = hci_alloc_dev();
> > if (!hdev)
> > return -ENOMEM;
> > @@ -135,6 +162,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> > hdev->open = btqcomsmd_open;
> > hdev->close = btqcomsmd_close;
> > hdev->send = btqcomsmd_send;
> > + hdev->setup = btqcomsmd_setup;
> > hdev->set_bdaddr = qca_set_bdaddr_rome;
>
> I do not like this patch. Why not just set HCI_QUIRK_INVALID_BDADDR
> and let a userspace tool deal with reading the BD_ADDR from some
> storage.
>
That's what we currently have, but we regularly get complaints from
developers using our board (DB410c).
We're maintaining a Debian-based and an OpenEmbedded-based build and at
least in the past btmgmt was not available in these - so we would have
to maintain both a custom BlueZ package and then some scripts to inject
the appropriate mac address.
Beyond these reference builds our users tend to build their own system
images and I was hoping that they would not be forced to have a custom
hook running each time hci0 is registered.
> Frankly I do not get this WiFI MAC address or BD_ADDR stored in DT. I
> assumed the DT is suppose to describe hardware and not some value that
> is normally retrieved for OTP or alike.
>
While I share your skepticism here I find it way superior over the
various cases where this information is hard coded in some firmware file
that has to be patched for each device - in particular when considering
the out-of-tree workarounds that follow when said firmware file is not
allowed to be modified on the device (e.g. in Android).
And note that it's not _stored_ in DT, it's passed from the boot loader
in DT - and it's still optional, so if an OEM has other means to
provision the BD_ADDR they can still handle this in user space.
Regards,
Bjorn
Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions
On Fri, Sep 01, 2017 at 11:50:03PM +0200, Peter Zijlstra wrote: > > Did you read the other other part of the description? > > > > Further, both functions can be used to accurately trace the refcount > > (refcount_inc() followed by refcount_read() can't be considered > > accurate). > > I must admit to having overlooked that. But can we treat the two issues > separately? They are quite distinct. So for tracing purposes inc_return/dec_return don't cover the full set. In particular: inc_not_zero, dec_not_one and dec_and_*lock are not covered. dec_if_one I suppose we only care about the success case, in which case we knew it was one by inference.
Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices
Hi,
On 09/01/2017 11:19 AM, Mika Westerberg wrote:
On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote:
On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote:
On 14-08-17 22:45, Andy Shevchenko wrote:
On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede
wrote:
+int cht_int33fe_check_for_max17047(struct device *dev, void *data)
+{
+ const char *name = dev_name(dev);
+ struct i2c_client **max17047 = data;
+
+ if (name && strcmp(name, "i2c-MAX17047:00") == 0) {
Can we stop using bad practice of comparing against _instance_?
If device is suppose to be single in the system, wouldn't _HID be enough?
Yes _HID would be enough, but that takes some extra code with little
gain IMHO, we are effectively checking the HID here as that is where
the device-name comes from.
Anyways if you strongly prefer a HID check I can do a v2 doing that
either way let me know.
Currently we have the following modules where ACPI instance is used in:
drivers/acpi/acpi_lpss.c
drivers/input/touchscreen/goodix.c
drivers/platform/x86/silead_dmi.c
drivers/power/supply/axp288_charger.c
and plenty under sound/soc/intel.
I do not care right now about sound/soc/intel stuff, while everywhere
else would be better to avoid this.
Mika, Rafael, what're yours opinions regarding to use ACPI instances
in the drivers?
Since the instance name is generated by the ACPI core and in theory
could change, I agree this is pretty fragile. Using _HID/_UID should be
the preferred way. However, it is not always possible so we end up doing
hacks like this.
Given that on the device in question where we need this workaround there
is only ever 1 max17047, including the instance number in the check really
is a non-problem, but if there is a strong preference for me to change
the check over to a _HID check then I can do a v2 doing so.
Regards,
Hans
RE: [PATCH][staging-next] staging: unisys: visorbus: make two functions static
> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Friday, September 1, 2017 6:08 AM > To: Greg Kroah-Hartman ; Sell, Timothy C > ; Binder, David Anthony > ; Wadgaonkar, Sameer Laxmikant > ; Charles Daniels > ; Andy Shevchenko > ; *S-Par-Maintainer > ; de...@driverdev.osuosl.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH][staging-next] staging: unisys: visorbus: make two functions > static > > From: Colin Ian King > > The functions sig_queue_offset and sig_data_offset are local to > the source and do not need to be in global scope, so make them > static. > > Cleans up sparse warnings: > symbol 'sig_queue_offset' was not declared. Should it be static? > symbol 'sig_data_offset' was not declared. Should it be static? > > Signed-off-by: Colin Ian King Acked-by: David Kershner > --- > drivers/staging/unisys/visorbus/visorchannel.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > smime.p7s Description: S/MIME cryptographic signature
[PATCH v2] mux: core: Fix double get_device()
class_find_device already does a get_device on the returned device.
So the device returned by of_find_mux_chip_by_node is already referenced
and we should not reference it again (and unref it on error).
Also rename of_find_mux_chip_by_node to of_get_mux_chip_by_node to
make it clear that it returns a reference.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Do not rename of_find_mux_chip_by_node
---
drivers/mux/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 2260063b0ea8..6e5cf9d9cd99 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -413,6 +413,7 @@ static int of_dev_node_match(struct device *dev, const void
*data)
return dev->of_node == data;
}
+/* Note this function returns a reference to the mux_chip dev. */
static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
{
struct device *dev;
@@ -466,6 +467,7 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
(!args.args_count && (mux_chip->controllers > 1))) {
dev_err(dev, "%pOF: wrong #mux-control-cells for %pOF\n",
np, args.np);
+ put_device(&mux_chip->dev);
return ERR_PTR(-EINVAL);
}
@@ -476,10 +478,10 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
if (controller >= mux_chip->controllers) {
dev_err(dev, "%pOF: bad mux controller %u specified in %pOF\n",
np, controller, args.np);
+ put_device(&mux_chip->dev);
return ERR_PTR(-EINVAL);
}
- get_device(&mux_chip->dev);
return &mux_chip->mux[controller];
}
EXPORT_SYMBOL_GPL(mux_control_get);
--
2.13.5
[PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform
On non DT platforms we cannot get the mux_chip by pnode. Other subsystems
(regulator, clock, pwm) have the same problem and solve this by allowing
platform / board-setup code to add entries to a lookup table and then use
this table to look things up.
This commit adds support for getting a mux controller on a non DT platform
following this pattern. It is based on a simplified version of the pwm
subsys lookup code, the dev_id and mux_name parts of a lookup table entry
are mandatory in the mux-core implementation.
Signed-off-by: Hans de Goede
---
drivers/mux/core.c | 96 +++-
include/linux/mux/consumer.h | 11 +
2 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 6142493c327b..8864cc745506 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -24,6 +24,9 @@
#include
#include
+static DEFINE_MUTEX(mux_lookup_lock);
+static LIST_HEAD(mux_lookup_list);
+
/*
* The idle-as-is "state" is not an actual state that may be selected, it
* only implies that the state should not be changed. So, use that state
@@ -408,6 +411,23 @@ int mux_control_deselect(struct mux_control *mux)
}
EXPORT_SYMBOL_GPL(mux_control_deselect);
+static int parent_name_match(struct device *dev, const void *data)
+{
+ const char *parent_name = dev_name(dev->parent);
+ const char *name = data;
+
+ return strcmp(parent_name, name) == 0;
+}
+
+static struct mux_chip *mux_chip_get_by_name(const char *name)
+{
+ struct device *dev;
+
+ dev = class_find_device(&mux_class, NULL, name, parent_name_match);
+
+ return dev ? to_mux_chip(dev) : NULL;
+}
+
static int of_dev_node_match(struct device *dev, const void *data)
{
return dev->of_node == data;
@@ -479,6 +499,42 @@ static struct mux_control *of_mux_control_get(struct
device *dev,
}
/**
+ * mux_add_table() - register PWM device consumers
+ * @table: array of consumers to register
+ * @num: number of consumers in table
+ */
+void mux_add_table(struct mux_lookup *table, size_t num)
+{
+ mutex_lock(&mux_lookup_lock);
+
+ while (num--) {
+ list_add_tail(&table->list, &mux_lookup_list);
+ table++;
+ }
+
+ mutex_unlock(&mux_lookup_lock);
+}
+EXPORT_SYMBOL_GPL(mux_add_table);
+
+/**
+ * mux_remove_table() - unregister PWM device consumers
+ * @table: array of consumers to unregister
+ * @num: number of consumers in table
+ */
+void mux_remove_table(struct mux_lookup *table, size_t num)
+{
+ mutex_lock(&mux_lookup_lock);
+
+ while (num--) {
+ list_del(&table->list);
+ table++;
+ }
+
+ mutex_unlock(&mux_lookup_lock);
+}
+EXPORT_SYMBOL_GPL(mux_remove_table);
+
+/**
* mux_control_get() - Get the mux-control for a device.
* @dev: The device that needs a mux-control.
* @mux_name: The name identifying the mux-control.
@@ -487,11 +543,49 @@ static struct mux_control *of_mux_control_get(struct
device *dev,
*/
struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
{
+ struct mux_lookup *m, *chosen = NULL;
+ const char *dev_id = dev_name(dev);
+ struct mux_chip *mux_chip;
+
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) && dev->of_node)
return of_mux_control_get(dev, mux_name);
- return ERR_PTR(-ENODEV);
+ /*
+* For non DT we look up the provider in the static table typically
+* provided by board setup code.
+*
+* If a match is found, the provider mux chip is looked up by name
+* and a mux-control is requested using the table provided index.
+*/
+ mutex_lock(&mux_lookup_lock);
+ list_for_each_entry(m, &mux_lookup_list, list) {
+ if (WARN_ON(!m->dev_id || !m->mux_name || !m->provider))
+ continue;
+
+ if (strcmp(m->dev_id, dev_id) == 0 &&
+ strcmp(m->mux_name, mux_name) == 0) {
+ chosen = m;
+ break;
+ }
+ }
+ mutex_unlock(&mux_lookup_lock);
+
+ if (!chosen)
+ return ERR_PTR(-ENODEV);
+
+ mux_chip = mux_chip_get_by_name(chosen->provider);
+ if (!mux_chip)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ if (chosen->index >= mux_chip->controllers) {
+ dev_err(dev, "Mux lookup table index out of bounds %u >= %u\n",
+ chosen->index, mux_chip->controllers);
+ put_device(&mux_chip->dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return &mux_chip->mux[chosen->index];
}
EXPORT_SYMBOL_GPL(mux_control_get);
diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
index ea96d4c82be7..912dd48a3a5d 100644
--- a/include/linux/mux/consumer.h
+++ b/include/linux/mux/consumer.h
@@ -18,6 +18,17 @@
struct device;
struct mux_contr
[PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling
The Intel cherrytrail xhci controller has an extended cap mmio-range
which contains registers to control the muxing to the xhci (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.
Having a mux driver included in the xhci code (or under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform mux driver for the
mux.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Check xHCI controller PCI device-id instead of only checking for the
Intel Extended capability ID, as the Extended capability ID is used on
other model Intel xHCI controllers too
---
drivers/usb/host/Makefile| 2 +-
drivers/usb/host/xhci-intel-quirks.c | 85
drivers/usb/host/xhci-pci.c | 4 ++
drivers/usb/host/xhci.h | 2 +
4 files changed, 92 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/xhci-intel-quirks.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691fffcc0..441edf82eb1c 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_USB_OHCI_HCD_DAVINCI)+= ohci-da8xx.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
-obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o xhci-intel-quirks.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o
diff --git a/drivers/usb/host/xhci-intel-quirks.c
b/drivers/usb/host/xhci-intel-quirks.c
new file mode 100644
index ..819f5f9da9ee
--- /dev/null
+++ b/drivers/usb/host/xhci-intel-quirks.c
@@ -0,0 +1,85 @@
+/*
+ * Intel Vendor Defined XHCI extended capability handling
+ *
+ * Copyright (c) 2016) Hans de Goede
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Author: Wu, Hao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program;
+ */
+
+#include
+#include "xhci.h"
+
+/* Extended capability IDs for Intel Vendor Defined */
+#define XHCI_EXT_CAPS_INTEL_HOST_CAP 192
+
+static void xhci_intel_unregister_pdev(void *arg)
+{
+ platform_device_unregister(arg);
+}
+
+int xhci_create_intel_cht_mux_pdev(struct xhci_hcd *xhci)
+{
+ struct usb_hcd *hcd = xhci_to_hcd(xhci);
+ struct device *dev = hcd->self.controller;
+ struct platform_device *pdev;
+ struct resource res = { 0, };
+ int ret, ext_offset;
+
+ ext_offset = xhci_find_next_ext_cap(&xhci->cap_regs->hc_capbase, 0,
+ XHCI_EXT_CAPS_INTEL_HOST_CAP);
+ if (!ext_offset) {
+ xhci_err(xhci, "couldn't find Intel ext caps\n");
+ return -ENODEV;
+ }
+
+ pdev = platform_device_alloc("intel_cht_usb_mux", PLATFORM_DEVID_NONE);
+ if (!pdev) {
+ xhci_err(xhci, "couldn't allocate intel_cht_usb_mux pdev\n");
+ return -ENOMEM;
+ }
+
+ res.start = hcd->rsrc_start + ext_offset;
+ res.end = res.start + 0x3ff;
+ res.name = "intel_cht_usb_mux";
+ res.flags = IORESOURCE_MEM;
+
+ ret = platform_device_add_resources(pdev, &res, 1);
+ if (ret) {
+ dev_err(dev, "couldn't add resources to intel_cht_usb_mux
pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ pdev->dev.parent = dev;
+
+ ret = platform_device_add(pdev);
+ if (ret) {
+ dev_err(dev, "couldn't register intel_cht_usb_mux pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, xhci_intel_unregister_pdev, pdev);
+ if (ret) {
+ dev_err(dev, "couldn't add unregister action for
intel_cht_usb_mux pdev\n");
+ return ret;
+ }
+
+ return 0;
+}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8071c8fdd15e..b55c1e96abf0 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -188,6 +188,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_
[PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver
Add a driver for the Pericom PI3USB30532 Type-C cross switch /
mux chip found on some devices with a Type-C port.
Signed-off-by: Hans de Goede
---
drivers/mux/Kconfig | 10 +
drivers/mux/Makefile | 2 +
drivers/mux/pi3usb30532.c | 97 +++
3 files changed, 109 insertions(+)
create mode 100644 drivers/mux/pi3usb30532.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 17938918bf93..19a3065c34e6 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -58,4 +58,14 @@ config MUX_MMIO
To compile the driver as a module, choose M here: the module will
be called mux-mmio.
+config MUX_PI3USB30532
+ tristate "Pericom PI3USB30532 Type-C cross switch driver"
+ depends on I2C
+ help
+ This driver adds support for the Pericom PI3USB30532 Type-C cross
+ switch / mux chip found on some devices with a Type-C port.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-pi3usb30532.
+
endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index a12e812c7966..7563dbf04593 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -7,9 +7,11 @@ mux-adg792a-objs := adg792a.o
mux-gpio-objs := gpio.o
mux-mmio-objs := mmio.o
mux-intel_cht_usb_mux-objs := intel_cht_usb_mux.o
+mux-pi3usb30532-objs := pi3usb30532.o
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
obj-$(CONFIG_MUX_CHT_USB_MUX) += mux-intel_cht_usb_mux.o
+obj-$(CONFIG_MUX_PI3USB30532) += mux-pi3usb30532.o
diff --git a/drivers/mux/pi3usb30532.c b/drivers/mux/pi3usb30532.c
new file mode 100644
index ..fa8abd851520
--- /dev/null
+++ b/drivers/mux/pi3usb30532.c
@@ -0,0 +1,97 @@
+/*
+ * Pericom PI3USB30532 Type-C cross switch / mux driver
+ *
+ * Copyright (c) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include /* For the MUX_USB_* defines */
+#include
+
+#define PI3USB30532_CONF 0x00
+
+#define PI3USB30532_CONF_OPEN 0x00
+#define PI3USB30532_CONF_SWAP 0x01
+#define PI3USB30532_CONF_4LANE_DP 0x02
+#define PI3USB30532_CONF_USB3 0x04
+#define PI3USB30532_CONF_USB3_AND_2LANE_DP 0x06
+
+struct pi3usb30532_mux {
+ struct i2c_client *client;
+};
+
+static int pi3usb30532_mux_set_mux(struct mux_control *mux_ctrl, int state)
+{
+ struct pi3usb30532_mux *mux = mux_chip_priv(mux_ctrl->chip);
+ u8 conf = PI3USB30532_CONF_OPEN;
+
+ switch (state & ~MUX_USB_POLARITY_INV) {
+ case MUX_USB_NONE:
+ conf = PI3USB30532_CONF_OPEN;
+ break;
+ case MUX_USB_DEVICE:
+ case MUX_USB_HOST:
+ conf = PI3USB30532_CONF_USB3;
+ break;
+ case MUX_USB_HOST_AND_DP_SRC:
+ conf = PI3USB30532_CONF_USB3_AND_2LANE_DP;
+ break;
+ case MUX_USB_DP_SRC:
+ conf = PI3USB30532_CONF_4LANE_DP;
+ break;
+ }
+
+ if (state & MUX_USB_POLARITY_INV)
+ conf |= PI3USB30532_CONF_SWAP;
+
+ return i2c_smbus_write_byte_data(mux->client, PI3USB30532_CONF, conf);
+}
+
+static const struct mux_control_ops pi3usb30532_mux_ops = {
+ .set = pi3usb30532_mux_set_mux,
+};
+
+static int pi3usb30532_mux_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct pi3usb30532_mux *mux;
+ struct mux_chip *mux_chip;
+
+ mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux));
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ mux_chip->ops = &pi3usb30532_mux_ops;
+ mux_chip->mux[0].states = MUX_USB_STATES;
+ mux = mux_chip_priv(mux_chip);
+ mux->client = client;
+
+ return devm_mux_chip_register(dev, mux_chip);
+}
+
+static const struct i2c_device_id pi3usb30532_mux_table[] = {
+ { "pi3usb30532" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pi3usb30532_mux_table);
+
+static struct i2c_driver pi3usb30532_mux_driver = {
+ .driver = {
+ .name = "pi3usb30532",
+ },
+ .probe_new = pi3usb30532_mux_probe,
+ .id_table = pi3usb30532_mux_table,
+};
+
+module_i2c_driver(pi3usb30532_mux_driver);
+
+MODULE_AUTHOR("Hans de Goede ");
+MODULE_DESCRIPTION("Pericom PI3USB30532 Type-C mux driver");
+MODULE_LICENSE("GPL");
--
2.13.5
[PATCH 07/11] extcon: intel-int3496: Add support for controlling the USB-role mux
Cherry Trail SoCs have a built-in USB-role mux for switching between
the host and device controllers, rather then using an external mux
controller by a GPIO.
There is a driver using the mux-subsys to control this mux, this
commit adds support to the intel-int3496 driver to get a mux_controller
handle for the mux and set the mux through the mux-subsys rather then
through a GPIO.
Signed-off-by: Hans de Goede
---
drivers/extcon/Kconfig| 1 +
drivers/extcon/extcon-intel-int3496.c | 59 ++-
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..7ab6acc9708a 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -45,6 +45,7 @@ config EXTCON_GPIO
config EXTCON_INTEL_INT3496
tristate "Intel INT3496 ACPI device extcon driver"
depends on GPIOLIB && ACPI && (X86 || COMPILE_TEST)
+ select MULTIPLEXER
help
Say Y here to enable extcon support for USB OTG ports controlled by
an Intel INT3496 ACPI device.
diff --git a/drivers/extcon/extcon-intel-int3496.c
b/drivers/extcon/extcon-intel-int3496.c
index 1a45e745717d..cea9c9b1521c 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -23,8 +23,12 @@
#include
#include
#include
+#include
#include
+#include
+#include
+
#define INT3496_GPIO_USB_ID0
#define INT3496_GPIO_VBUS_EN 1
#define INT3496_GPIO_USB_MUX 2
@@ -37,6 +41,8 @@ struct int3496_data {
struct gpio_desc *gpio_usb_id;
struct gpio_desc *gpio_vbus_en;
struct gpio_desc *gpio_usb_mux;
+ struct mux_control *usb_mux;
+ bool usb_mux_set;
int usb_id_irq;
};
@@ -56,11 +62,31 @@ static const struct acpi_gpio_mapping
acpi_int3496_default_gpios[] = {
{ },
};
+static struct mux_lookup acpi_int3496_cht_mux_lookup[] = {
+ {
+ .provider = "intel_cht_usb_mux",
+ .dev_id = "INT3496:00",
+ .mux_name = "usb-role-mux",
+ },
+};
+
+#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
+
+static const struct x86_cpu_id cht_cpu_ids[] = {
+ ICPU(INTEL_FAM6_ATOM_AIRMONT), /* Braswell, Cherry Trail */
+ {}
+};
+
+static bool int3496_soc_has_mux(void)
+{
+ return x86_match_cpu(cht_cpu_ids);
+}
+
static void int3496_do_usb_id(struct work_struct *work)
{
struct int3496_data *data =
container_of(work, struct int3496_data, work.work);
- int id = gpiod_get_value_cansleep(data->gpio_usb_id);
+ int ret, id = gpiod_get_value_cansleep(data->gpio_usb_id);
/* id == 1: PERIPHERAL, id == 0: HOST */
dev_dbg(data->dev, "Connected %s cable\n", id ? "PERIPHERAL" : "HOST");
@@ -72,6 +98,22 @@ static void int3496_do_usb_id(struct work_struct *work)
if (!IS_ERR(data->gpio_usb_mux))
gpiod_direction_output(data->gpio_usb_mux, id);
+ if (data->usb_mux) {
+ /*
+* The mux framework expects multiple competing users, we must
+* release our previous setting before applying the new one.
+*/
+ if (data->usb_mux_set)
+ mux_control_deselect(data->usb_mux);
+
+ ret = mux_control_select(data->usb_mux,
+id ? MUX_USB_DEVICE : MUX_USB_HOST);
+ if (ret)
+ dev_err(data->dev, "Error setting mux: %d\n", ret);
+
+ data->usb_mux_set = ret == 0;
+ }
+
if (!IS_ERR(data->gpio_vbus_en))
gpiod_direction_output(data->gpio_vbus_en, !id);
@@ -107,6 +149,21 @@ static int int3496_probe(struct platform_device *pdev)
data->dev = dev;
INIT_DELAYED_WORK(&data->work, int3496_do_usb_id);
+ if (int3496_soc_has_mux()) {
+ mux_add_table(acpi_int3496_cht_mux_lookup,
+ ARRAY_SIZE(acpi_int3496_cht_mux_lookup));
+ data->usb_mux = devm_mux_control_get(dev, "usb-role-mux");
+ /* Doing this here keeps our error handling clean. */
+ mux_remove_table(acpi_int3496_cht_mux_lookup,
+ARRAY_SIZE(acpi_int3496_cht_mux_lookup));
+ if (IS_ERR(data->usb_mux)) {
+ ret = PTR_ERR(data->usb_mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "can't get mux: %d\n", ret);
+ return ret;
+ }
+ }
+
data->gpio_usb_id = devm_gpiod_get(dev, "id", GPIOD_IN);
if (IS_ERR(data->gpio_usb_id)) {
ret = PTR_ERR(data->gpio_usb_id);
--
2.13.5
[PATCH 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys
So far the mux functionality of the tcpm code has not been hooked up
in any tcpc drivers. This commit adds a generic TCPC mux driver using
the mux subsys, which tcpc drivers can use to provide mux functionality
in cases where an external my is used.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/Makefile | 2 +-
drivers/staging/typec/tcpc_gen_mux.c | 129 +++
drivers/staging/typec/tcpm.h | 2 +
3 files changed, 132 insertions(+), 1 deletion(-)
create mode 100644 drivers/staging/typec/tcpc_gen_mux.c
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index 30a7e29cbc9e..623d78114ee3 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
+obj-$(CONFIG_TYPEC_TCPM) += tcpm.o tcpc_gen_mux.o
obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
obj-y += fusb302/
diff --git a/drivers/staging/typec/tcpc_gen_mux.c
b/drivers/staging/typec/tcpc_gen_mux.c
new file mode 100644
index ..dc725e17b106
--- /dev/null
+++ b/drivers/staging/typec/tcpc_gen_mux.c
@@ -0,0 +1,129 @@
+/*
+ * Generic TCPC mux driver using the mux subsys
+ *
+ * Copyright (c) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include "tcpm.h"
+
+struct tcpc_gen_mux_data {
+ struct tcpc_mux_dev mux;
+ struct device *dev;
+ struct mux_control *type_c_mode_mux; /* Type-C cross switch / mux */
+ struct mux_control *usb_role_mux;/* USB Device / Host mode mux */
+ bool muxes_set;
+};
+
+static int tcpc_gen_mux_set(struct tcpc_mux_dev *mux_dev,
+ enum tcpc_mux_mode mux_mode,
+ enum tcpc_usb_switch usb_config,
+ enum typec_cc_polarity polarity)
+{
+ struct tcpc_gen_mux_data *data =
+ container_of(mux_dev, struct tcpc_gen_mux_data, mux);
+ unsigned int state = MUX_USB_NONE;
+ int ret;
+
+ switch (mux_mode) {
+ case TYPEC_MUX_NONE:
+ state = MUX_USB_NONE;
+ break;
+ case TYPEC_MUX_USB_DEVICE:
+ state = MUX_USB_DEVICE;
+ break;
+ case TYPEC_MUX_USB_HOST:
+ state = MUX_USB_HOST;
+ break;
+ case TYPEC_MUX_DP:
+ state = MUX_USB_DP_SRC;
+ break;
+ case TYPEC_MUX_DOCK:
+ state = MUX_USB_HOST_AND_DP_SRC;
+ break;
+ }
+
+ if (polarity)
+ state |= MUX_USB_POLARITY_INV;
+
+ /*
+* The mux framework expects multiple competing users, so we must
+* release our previous setting before applying the new one.
+*/
+ if (data->muxes_set) {
+ mux_control_deselect(data->type_c_mode_mux);
+ if (data->usb_role_mux)
+ mux_control_deselect(data->usb_role_mux);
+ data->muxes_set = false;
+ }
+
+ ret = mux_control_select(data->type_c_mode_mux, state);
+ if (ret) {
+ dev_err(data->dev, "Error setting Type-C mode mux: %d\n", ret);
+ return ret;
+ }
+
+ if (!data->usb_role_mux)
+ goto out;
+
+ ret = mux_control_select(data->usb_role_mux, state);
+ if (ret) {
+ dev_err(data->dev, "Error setting USB role mux: %d\n", ret);
+ mux_control_deselect(data->type_c_mode_mux);
+ return ret;
+ }
+
+out:
+ data->muxes_set = true;
+ return 0;
+}
+
+struct tcpc_mux_dev *devm_tcpc_gen_mux_create(struct device *dev)
+{
+ struct tcpc_gen_mux_data *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ data->type_c_mode_mux = devm_mux_control_get(dev, "type-c-mode-mux");
+ if (IS_ERR(data->type_c_mode_mux)) {
+ ret = PTR_ERR(data->type_c_mode_mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Error getting Type-C mux: %d\n", ret);
+ return ERR_PTR(-ret);
+ }
+
+ data->usb_role_mux = devm_mux_control_get(dev, "usb-role-mux");
+ if (IS_ERR(data->usb_role_mux)) {
+ ret = PTR_ERR(data->usb_role_mux);
+ /* The USB role mux is optional */
+ if (ret == -ENODEV) {
+ data->usb_role_mux = NULL;
+ } else {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Error getting USB role mux: %d\n",
+ ret);
+ return ERR_PTR(
Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions
On Fri, Sep 01, 2017 at 10:15:39PM +0100, David Howells wrote:
> Peter Zijlstra wrote:
>
> > > unsigned int refcount_dec_return(refcount_t *r);
> > > unsigned int refcount_inc_return(refcount_t *r);
> > >
> >
> > I'm not immediately seeing how wanting 1 to mean unused leads to
> > requiring these two functions.
>
> Did you read the other other part of the description?
>
> Further, both functions can be used to accurately trace the refcount
> (refcount_inc() followed by refcount_read() can't be considered
> accurate).
I must admit to having overlooked that. But can we treat the two issues
separately? They are quite distinct.
> > If you'll remember, I did that for inode_count and only needed
> > dec_unless().
>
> I don't remember. inode_count? I can't find such a thing - did you mean
> i_count? I don't find anything matching "dec_unless.*i_count" either.
Ah, yes, i_count. See these:
https://lkml.kernel.org/r/20170224162044.479190...@infradead.org
https://lkml.kernel.org/r/20170224162044.548813...@infradead.org
But looking at them, i_count was rather special, a normal GC based
scheme doesn't need anything new AFAICT:
add:
spin_lock(&map->lock)
refcount_set(&obj->refs, 1);
map_link(map, obj);
spin_unlock(&map->lock);
lookup:
rcu_read_lock();
obj = map_find(map, key);
if (obj && !refcount_inc_not_zero(&obj->refs))
obj = NULL;
rcu_read_unlock();
if (obj) {
/* use obj */
refcount_dec(&obj->refs); /* should never hit 0 */
}
GC:
spin_lock(&map->lock);
map_for_each_obj_safe(obj, map) {
if (refcount_dec_if_one(&obj->refs)) {
map_unlink(map, obj);
rcu_free(obj);
}
}
spin_unlock(&map->lock);
[PATCH 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support
Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create()
to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us.
Also document the mux-names used by the generic tcpc_mux_dev code in
our devicetree bindings.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++
drivers/staging/typec/fusb302/fusb302.c | 11 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
index 472facfa5a71..63d639eadacd 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -6,6 +6,9 @@ Required properties :
- interrupts : Interrupt specifier
Optional properties :
+- mux-controls : List of mux-ctrl-specifiers containing 1 or 2 muxes
+- mux-names : "type-c-mode-mux" when using 1 mux, or
+ "type-c-mode-mux", "usb-role-mux" when using 2 muxes
- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink
- fcs,max-sink-microamp : Maximum current to negotiate when configured as sink
- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink
diff --git a/drivers/staging/typec/fusb302/fusb302.c
b/drivers/staging/typec/fusb302/fusb302.c
index cf6355f59cd9..00d045d0246b 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1259,7 +1259,6 @@ static void init_tcpc_dev(struct tcpc_dev
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
fusb302_tcpc_dev->pd_transmit = tcpm_pd_transmit;
- fusb302_tcpc_dev->mux = NULL;
}
static const char * const cc_polarity_name[] = {
@@ -1817,6 +1816,16 @@ static int fusb302_probe(struct i2c_client *client,
return -EPROBE_DEFER;
}
+ chip->tcpc_dev.mux = devm_tcpc_gen_mux_create(dev);
+ if (IS_ERR(chip->tcpc_dev.mux)) {
+ ret = PTR_ERR(chip->tcpc_dev.mux);
+ /* Use of a mux is optional (for now?), ignore -ENODEV errors */
+ if (ret == -ENODEV)
+ chip->tcpc_dev.mux = NULL;
+ else
+ return ret;
+ }
+
cfg.drv_data = chip;
chip->psy = devm_power_supply_register(dev, &fusb302_psy_desc, &cfg);
if (IS_ERR(chip->psy)) {
--
2.13.5
[PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port
We need to add mappings for the mux subsys to be able to find the
muxes for the fusb302 driver to be able to control the PI3USB30532
Type-C mux and the device/host mux integrated in the CHT SoC.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/intel_cht_int33fe.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index c5554577681a..4256e05ee584 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -794,6 +794,7 @@ config ACPI_CMPC
config INTEL_CHT_INT33FE
tristate "Intel Cherry Trail ACPI INT33FE Driver"
depends on X86 && ACPI && I2C && REGULATOR
+ select MULTIPLEXER
---help---
This driver add support for the INT33FE ACPI device found on
some Intel Cherry Trail devices.
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 24a1662be81d..611b8af9cefd 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,6 +36,19 @@ struct cht_int33fe_data {
struct i2c_client *pi3usb30532;
};
+static struct mux_lookup cht_int33fe_mux_lookup[] = {
+ {
+ .provider = "i2c-pi3usb30532",
+ .dev_id = "i2c-fusb302",
+ .mux_name = "type-c-mode-mux",
+ },
+ {
+ .provider = "intel_cht_usb_mux",
+ .dev_id = "i2c-fusb302",
+ .mux_name = "usb-role-mux",
+ },
+};
+
/*
* Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
* the max17047 both through the INT33FE ACPI device (it is right there
@@ -170,6 +184,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
board_info.properties = fusb302_props;
board_info.irq = fusb302_irq;
+ mux_add_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
data->fusb302 = i2c_acpi_new_device(dev, 2, &board_info);
if (!data->fusb302)
goto out_unregister_max17047;
@@ -193,6 +210,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ mux_remove_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
}
@@ -205,6 +225,9 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ mux_remove_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
return 0;
}
--
2.13.5
[PATCH 08/11] staging: typec: tcpm: Set mux to device mode when configured as such
Setting the mux to TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT when the
data-role is device is not correct. Plenty of devices support operating
as USB device through a (separate) USB device controller.
So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST
and TYPEC_MUX_USB_DEVICE and makes tcpm_set_roles() set the mux
accordingly.
Likewise TCPC_MUX_DP gets renamed to TCPC_MUX_DP_SRC to make clear that
this is for configuring the Type-C port as a Display Port source, not a
sink.
Last this commit makes tcpm_reset_port() to set the mux to
TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT so that it does not and up
staying in host (and with this commit also device) mode after a detach.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/tcpm.c | 7 ---
drivers/staging/typec/tcpm.h | 22 ++
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 8af62e74d54c..ffe7e26d4ed3 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -752,11 +752,11 @@ static int tcpm_set_roles(struct tcpm_port *port, bool
attached,
int ret;
if (data == TYPEC_HOST)
- ret = tcpm_mux_set(port, TYPEC_MUX_USB,
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_HOST,
TCPC_USB_SWITCH_CONNECT);
else
- ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
- TCPC_USB_SWITCH_DISCONNECT);
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_DEVICE,
+ TCPC_USB_SWITCH_CONNECT);
if (ret < 0)
return ret;
@@ -2025,6 +2025,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
index 7e9a6b7b5cd6..f662eed48c86 100644
--- a/drivers/staging/typec/tcpm.h
+++ b/drivers/staging/typec/tcpm.h
@@ -83,17 +83,23 @@ enum tcpc_usb_switch {
};
/* Mux state attributes */
-#define TCPC_MUX_USB_ENABLED BIT(0) /* USB enabled */
-#define TCPC_MUX_DP_ENABLEDBIT(1) /* DP enabled */
-#define TCPC_MUX_POLARITY_INVERTED BIT(2) /* Polarity inverted */
+#define TCPC_MUX_USB_DEVICE_ENABLEDBIT(0) /* USB device enabled */
+#define TCPC_MUX_USB_HOST_ENABLED BIT(1) /* USB host enabled */
+#define TCPC_MUX_DP_SRC_ENABLEDBIT(2) /* DP enabled */
+#define TCPC_MUX_POLARITY_INVERTED BIT(3) /* Polarity inverted */
/* Mux modes, decoded to attributes */
enum tcpc_mux_mode {
- TYPEC_MUX_NONE = 0,/* Open switch */
- TYPEC_MUX_USB = TCPC_MUX_USB_ENABLED, /* USB only */
- TYPEC_MUX_DP= TCPC_MUX_DP_ENABLED, /* DP only */
- TYPEC_MUX_DOCK = TCPC_MUX_USB_ENABLED |/* Both USB and DP */
- TCPC_MUX_DP_ENABLED,
+ /* Open switch */
+ TYPEC_MUX_NONE = 0,
+ /* USB device only */
+ TYPEC_MUX_USB_DEVICE = TCPC_MUX_USB_DEVICE_ENABLED,
+ /* USB host only */
+ TYPEC_MUX_USB_HOST = TCPC_MUX_USB_HOST_ENABLED,
+ /* DP source only */
+ TYPEC_MUX_DP = TCPC_MUX_DP_SRC_ENABLED,
+ /* Both USB host and DP source */
+ TYPEC_MUX_DOCK = TCPC_MUX_USB_HOST_ENABLED | TCPC_MUX_DP_SRC_ENABLED,
};
struct tcpc_mux_dev {
--
2.13.5
[PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver
Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port
USB data lines between the xHCI host controller and the dwc3 gadget
controller. On some Cherrytrail systems this mux is controlled through
AML code reacting on a GPIO IRQ connected to the USB OTG id pin (through
an _AIE ACPI method) so things just work.
But on other Cherrytrail systems we need to control the mux ourselves
this driver exports the mux through the mux subsys, so that other drivers
can control it if necessary.
This driver also updates the vbus-valid reporting to the dwc3 gadget
controller, as this uses the same registers as the mux. This is needed
for gadget/device mode to work properly (even on systems which control
the mux from their AML code).
Note this depends on the xhci driver registering a platform device
named "intel_cht_usb_mux", which has an IOMEM resource 0 which points
to the Intel Vendor Defined XHCI extended capabilities region.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Complete rewrite as a stand-alone platform-driver rather then as a phy
driver, since this is just a mux, not a phy
Changes in v3:
-Make this a mux subsys driver instead of listening to USB_HOST extcon
cable events and responding to those
---
drivers/mux/Kconfig | 11 ++
drivers/mux/Makefile| 2 +
drivers/mux/intel_cht_usb_mux.c | 269
3 files changed, 282 insertions(+)
create mode 100644 drivers/mux/intel_cht_usb_mux.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 19e4e904c9bf..17938918bf93 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -34,6 +34,17 @@ config MUX_GPIO
To compile the driver as a module, choose M here: the module will
be called mux-gpio.
+config MUX_CHT_USB_MUX
+ tristate "Intel Cherrytrail USB Multiplexer"
+ depends on ACPI && X86 && EXTCON
+ help
+ This driver adds support for the internal USB mux for muxing the OTG
+ USB data lines between the xHCI host controller and the dwc3 gadget
+ controller found on Intel Cherrytrail SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-intel_cht_usb_mux.
+
config MUX_MMIO
tristate "MMIO register bitfield-controlled Multiplexer"
depends on (OF && MFD_SYSCON) || COMPILE_TEST
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 0e1e59760e3f..a12e812c7966 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -6,8 +6,10 @@ mux-core-objs := core.o
mux-adg792a-objs := adg792a.o
mux-gpio-objs := gpio.o
mux-mmio-objs := mmio.o
+mux-intel_cht_usb_mux-objs := intel_cht_usb_mux.o
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
+obj-$(CONFIG_MUX_CHT_USB_MUX) += mux-intel_cht_usb_mux.o
diff --git a/drivers/mux/intel_cht_usb_mux.c b/drivers/mux/intel_cht_usb_mux.c
new file mode 100644
index ..7b1621a081d8
--- /dev/null
+++ b/drivers/mux/intel_cht_usb_mux.c
@@ -0,0 +1,269 @@
+/*
+ * Intel Cherrytrail USB OTG MUX driver
+ *
+ * Copyright (c) 2016 Hans de Goede
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Author: Wu, Hao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include /* For the MUX_USB_* defines */
+#include
+#include
+#include
+
+/* register definition */
+#define DUAL_ROLE_CFG0 0x68
+#define SW_VBUS_VALID (1 << 24)
+#define SW_IDPIN_EN(1 << 21)
+#define SW_IDPIN (1 << 20)
+
+#define DUAL_ROLE_CFG1 0x6c
+#define HOST_MODE (1 << 29)
+
+#define DUAL_ROLE_CFG1_POLL_TIMEOUT1000
+
+#define DRV_NAME "intel_cht_usb_mux"
+
+struct intel_cht_usb_mux {
+ struct mutex cfg0_lock;
+ void __iomem *base;
+ struct extcon_dev *vbus_extcon;
+ struct notifier_block vbus_nb;
+ struct work_struct vbus_work;
+};
+
+struct intel_cht_extcon_info {
+ const char *hid;
+ int hrv;
+ const char *extcon;
+};
+
+struct intel_cht_extcon_info vbus_providers[] = {
+ { "INT33F4", -1, "axp288_extcon" },
+ { "INT34D3", 3, "cht_wcove_pwrsrc" },
+};
+
+static const unsigned int vbus_cable_ids[] = {
+ EXTCON_CHG_USB_SDP, EXTCON_CHG_USB_CDP, EXTCON_CHG_USB_DCP,
+ EXTCON_CHG_USB_ACA, EXTCON_CHG_USB_FAST,
+};
+
+static void intel_cht_usb_mux_set_sw_mode(struct intel_cht_usb_mux *mux)
+{
+ u32 data;
+
[PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems
Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux drivers 3) Hookup the Intel CHT USB mux driver for CHT devices without Type-C 4) Hookup both the Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux drivers to the fusb302 Type-C port controller found on some CHT x86 devs Please review, or in the case of the drivers/mux changes (which are a dep for some of the other patches) merge if the patches are ready. Regards, Hans
[PATCH 01/11] mux: core: Add of_mux_control_get helper function
Currently the mux_control_get implementation only deals with getting
mux controllers on DT platforms. This commit renames the current
implementation to of_mux_control_get to reflect this and makes
mux_control_get a wrapper around of_mux_control_get.
This is a preparation patch for adding support for getting muxes on
non DT platforms.
Signed-off-by: Hans de Goede
---
drivers/mux/core.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index e75d5adc5949..6142493c327b 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -422,14 +422,8 @@ static struct mux_chip *of_get_mux_chip_by_node(struct
device_node *np)
return dev ? to_mux_chip(dev) : NULL;
}
-/**
- * mux_control_get() - Get the mux-control for a device.
- * @dev: The device that needs a mux-control.
- * @mux_name: The name identifying the mux-control.
- *
- * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
- */
-struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
+static struct mux_control *of_mux_control_get(struct device *dev,
+ const char *mux_name)
{
struct device_node *np = dev->of_node;
struct of_phandle_args args;
@@ -483,6 +477,22 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
return &mux_chip->mux[controller];
}
+
+/**
+ * mux_control_get() - Get the mux-control for a device.
+ * @dev: The device that needs a mux-control.
+ * @mux_name: The name identifying the mux-control.
+ *
+ * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
+ */
+struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
+{
+ /* look up via DT first */
+ if (IS_ENABLED(CONFIG_OF) && dev->of_node)
+ return of_mux_control_get(dev, mux_name);
+
+ return ERR_PTR(-ENODEV);
+}
EXPORT_SYMBOL_GPL(mux_control_get);
/**
--
2.13.5
[PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines
Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede --- include/linux/mux/consumer.h | 16 1 file changed, 16 insertions(+) diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h index 912dd48a3a5d..e3ec9b4db962 100644 --- a/include/linux/mux/consumer.h +++ b/include/linux/mux/consumer.h @@ -15,6 +15,22 @@ #include +/* + * Mux state values for USB muxes, used for both USB device/host role muxes + * as well as for Type-C polarity/role/altmode muxes. + * + * MUX_USB_POLARITY_INV may be or-ed together with any other mux-state as + * inverted-polarity (Type-C plugged in upside down) can happen with any + * other mux-state. + */ +#define MUX_USB_POLARITY_INV BIT(0) /* Polarity inverted bit */ +#define MUX_USB_NONE (1 << 1) /* Mux open / not connected */ +#define MUX_USB_DEVICE (2 << 1) /* USB device mode */ +#define MUX_USB_HOST (3 << 1) /* USB host mode */ +#define MUX_USB_HOST_AND_DP_SRC(4 << 1) /* USB host + 2 lanes Display Port */ +#define MUX_USB_DP_SRC (5 << 1) /* 4 lanes Display Port source */ +#define MUX_USB_STATES (6 << 1) + struct device; struct mux_control; -- 2.13.5
Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
On 1 September 2017 at 21:22, Kees Cook wrote:
> Using .text.unlikely for refcount exceptions isn't safe because gcc may
> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
> would cause any uses of a protected refcount_t function to stay inline
> with the function, triggering the protection unconditionally:
>
> .section.text.unlikely,"ax",@progbits
> .type in6_dev_get, @function
> in6_dev_getx:
> .LFB4673:
> .loc 2 4128 0
> .cfi_startproc
> ...
> lock; incl 480(%rbx)
> js 111f
> .pushsection .text.unlikely
> 111:lea 480(%rbx), %rcx
> 112:.byte 0x0f, 0xff
> .popsection
> 113:
>
> This creates a unique .text section and adds an additional test to the
> exception handler to WARN in the case of having none of OF, SF, nor ZF
> set so we can see things like this more easily in the future.
>
> Reported-by: Mike Galbraith
> Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount
> overflow protection")
> Signed-off-by: Kees Cook
> ---
> arch/x86/Kconfig | 2 +-
> arch/x86/include/asm/refcount.h | 2 +-
> arch/x86/mm/extable.c | 7 ++-
> include/asm-generic/vmlinux.lds.h | 1 +
> 4 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eaa8ff41f424..c6acdcdb3fc6 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -56,7 +56,7 @@ config X86
> select ARCH_HAS_MMIO_FLUSH
> select ARCH_HAS_PMEM_APIif X86_64
> # Causing hangs/crashes, see the commit that added this change for
> details.
> - select ARCH_HAS_REFCOUNTif BROKEN
> + select ARCH_HAS_REFCOUNT
> select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
> select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_SG_CHAIN
> diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h
> index ff871210b9f2..4e44250e7d0d 100644
> --- a/arch/x86/include/asm/refcount.h
> +++ b/arch/x86/include/asm/refcount.h
> @@ -15,7 +15,7 @@
> * back to the regular execution flow in .text.
> */
> #define _REFCOUNT_EXCEPTION\
> - ".pushsection .text.unlikely\n" \
> + ".pushsection .text..refcount\n"\
You could also use a .subsection here: those are always emitted out of
line, but into the same section.
> "111:\tlea %[counter], %%" _ASM_CX "\n" \
> "112:\t" ASM_UD0 "\n" \
> ASM_UNREACHABLE \
> diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
> index c076f710de4c..cf0d74b47ae0 100644
> --- a/arch/x86/mm/extable.c
> +++ b/arch/x86/mm/extable.c
> @@ -66,12 +66,17 @@ bool ex_handler_refcount(const struct
> exception_table_entry *fixup,
> * wrapped around) will be set. Additionally, seeing the refcount
> * reach 0 will set ZF (Zero Flag: result was zero). In each of
> * these cases we want a report, since it's a boundary condition.
> -*
> +* The SF case is not reported since it indicates post-boundary
> +* manipulations below zero or above INT_MAX. And if none of the
> +* flags are set, something has gone very wrong, so report it.
> */
> if (regs->flags & (X86_EFLAGS_OF | X86_EFLAGS_ZF)) {
> bool zero = regs->flags & X86_EFLAGS_ZF;
>
> refcount_error_report(regs, zero ? "hit zero" : "overflow");
> + } else if ((regs->flags & X86_EFLAGS_SF) == 0) {
> + /* Report if none of OF, ZF, nor SF are set. */
> + refcount_error_report(regs, "unexpected saturation");
> }
>
> return true;
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index 8acfc1e099e1..e549bff87c5b 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -459,6 +459,7 @@
> #define TEXT_TEXT \
> ALIGN_FUNCTION(); \
> *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \
> + *(.text..refcount) \
> *(.ref.text)\
> MEM_KEEP(init.text) \
> MEM_KEEP(exit.text) \
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
[PULL REQUEST] i2c for 4.13
Linus, I2C has two bugfixes for you: the ismt driver had a problem with a rarely used transaction type and the designware driver was made even more robust against non standard ACPI tables. Please pull. Thanks, Wolfram The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98: Linux 4.13-rc7 (2017-08-27 17:20:40 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 231d069fcde22bd0582c2c9564f1b334d280c7d7: i2c: designware: Round down ACPI provided clk to nearest supported clk (2017-08-31 20:27:39 +0200) Hans de Goede (1): i2c: designware: Round down ACPI provided clk to nearest supported clk Stephen Douthit (2): i2c: ismt: Don't duplicate the receive length for block reads i2c: ismt: Return EMSGSIZE for block reads with bogus length with much appreciated quality assurance from Dan Priamo (2): (Test) i2c: ismt: Return EMSGSIZE for block reads with bogus length (Test) i2c: ismt: Don't duplicate the receive length for block reads drivers/i2c/busses/i2c-designware-platdrv.c | 16 drivers/i2c/busses/i2c-ismt.c | 6 -- 2 files changed, 16 insertions(+), 6 deletions(-) signature.asc Description: PGP signature
RE: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking
>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:44 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org; ryan.lee.ma...@gmail.com >Subject: Re: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking > >On Mon, Aug 28, 2017 at 04:30:54PM -0700, Ryan Lee wrote: > >> /* Envelope Tracking configuration */ >> regmap_write(max98927->regmap, >> MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM, >> -0x08); >> +0x0A); >> regmap_write(max98927->regmap, >> MAX98927_R0086_ENV_TRACK_CTRL, >> 0x01); >> -regmap_write(max98927->regmap, >> -MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ, >> -0x10); > >Why are we changing the defaults here? It was understandable to have a fixed >default that differed from the chip value when there was no control but now >there is a control and we're changing the default again for some undocumented >reason. It'd be better to leave the values here to avoid breaking >compatibility >with existing users and let users who need different values change things using >the newly added controls. Thank you for feedback. Let me keep existing value. I still need to remove regmap_write for R:0x87 because it is read-only register.
RE: [PATCH 5/9] ASoC: max98927: Removed obsolete variables
>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:54 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org; ryan.lee.ma...@gmail.com >Subject: Re: [PATCH 5/9] ASoC: max98927: Removed obsolete variables > >On Mon, Aug 28, 2017 at 04:30:57PM -0700, Ryan Lee wrote: >> Signed-off-by: Ryan Lee > >Why are these variables obsolete? If their use was removed in earlier patches >in >the series they should be handled in that patch, if they're just unused say >so. In >general your changelogs could really benefit from being a bit longer and >explaining why changes are being made. > >> mode change 100644 => 100755 sound/soc/codecs/max98927.h > >This also changes the permissions to be executable which isn't what we want. Thank you for your comment. I wanted to remove these variables because it have never been referred in max98927.c from the beginning.
RE: [PATCH 1/9] ASoC: max98927: Added support for DSP_A and DSP_B format
>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Tuesday, August 29, 2017 12:00 PM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org; ryan.lee.ma...@gmail.com >Subject: Re: [PATCH 1/9] ASoC: max98927: Added support for DSP_A and DSP_B >format > >On Mon, Aug 28, 2017 at 04:30:53PM -0700, Ryan Lee wrote: > >> +if ((max98927->iface == SND_SOC_DAIFMT_DSP_A) || >> +(max98927->iface == SND_SOC_DAIFMT_DSP_B)) >> +return 0; >> + >> +/* BCLK configuration */ > >Why do we not configure the BCLK in DSP modes? That's unusual and seems >likely to break some systems that rely on exact clocking. I put this code to avoid overwrite BCLK value in TDM mode. BCLK is being configured by ' max98927_dai_tdm_slot'. Now I added one more variable to check TDM mode instead of checking DAI_FMT. > >Also if we're selecting on format a switch statement is generally better to >make >any further special casing easier in future. OK. Thanks. But I kept if statement on the modified version because it only have two cases, tdm and non-tdm.
