* RE: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
From: Jun Li @ 2020-02-20 15:37 UTC (permalink / raw)
To: Martin Kepplinger, Peter Chen, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org, dl-linux-imx, Anson Huang,
shawnguo@kernel.org, kernel@pengutronix.de
In-Reply-To: <ddbb9543-f632-b1da-cbb8-d390fcd3b4f8@puri.sm>
> -----Original Message-----
> From: Martin Kepplinger <martin.kepplinger@puri.sm>
> Sent: 2020年2月20日 19:44
> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
> mathias.nyman@intel.com
> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Anson Huang
> <anson.huang@nxp.com>; shawnguo@kernel.org; kernel@pengutronix.de
> Subject: Re: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
>
> On 20.02.20 07:31, Jun Li wrote:
> >> -----Original Message-----
> >> From: Martin Kepplinger <martin.kepplinger@puri.sm>
> >> Sent: 2020年2月20日 1:37
> >> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
> >> mathias.nyman@intel.com
> >> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> >> Anson Huang <anson.huang@nxp.com>; shawnguo@kernel.org;
> >> kernel@pengutronix.de
> >> Subject: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
> >>
> >> From: Li Jun <jun.li@nxp.com>
> >>
> >> i.MX8MQ USB3 host needs XHCI_MISSING_CAS quirk to warm reset the port
> >> to enum the
> >> USB3 device plugged in while system sleep, as the port state is stuck
> >> in polling mode after resume.
> >>
> >> Signed-off-by: Li Jun <jun.li@nxp.com>
> >> Acked-by: Peter Chen <peter.chen@nxp.com>
> >> ---
> >>
> >> Hi,
> >>
> >> Because resume from S3 suspend is broken for me on imx8mq, I stumbled
> >> upon this patch in NXP's linux tree. (Please note that I'm not the
> >> author and I've not yet put my SoB tag under it). This is just a
> >> question:
> >>
> >> This patch (and the docs) clearly is missing in mainline Linux
> >> because the imx8mq devicetree description includes it (which does nothing now).
> >>
> >> I've tested this and this particular addition doesn't fix my problem:
> >>
> >> [ 84.257538] imx8mq-usb-phy 381f0040.usb-phy: bus resume
> >> [ 84.263195] imx8mq-usb-phy 382f0040.usb-phy: bus resume
> >> [ 84.268898] dwc3 38100000.usb: driver resume
> >>
> >> during resume from S3 suspend, here it still hangs.
> >
> > Is your problem a system hang? If yes, this may another issue, where
> > the hang happens? dwc3_resume_common()?
>
> exactly! I followed to the point it hangs once again and it's
>
> dwc3_core_init() called from dwc3_resume_common()'s "OTG" case.
>
> Specifically, dwc3_writel() is what I don't get past:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootl
> in.com%2Flinux%2Fv5.6-rc2%2Fsource%2Fdrivers%2Fusb%2Fdwc3%2Fcore.c%23L934&
> data=02%7C01%7Cjun.li%40nxp.com%7C130cd29875c44792d1a908d7b5fa2516%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C637177958284696041&sdata=mqh9MH6ESLVxKvW
> vvMq4vwt2dcTuvNopgGVdXEbbMwk%3D&reserved=0
So while dwc3 resume, the first register access cause hang.
Looks like some required clocks or power domain of USB0 is not on.
>
> do you have an idea why this writel() hangs?
I never encounter such hang on my iMX8MQ EVK board
using upstream kernel(5.x) + changes of enable USB0 port,
but I didn't try latest 5.6 kernel.
I will enable the first port based on Linux-next to give a
try on my NXP iMX8MQ EVK board, do you think I can reproduce
your problem?
Li Jun
>
> >
> > The question patch is to give a warm reset for connected USB device if
> > the link state is not connect/CAS after system resume, otherwise host
> > will wait 2s for device appear:
> >
> > [ 44.834831] usb 2-1: Waited 2000ms for CONNECT
> > ...
> > [ 45.055718] PM: resume devices took 3.132 seconds
> >
> > I will post this patch and doc(to be updated) to upstream later.
> >
>
> ok, good, thanks,
>
> martin
^ permalink raw reply
* Re: [PATCH 3/3] btrfs: Make btrfs_check_uuid_tree private to disk-io.c
From: Josef Bacik @ 2020-02-20 15:37 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
In-Reply-To: <20200218145609.13427-4-nborisov@suse.com>
On 2/18/20 9:56 AM, Nikolay Borisov wrote:
> It's used only during fs mount as such it can be made private to
> disk-io.c file. Also use the occassion to move btrfs_uuid_rescan_kthread
> as btrfs_check_uuid_tree is its sole caller. No functional changes.
> ---
Forgot your signed-off-by here as well. And it's "occasion".
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [Xen-devel] [PATCH] x86/vpt: update last_guest_time with cmpxchg and drop pl_time_lock
From: Igor Druzhinin @ 2020-02-20 15:37 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, roger.pau, wl, andrew.cooper3
In-Reply-To: <86036433-0dd9-773c-3855-fb4b4697fc08@suse.com>
On 20/02/2020 08:27, Jan Beulich wrote:
> On 19.02.2020 19:52, Igor Druzhinin wrote:
>> On 19/02/2020 07:48, Jan Beulich wrote:
>>> On 20.12.2019 22:39, Igor Druzhinin wrote:
>>>> @@ -38,24 +37,22 @@ void hvm_init_guest_time(struct domain *d)
>>>> uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_tsc)
>>>> {
>>>> struct pl_time *pl = v->domain->arch.hvm.pl_time;
>>>> - u64 now;
>>>> + s_time_t old, new, now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>>
>>>> /* Called from device models shared with PV guests. Be careful. */
>>>> ASSERT(is_hvm_vcpu(v));
>>>>
>>>> - spin_lock(&pl->pl_time_lock);
>>>> - now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>> -
>>>> if ( !at_tsc )
>>>> {
>>>> - if ( (int64_t)(now - pl->last_guest_time) > 0 )
>>>> - pl->last_guest_time = now;
>>>> - else
>>>> - now = ++pl->last_guest_time;
>>>> + do {
>>>> + old = pl->last_guest_time;
>>>> + new = now > pl->last_guest_time ? now : old + 1;
>>>> + } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>>>
>>> I wonder whether you wouldn't better re-invoke get_s_time() in
>>> case you need to retry here. See how the function previously
>>> was called only after the lock was already acquired.
>>
>> If there is a concurrent writer, wouldn't it just update pl->last_guest_time
>> with the new get_s_time() and then we subsequently would just use the new
>> time on retry?
>
> Yes, it would, but the latency until the retry actually occurs
> is unknown (in particular if Xen itself runs virtualized). I.e.
> in the at_tsc == 0 case I think the value would better be
> re-calculated on every iteration.
Why does it need to be recalculated if a concurrent writer did this
for us already anyway and (get_s_time_fixed(at_tsc) + pl->stime_offset)
value is common for all of vCPUs? Yes, it might reduce jitter slightly
but overall latency could come from any point (especially in case of
rinning virtualized) and it's important just to preserve invariant that
the value is monotonic across vCPUs.
> Anther thing I notice only now are the multiple reads of
> pl->last_guest_time. Wouldn't you better do
>
> do {
> old = ACCESS_ONCE(pl->last_guest_time);
> new = now > old ? now : old + 1;
> } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>
> ?
Fair enough, although even reading it multiple times wouldn't cause
any harm as any inconsistency would be resolved by cmpxchg op. I'd
prefer to make it in a separate commit to unify it with pv_soft_rdtsc().
Igor
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
From: Thomas Monjalon @ 2020-02-20 15:37 UTC (permalink / raw)
To: Ye Xiaolong, taox.zhu, Ferruh Yigit
Cc: dev, konstantin.ananyev, wenzhuo.lu, stable
In-Reply-To: <2b14bca2-f69c-bd29-8e6c-65a174ed609e@intel.com>
17/02/2020 14:01, Ferruh Yigit:
> On 2/15/2020 3:41 PM, Ye Xiaolong wrote:
> > On 01/15, taox.zhu@intel.com wrote:
> >> From: Zhu Tao <taox.zhu@intel.com>
> >>
> >> IXGBE link status task use rte alarm thread in old implementation.
> >
> > s/use/uses
> >
> >> Sometime ixgbe link status task takes up to 9 seconds. This will
> >> severely affect the rte-alarm-thread-dependent a task in the
> >> system, like interrupt or hotplug event. So replace with a
> >
> > s/a/an
> >
> >> independent thread which has the same thread affinity settings
> >> as rte interrupt.
> >>
> >> Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link update")
> >
> > Should be:
> >
> > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link update")
> >
> >> Cc: stable@dpdk.org
> >>
> >
> > Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.
> >
>
> Shared build is failing because of missing pthread library, fixing while merging
> to next-net:
One more thing looks strange in this patch:
ixgbe_dev_cannel_link_thread
Should it be
ixgbe_dev_cancel_link_thread
?
Note: I looked at it because I am not sure multiplying the interrupt
threads is a good idea.
Basically the link status management is too long in this driver.
Instead of fixing the root cause, you move the annoying workload
somewhere else. But it is still there...
Please could you work on a long term fix?
^ permalink raw reply
* Re: [PATCH 1/3] btrfs: Call btrfs_check_uuid_tree_entry directly in btrfs_uuid_tree_iterate
From: Josef Bacik @ 2020-02-20 15:36 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
In-Reply-To: <20200218145609.13427-2-nborisov@suse.com>
On 2/18/20 9:56 AM, Nikolay Borisov wrote:
> btrfs_uuid_tree_iterate is called from only once place and its 2nd
> argument is always btrfs_check_uuid_tree_entry. Simplify
> btrfs_uuid_tree_iterate's signature by removing its 2nd argument and
> directly calling btrfs_check_uuid_tree_entry. Also move the latter
> into uuid-tree.h. No functional changes.
You forgot your signed-off-by
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
From: linmiaohe @ 2020-02-20 15:36 UTC (permalink / raw)
To: pbonzini, rkrcmar, sean.j.christopherson, vkuznets, wanpengli,
jmattson, joro, tglx, mingo, bp, hpa
Cc: linmiaohe, kvm, linux-kernel, x86
From: Miaohe Lin <linmiaohe@huawei.com>
When get user eoi value failed, var val would be uninitialized and result
in calculating pending eoi from an uninitialized val. Initialize var val
to 0 to fix this case.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
arch/x86/kvm/lapic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4f14ec7525f6..7e77e94f3176 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
{
- u8 val;
+ u8 val = 0;
if (pv_eoi_get_user(vcpu, &val) < 0)
printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
(unsigned long long)vcpu->arch.pv_eoi.msr_val);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH -next] pinctrl: mediatek: remove set but not used variable 'e'
From: Linus Walleij @ 2020-02-20 15:14 UTC (permalink / raw)
To: YueHaibing
Cc: linux-arm-kernel, Sean Wang, linux-kernel@vger.kernel.org,
Light Hsieh, open list:GPIO SUBSYSTEM,
moderated list:ARM/Mediatek SoC support, Matthias Brugger
In-Reply-To: <20200218023625.14324-1-yuehaibing@huawei.com>
On Tue, Feb 18, 2020 at 3:36 AM YueHaibing <yuehaibing@huawei.com> wrote:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c: In function mtk_hw_pin_field_lookup:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:70:39: warning:
> variable e set but not used [-Wunused-but-set-variable]
>
> Since commit 3de7deefce69 ("pinctrl: mediatek: Check gpio pin
> number and use binary search in mtk_hw_pin_field_lookup()"),
> it is not used any more, so remove it, also remove redundant
> assignment to variable c, it will be assigned a new value later
> before used.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied with Matthias Review tag.
Yours,
Linus Walleij
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH] nvme-multipath: do not reset on unknown status
From: Keith Busch @ 2020-02-20 14:52 UTC (permalink / raw)
To: linux-nvme, hch, sagi; +Cc: Keith Busch, hare, John Meneghini
From: John Meneghini <johnm@netapp.com>
The nvme multipath error handling defaults to controller reset if the
error is unknown. There are, however, no existing nvme status codes that
indicate a reset should be used, and resetting causes unnecessary
disruption to the rest of IO.
Change nvme's error handling to first check if failover should happen.
If not, let the normal error handling take over rather than reset the
controller.
Signed-off-by: John Meneghini <johnm@netapp.com>
[changelog]
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
drivers/nvme/host/core.c | 4 +---
drivers/nvme/host/multipath.c | 21 +++++++++------------
drivers/nvme/host/nvme.h | 5 +++--
3 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 84914223c537..0eef1ef8c659 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -292,10 +292,8 @@ void nvme_complete_rq(struct request *req)
if (unlikely(status != BLK_STS_OK && nvme_req_needs_retry(req))) {
if ((req->cmd_flags & REQ_NVME_MPATH) &&
- blk_path_error(status)) {
- nvme_failover_req(req);
+ nvme_failover_req(req))
return;
- }
if (!blk_queue_dying(req->q)) {
nvme_retry_req(req);
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 797c18337d96..16df0baaeb40 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -64,17 +64,12 @@ void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
}
}
-void nvme_failover_req(struct request *req)
+bool nvme_failover_req(struct request *req)
{
struct nvme_ns *ns = req->q->queuedata;
u16 status = nvme_req(req)->status;
unsigned long flags;
- spin_lock_irqsave(&ns->head->requeue_lock, flags);
- blk_steal_bios(&ns->head->requeue_list, req);
- spin_unlock_irqrestore(&ns->head->requeue_lock, flags);
- blk_mq_end_request(req, 0);
-
switch (status & 0x7ff) {
case NVME_SC_ANA_TRANSITION:
case NVME_SC_ANA_INACCESSIBLE:
@@ -103,15 +98,17 @@ void nvme_failover_req(struct request *req)
nvme_mpath_clear_current_path(ns);
break;
default:
- /*
- * Reset the controller for any non-ANA error as we don't know
- * what caused the error.
- */
- nvme_reset_ctrl(ns->ctrl);
- break;
+ /* This was a non-ANA error so follow the normal error path. */
+ return false;
}
+ spin_lock_irqsave(&ns->head->requeue_lock, flags);
+ blk_steal_bios(&ns->head->requeue_list, req);
+ spin_unlock_irqrestore(&ns->head->requeue_lock, flags);
+ blk_mq_end_request(req, 0);
+
kblockd_schedule_work(&ns->head->requeue_work);
+ return true;
}
void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 1024fec7914c..d800b9a51c2c 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -550,7 +550,7 @@ void nvme_mpath_wait_freeze(struct nvme_subsystem *subsys);
void nvme_mpath_start_freeze(struct nvme_subsystem *subsys);
void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
struct nvme_ctrl *ctrl, int *flags);
-void nvme_failover_req(struct request *req);
+bool nvme_failover_req(struct request *req);
void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl);
int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl,struct nvme_ns_head *head);
void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id);
@@ -599,8 +599,9 @@ static inline void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
sprintf(disk_name, "nvme%dn%d", ctrl->instance, ns->head->instance);
}
-static inline void nvme_failover_req(struct request *req)
+static inline bool nvme_failover_req(struct request *req)
{
+ return false;
}
static inline void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl)
{
--
2.21.0
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related
* [PATCH v2] pinctrl: ingenic: Improve unreachable code generation
From: Josh Poimboeuf @ 2020-02-20 15:35 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, linux-gpio, linux-kernel, Peter Zijlstra,
Randy Dunlap
In the second loop of ingenic_pinconf_set(), it annotates the switch
default case as unreachable(). The annotation is technically correct,
because that same case would have resulted in an early function return
in the previous loop.
However, the compiled code is suboptimal. GCC seems to work extra hard
to ensure that the unreachable code path triggers undefined behavior.
The function would fall through to start executing whatever function
happens to be next in the compilation unit.
This is problematic because:
a) it adds unnecessary 'ensure undefined behavior' logic, and
corresponding i-cache footprint; and
b) it's less robust -- if a bug were to be introduced, falling through
to the next function would be catastrophic.
Yet another issue is that, while objtool normally understands
unreachable() annotations, there's one special case where it doesn't:
when the annotation occurs immediately after a 'ret' instruction. That
happens to be the case here because unreachable() is immediately before
the return.
Remove the unreachable() annotation and replace it with a comment. This
simplifies the code generation and changes the unreachable error path to
just silently return instead of corrupting execution.
This fixes the following objtool warning:
drivers/pinctrl/pinctrl-ingenic.o: warning: objtool: ingenic_pinconf_set() falls through to next function ingenic_pinconf_group_set()
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
drivers/pinctrl/pinctrl-ingenic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index 96f04d121ebd..13c7d3351ed5 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -2158,7 +2158,8 @@ static int ingenic_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
break;
default:
- unreachable();
+ /* unreachable */
+ break;
}
}
--
2.21.1
^ permalink raw reply related
* Re: [PATCH] pinctrl: mediatek: Fix some off by one bugs
From: Linus Walleij @ 2020-02-20 15:14 UTC (permalink / raw)
To: Dan Carpenter, Matthias Brugger
Cc: open list:GPIO SUBSYSTEM, kernel-janitors, Sean Wang,
moderated list:ARM/Mediatek SoC support, Light Hsieh
In-Reply-To: <20200218055247.74s2xa7veqx2do34@kili.mountain>
On Tue, Feb 18, 2020 at 6:55 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> These comparisons should be >= instead of > to prevent accessing one
> element beyond the end of the hw->soc->pins[] array.
>
> Fixes: 3de7deefce69 ("pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Matthias could you have a look at this patch?
Yours,
Linus Walleij
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: NVMe/IB support
From: Max Gurtovoy @ 2020-02-20 15:16 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Talker Alex, linux-nvme
In-Reply-To: <20200220142517.GA20993@infradead.org>
On 2/20/2020 4:25 PM, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 04:13:07PM +0200, Max Gurtovoy wrote:
>> On 2/19/2020 5:20 PM, Christoph Hellwig wrote:
>>> On Fri, Feb 07, 2020 at 03:43:22PM +0300, Talker Alex wrote:
>>>> Hi,
>>>>
>>>> is there really exist NVMe/IB solutions?
>>> All the original NVMeoF development was done on IB, just using the
>>> RDMA/CM IP based addressing.
>> I guess we can consider adding this code one day, for users that can't use
>> RDMA/CM (SRP supports both options).
> The NVMeOF RDMA transport requires RDMA/CM. But RDMA/CM can also use
> IB addressing, which should be easy enough to implement if someone
> cares.
Are you saying that if one would like to use ADRFAM == AF_IB, he must
have RDMA/CM stack that support IB addressing ?
seems little bit weird requirement...
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH] MIPS: cavium_octeon: Fix syncw generation.
From: Dmitry Golovin @ 2020-02-20 15:28 UTC (permalink / raw)
To: Nick Desaulniers, Chris Packham
Cc: Mark Tomlinson, f4bug@amsat.org, linux-kernel@vger.kernel.org,
clang-built-linux@googlegroups.com, paulburton@kernel.org,
linux-mips@vger.kernel.org
In-Reply-To: <CAKwvOdkaLRE0Ek3PnmqE2P3Urn4+pwfAp-qQdsLurwERcqNXfQ@mail.gmail.com>
18.02.2020, 20:37, "'Nick Desaulniers' via Clang Built Linux" <clang-built-linux@googlegroups.com>:
>> There is an effort underway to build the kernel with clang[1]. I'm not
>> sure what that ends up using for an assembler or if it'll even be able
>> to target mips64 anytime soon.
I have a working build for MIPS64 (only mips64r6 at the moment), the
config is based on malta_defconfig and it boots in qemu. I still don't
have a matching buildroot image, but it shouldn't be a problem.
Regards,
Dima
^ permalink raw reply
* Re: [PATCH] usb: gadget: net2280: Distribute switch variables for initialization
From: Alan Stern @ 2020-02-20 15:34 UTC (permalink / raw)
To: Kees Cook
Cc: Greg Kroah-Hartman, Felipe Balbi, Alexander Potapenko, linux-usb,
linux-kernel
In-Reply-To: <20200220062315.69253-1-keescook@chromium.org>
On Wed, 19 Feb 2020, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, this triggers a warning (and they
> don't get initialized). Clang's automatic stack variable initialization
> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> doesn't initialize such variables[1]. Note that these warnings (or silent
> skipping) happen before the dead-store elimination optimization phase,
> so even when the automatic initializations are later elided in favor of
> direct initializations, the warnings remain.
>
> To avoid these problems, move such variables into the "case" where
> they're used or lift them up into the main function body.
>
> drivers/usb/gadget/udc/net2280.c: In function ‘handle_stat0_irqs_superspeed’:
> drivers/usb/gadget/udc/net2280.c:2871:22: warning: statement will never be executed [-Wswitch-unreachable]
> 2871 | struct net2280_ep *e;
> | ^
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/usb/gadget/udc/net2280.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
> index 1fd1b9186e46..cc5869363298 100644
> --- a/drivers/usb/gadget/udc/net2280.c
> +++ b/drivers/usb/gadget/udc/net2280.c
> @@ -2861,6 +2861,7 @@ static void ep_clear_seqnum(struct net2280_ep *ep)
> static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> struct net2280_ep *ep, struct usb_ctrlrequest r)
> {
> + struct net2280_ep *e;
> int tmp = 0;
>
> #define w_value le16_to_cpu(r.wValue)
> @@ -2868,14 +2869,13 @@ static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> #define w_length le16_to_cpu(r.wLength)
>
> switch (r.bRequest) {
> - struct net2280_ep *e;
> - u16 status;
> -
> case USB_REQ_SET_CONFIGURATION:
> dev->addressed_state = !w_value;
> goto usb3_delegate;
>
> - case USB_REQ_GET_STATUS:
> + case USB_REQ_GET_STATUS: {
> + u16 status;
> +
> switch (r.bRequestType) {
> case (USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE):
> status = dev->wakeup_enable ? 0x02 : 0x00;
> @@ -2905,7 +2905,7 @@ static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> goto usb3_delegate;
> }
> break;
> -
> + }
This is an unusual use of nested blocks (i.e., a block immediately
following a "case" label, and it throws the indentation off -- there
will now be two nested closing braces at the same indentation level:
this one and the one preceding do_stall3:.
Just define status at the function level, along with e, and don't
worry about it.
Alan Stern
> case USB_REQ_CLEAR_FEATURE:
> switch (r.bRequestType) {
> case (USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE):
>
>
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 15:34 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200220142759.GA13686@intel.com>
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some stats for the whole series:
> > >
> > > 64bit sizeof(struct drm_display_mode):
> > > 200 -> 136 bytes (-32%)
> > >
> > > 64bit bloat-o-meter -c drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > > Function old new delta
> > > ...
> > > Total: Before=189430, After=188779, chg -0.34%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=11667, After=11667, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 1000 680 -320
> > > edid_est_modes 3400 2312 -1088
> > > edid_cea_modes_193 5400 3672 -1728
> > > drm_dmt_modes 17600 11968 -5632
> > > edid_cea_modes_1 25400 17272 -8128
> > > Total: Before=71239, After=54343, chg -23.72%
> > >
> > >
> > > 64bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > > ...
> > > Total: Before=272336, After=254789, chg -6.44%
> > >
> > >
> > > 32bit sizeof(struct drm_display_mode):
> > > 184 -> 120 bytes (-34%)
> > >
> > > 32bit bloat-o-meter -c drm.ko
> > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > > Function old new delta
> > > ...
> > > Total: Before=172359, After=171734, chg -0.36%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=4227, After=4227, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 920 600 -320
> > > edid_est_modes 3128 2040 -1088
> > > edid_cea_modes_193 4968 3240 -1728
> > > drm_dmt_modes 16192 10560 -5632
> > > edid_cea_modes_1 23368 15240 -8128
> > > Total: Before=59230, After=42334, chg -28.53%
> > >
> > > 32bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > > ...
> > > Total: Before=235816, After=218295, chg -7.43%
> > >
> > >
> > > Some ideas for further reduction:
> > > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > > struct but would often require a heap alloc for the name (though
> > > typical mode name is <10 bytes so still overall win perhaps)
> > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > > place where we have to preserve the user provided name, elsewhere
> > > could pehaps just generate on demand? Not sure how tricky this
> > > would get.
> >
> > The series does some great work, with future work reaching the cache
> > line for 64bit.
> > Doing much more than that might be an overkill IMHO.
> >
> > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> > avoiding the heap alloc/calc on demand fun.
> > While also ensuring the name is sufficiently large for the next decade or so.
>
> Unfortunately it's part of the uabi. So can't change it without some
> risk of userspace breakage.
>
> The least demanding option is probably to nuke export_head. We need
> one bit to replace it, which we can get by either:
> - stealing from eg. mode->type, or perhaps mode->private_flags
> - nuke private_flags outright and replace it with a bool for this
> purpose
Looks like getting rid of private_flags is going to be pretty
straightforward. I'll post patches for that once this first series
lands.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 15:34 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200220142759.GA13686@intel.com>
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some stats for the whole series:
> > >
> > > 64bit sizeof(struct drm_display_mode):
> > > 200 -> 136 bytes (-32%)
> > >
> > > 64bit bloat-o-meter -c drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > > Function old new delta
> > > ...
> > > Total: Before=189430, After=188779, chg -0.34%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=11667, After=11667, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 1000 680 -320
> > > edid_est_modes 3400 2312 -1088
> > > edid_cea_modes_193 5400 3672 -1728
> > > drm_dmt_modes 17600 11968 -5632
> > > edid_cea_modes_1 25400 17272 -8128
> > > Total: Before=71239, After=54343, chg -23.72%
> > >
> > >
> > > 64bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > > ...
> > > Total: Before=272336, After=254789, chg -6.44%
> > >
> > >
> > > 32bit sizeof(struct drm_display_mode):
> > > 184 -> 120 bytes (-34%)
> > >
> > > 32bit bloat-o-meter -c drm.ko
> > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > > Function old new delta
> > > ...
> > > Total: Before=172359, After=171734, chg -0.36%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=4227, After=4227, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 920 600 -320
> > > edid_est_modes 3128 2040 -1088
> > > edid_cea_modes_193 4968 3240 -1728
> > > drm_dmt_modes 16192 10560 -5632
> > > edid_cea_modes_1 23368 15240 -8128
> > > Total: Before=59230, After=42334, chg -28.53%
> > >
> > > 32bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > > ...
> > > Total: Before=235816, After=218295, chg -7.43%
> > >
> > >
> > > Some ideas for further reduction:
> > > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > > struct but would often require a heap alloc for the name (though
> > > typical mode name is <10 bytes so still overall win perhaps)
> > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > > place where we have to preserve the user provided name, elsewhere
> > > could pehaps just generate on demand? Not sure how tricky this
> > > would get.
> >
> > The series does some great work, with future work reaching the cache
> > line for 64bit.
> > Doing much more than that might be an overkill IMHO.
> >
> > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> > avoiding the heap alloc/calc on demand fun.
> > While also ensuring the name is sufficiently large for the next decade or so.
>
> Unfortunately it's part of the uabi. So can't change it without some
> risk of userspace breakage.
>
> The least demanding option is probably to nuke export_head. We need
> one bit to replace it, which we can get by either:
> - stealing from eg. mode->type, or perhaps mode->private_flags
> - nuke private_flags outright and replace it with a bool for this
> purpose
Looks like getting rid of private_flags is going to be pretty
straightforward. I'll post patches for that once this first series
lands.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Art Nikpal, Christian Hewitt
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Art Nikpal, Christian Hewitt
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] btrfs: add test case for newly supported cases of cloning inline extents
From: Josef Bacik @ 2020-02-20 15:34 UTC (permalink / raw)
To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana
In-Reply-To: <20200219140641.1642570-1-fdmanana@kernel.org>
On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> Test several scenarios of cloning operations where the source range includes
> inline extents. They used to not be supported on btrfs because their
> implementation was not straightforward, and therefore these operations used
> to fail with errno EOPNOTSUPP on older kernels.
>
> This currently fails on any released kernel. It passes only when the patch
> with the following subject is applied:
>
> "Btrfs: implement full reflink support for inline extents"
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: mvneta: comphy regression with SolidRun ClearFog
From: Joel Johnson @ 2020-02-20 15:34 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: David S. Miller, Baruch Siach, Gregory Clement, Thomas Petazzoni,
Rob Herring, netdev
In-Reply-To: <20200220101232.GU25745@shell.armlinux.org.uk>
On 2020-02-20 03:12, Russell King - ARM Linux admin wrote:
> On Wed, Feb 19, 2020 at 06:49:51AM -0700, Joel Johnson wrote:
>> On 2020-02-19 02:22, Russell King - ARM Linux admin wrote:
>> > On Tue, Feb 18, 2020 at 10:14:48PM -0700, Joel Johnson wrote:
>> > Does debian have support for the comphy enabled in their kernel,
>> > which is controlled by CONFIG_PHY_MVEBU_A38X_COMPHY ?
>>
>> Well, doh! I stared at the patch series for way to long, but the added
>> Kconfig symbol failed to register mentally somehow. I had been using
>> the
>> last known good Debian config with make olddefconfig, but it obviously
>> wasn't included in earlier configs and not enabled by default.
>>
>> Many thanks to you and Willy Tarreau for pointing out my glaring
>> omission!
>
> Thanks for letting us know that you've fixed it now.
Sure thing, I've submitted a Debian patch, and was pointed to an
existing Debian bug with the same issue and patch, so hopefully that
will get incorporated soon. I'll also keep an eye on OpenWRT when they
move to an affected kernel version to make sure it's included.
One lingering question that wasn't clear to me is the apparent
inconsistency in default enablement for PHYs in
drivers/phy/marvell/Kconfig. Is there a technical reason why
PHY_MVEBU_A3700_COMPHY defaults to 'y' but PHY_MVEBU_A38X_COMPHY (and
PHY_MVEBU_CP110_COMPHY) default to 'n', or is it just an artifact of
being added at different times? Similarly, is there a reason that
PHY_MVEBU_A3700_COMPHY and PHY_MVEBU_A3700_UTMI default to 'y' instead
of 'm' for all ARCH_MVEBU builds? In my testing, building with
PHY_MVEBU_A38X_COMPHY as a module still seemed to autoload the module as
needed on boot, so modules for different platforms seems off-hand more
lightweight that building the driver in for all MVEBU boards which don't
use all drivers.
With the current defaults, it seems like PHY_MVEBU_CP110_COMPHY may be
affected in Debian the same way as PHY_MVEBU_A38X_COMPHY, but I don't
have available Armada 7K/8K hardware yet to confirm.
Joel
^ permalink raw reply
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt, Art Nikpal
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: Sean Paul, linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: NVMe/IB support
From: Christoph Hellwig @ 2020-02-20 15:33 UTC (permalink / raw)
To: Max Gurtovoy; +Cc: Christoph Hellwig, Talker Alex, linux-nvme
In-Reply-To: <cd2f6306-1c4e-848c-9075-f89ce5f3a9ac@mellanox.com>
On Thu, Feb 20, 2020 at 05:16:35PM +0200, Max Gurtovoy wrote:
> Are you saying that if one would like to use ADRFAM == AF_IB, he must have
> RDMA/CM stack that support IB addressing ?
Yes.
> seems little bit weird requirement...
NVMeoF/RDMA is specified to use RDMA/CM for connection management.
There is no reason we could not also specify it on raw IB, but someone
would have to do the work and specify a binding for it.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: ML dri-devel, linux-arm-msm, Intel Graphics Development,
freedreno, Sean Paul
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
^ permalink raw reply
* [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Martin Peres @ 2020-02-20 15:32 UTC (permalink / raw)
To: igt-dev
When arriving at the office on Monday morning, the reported queue
size was ~100 hours. This defeats the point of pre-merge testing and
vastly exceeds our target of ~6 hours.
We have a lot of work needed to reduce testing time, but this patches
reduces the reported run time by 15-30% depending on the platforms:
- shard-skl: 23.9 -> 18.2 minutes (18.5%)
- shard-kbl: 21.2 -> 16.2 minutes (20%)
- shard-apl: 25.9 -> 18.5 minutes (24.3%)
- shard-glk: 24.7 -> 17.6 minutes (24.8%)
- shard-icl: 25.1 -> 16.7 minutes (28.7%)
- shard-tgl: 28.2 -> 19.6 minutes (26.4%)
The reason why the reported runtime is so low compared to the
actual time is due to:
- Unaccounted time spent outside of the IGT subtests (exec(), fixtures)
- Unaccounted time spent in suspend (monotonic clock, 20s / suspend)
- Boot time / extra reboots between shards to workaround kernel failures
- Intel GFX CI shard scheduling overhead
- More?
Tomi and Petri are working on reducing these overheads by detecting the
bad conditions and rebooting the machine only at this point rather than
between every single shard, and increasing the size of the shard test
lists to reduce the per-shard CI overhead.
Because of this, the actual savings are way smaller in percentage
but still compound over the tens of executions we do per week:
- shard-skl: ~58 -> ~52 minutes
- shard-kbl: ~50 -> ~45 minutes
- shard-apl: ~53 -> ~46 minutes
- shard-glk: ~38 -> ~31 minutes
- shard-icl: ~47 -> ~39 minutes
- shard-tgl: ~60 -> ~51 minutes
More work needed, but we'll get there :)
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
---
tests/intel-ci/README | 7 +
tests/intel-ci/blacklist-pre-merge.txt | 221 +++++++++++++++++++++++++
2 files changed, 228 insertions(+)
create mode 100644 tests/intel-ci/blacklist-pre-merge.txt
diff --git a/tests/intel-ci/README b/tests/intel-ci/README
index e3289933..07b32b54 100644
--- a/tests/intel-ci/README
+++ b/tests/intel-ci/README
@@ -37,6 +37,13 @@ blacklist.txt
This file contains regular expressions (one per line) for tests that
are not to be executed in full suite test rounds.
+=======================
+blacklist-pre-merge.txt
+=======================
+
+This file contains regular expressions (one per line) for tests that
+are not to be executed in pre-merge full suite test rounds.
+
=============
meta.testlist
=============
diff --git a/tests/intel-ci/blacklist-pre-merge.txt b/tests/intel-ci/blacklist-pre-merge.txt
new file mode 100644
index 00000000..45fded33
--- /dev/null
+++ b/tests/intel-ci/blacklist-pre-merge.txt
@@ -0,0 +1,221 @@
+###############################################################################
+# This test has caught regressions in the past, but the feature is rarely used
+# by our users, yet it is responsible a significant portion of our execution
+# time:
+#
+# - shard-skl: 10.2% (~22 minutes)
+# - shard-kbl: 6% (~8 minutes)
+# - shard-apl: 3.9% (~7 minutes)
+# - shard-glk: 8% (~18 minutes)
+# - shard-icl: 11% (~22 minutes)
+# - shard-tgl: 7.1% (~14 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@kms_rotation_crc@.*
+
+
+###############################################################################
+# These 4 tests catching a lot of unrelated issues and are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 1.6% (~4 minutes)
+# - shard-kbl: 0.4% (30 seconds)
+# - shard-apl: 0.2% (20 seconds)
+# - shard-glk: 0.2% (30 seconds)
+# - shard-icl: 6% (~12 minutes)
+# - shard-tgl: 6% (~12 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@(legacy|universal)-planes(-dpms)?
+
+
+###############################################################################
+# These 8 tests are responsible for a significant portion of our execution time
+# despite them testing a feature which is only found in older userspaces:
+#
+# - shard-skl: 0.1% (~15 seconds)
+# - shard-kbl: 3.5% (~4.5 minutes)
+# - shard-apl: 10% (~18 minutes)
+# - shard-glk: 6.3% (~14 minutes)
+# - shard-icl: 1.7% (~3.5 minutes)
+# - shard-tgl: 1.6% (~3 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@gem_pwrite@big-.*
+
+
+###############################################################################
+# These 4 tests are covering an edge case which should never be hit by users
+# unless we already are in a bad situation, yet they are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 2% (~5 minutes)
+# - shard-kbl: 4% (~5 minutes)
+# - shard-apl: 2.7% (~5 minutes)
+# - shard-glk: 4.5% (~10 minutes)
+# - shard-icl: 2.5% (~5 minutes)
+# - shard-tgl: 3.5% (~7 minutes)
+#
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_flip@flip-vs-(modeset|panning)-vs-hang(-interruptible)?
+
+
+###############################################################################
+# These 28 tests are covering an edge case which should never be hit by users
+# unless we already are in a bad situation, yet they are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 1.7% (~4 minutes)
+# - shard-kbl: 2.8% (~3.5 minutes)
+# - shard-apl: 2.2% (~4 minutes)
+# - shard-glk: 1.8% (~4 minutes)
+# - shard-icl: 1.9% (~4 minutes)
+# - shard-tgl: 2.8% (~5.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_busy@.*hang.*
+
+
+###############################################################################
+# This test is reading one file at a time while being suspended, which makes
+# testing extremelly slow. This is somewhat of an edge case that is unlikely
+# to be hit, hence why it could be dropped from pre-merge testing. Here are the
+# execution time statistics:
+#
+# - shard-skl: 0.5% (~1 minute)
+# - shard-kbl: 0.1% (~2 seconds)
+# - shard-apl: 0.1% (~2 seconds)
+# - shard-glk: 0.1% (~2 seconds)
+# - shard-icl: 0.6% (~1.5 minutes)
+# - shard-tgl: 0.7% (~1.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@debugfs-read
+
+
+###############################################################################
+# Perf tests are for people using performance counters to get details about
+# how the execution is performed (Observability Architecture). As such, the
+# audience is very limited (game developers, driver developers), and it does
+# not justify the overall execution time:
+#
+# - shard-skl: 0%
+# - shard-kbl: 0%
+# - shard-apl: 0%
+# - shard-glk: 0%
+# - shard-icl: 0%
+# - shard-tgl: 1.7% (~3.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@perf@gen12-mi-rpc
+
+
+###############################################################################
+# Modern userspace does not depend on the GTT anymore, so let's drop the
+# slowest tests from pre-merge testing:
+#
+# - shard-skl: 2.7% (~6.5 minutes)
+# - shard-kbl: 2% (~2.5 minutes)
+# - shard-apl: 4.7% (~8.5 minutes)
+# - shard-glk: 3.5% (~8 minutes)
+# - shard-icl: 4.2% (~8.5 minutes)
+# - shard-tgl: 2.5% (~4.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_fence_thrash@bo-write-verify-threaded-[xy]
+igt@gem_tiled_(wc|(|blits|fence_blits)@(normal|interruptible))
+
+
+###############################################################################
+# This tests modesetting-vs-wedged which is a useful thing to check, but it
+# seems like it mostly catches unrelated issues which are better caught by
+# other tests.
+#
+# - shard-skl: 0.5% (~1 minute)
+# - shard-kbl: 1% (~1 minute)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.5% (~1 minute)
+# - shard-icl: 0.6% (~1.5 minutes)
+# - shard-tgl: 0.7% (~1.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_eio@kms
+
+
+###############################################################################
+# This is a useful test, but it mostly tests the HW rather than the driver.
+# Very few regressions should be caught by this test as the driver code should
+# be relatively left untouched. Hopefully, it will get optimized to be made
+# useful in pre-merge as well:
+#
+# - shard-skl: 1% (~2.5 minutes)
+# - shard-kbl: 1.5% (~2 minutes)
+# - shard-apl: 1.4% (~2.5 minutes)
+# - shard-glk: 2% (~4.5 minutes)
+# - shard-icl: 2.7% (~5.5 minutes)
+# - shard-tgl: 2.3% (~4.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_plane@pixel-format-pipe-[a-d]-planes(-source-clamping)?
+
+
+###############################################################################
+# This test is doing nothing more than waiting for the driver to be suspended
+# before issueing a modeset. However, it never failed while testing for this
+# in the past year, so we probably just want to drop the amount of rounds to
+# reduce the runtime, but let's just blacklist it in pre-merge for now:
+#
+# - shard-skl: 1% (~2.5 minute)
+# - shard-kbl: 0.9% (~1 minute)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.5% (~1 minute)
+# - shard-icl: 1.1% (~2.5 minutes)
+# - shard-tgl: 1.4% (~2.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@modeset-stress-extra-wait
+
+
+###############################################################################
+# This test virtually never failed, yet is responsible for a relatively big
+# execution time on some platforms:
+#
+# - shard-skl: 1.3% (~3 minutes)
+# - shard-kbl: 0.3% (~0.3 minutes)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.4% (50 seconds)
+# - shard-icl: 0.1% (15 seconds)
+# - shard-tgl: 0.1% (15 seconds)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@sw_sync@sync_expired_merge
+
+
+###############################################################################
+# These 2 tests are stressing the re-usability of objects. It does not look
+# like we have had issues with this outside of the gen7 ppgtt issue, which
+# does not counterbalance its overall execution time.
+#
+# - shard-skl: 2% (~5 minutes)
+# - shard-kbl: 1% (~1.5 minutes)
+# - shard-apl: 1.7% (~3 minutes)
+# - shard-glk: 1% (2.5 minutes)
+# - shard-icl: 0.5% (1 minute)
+# - shard-tgl: 0.5% (1 minute)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_exec_reuse@(baggage|contexts)
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.