* [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Andrey Smirnov @ 2018-07-23 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42ff53eeea3067b19e3e16bed8392706502c8f23.camel@nxp.com>
On Mon, Jul 23, 2018 at 5:41 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> > On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> > >
> > > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> > >
> > > That commit followed the reference manual but unfortunately the imx7d
> > > manual is incorrect.
> >
> > I'd also add similar comment to DT file to prevent people from trying
> > to "fix" this in the future.
>
> I'll try to see if I can follow up internally with docs team to get
> this updated in the next revision of the reference manual.
>
Not sure if we are on the same page here, but what I meant is adding
the same explanation that is in your commit message to Device Tree
file as well so that if anyone looks at DT code and goes "Huh?" in the
future, they wouldn't have to research commit history to see the
reason why things the way they are.
> > Also, this change is going to break QEMU's mapping found here:
>
> I had no idea that existed, I guess somebody needs to fix that as well.
>
I take it it's a no to my "any chance you can fix that as well?" ;-).
I'll see if I can find time to do that this week.
> Do you have an imx7d board using pci or did you just test in emulation?
>
I used real i.MX7D Sabre board with i210 network card, when I was
porting i.MX7 PCIe patches. However, as per note I made in the
original submission:
https://lkml.org/lkml/2017/10/9/913
this IRQ swap patch came up as a result of "connecting" emulated ICH4
in QEMU which was using legacy interrupts.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Andrey Smirnov @ 2018-07-23 18:38 UTC (permalink / raw)
To: Leonard Crestez
Cc: Richard Zhu, linux-kernel, Dong Aisheng, Jingoo Han, linux-imx,
lorenzo.pieralisi, linux-pm, Fabio Estevam, Joao.Pinto, Shawn Guo,
linux-arm-kernel, Bjorn Helgaas, Lucas Stach, Sascha Hauer,
linux-pci
In-Reply-To: <42ff53eeea3067b19e3e16bed8392706502c8f23.camel@nxp.com>
On Mon, Jul 23, 2018 at 5:41 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> > On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> > >
> > > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> > >
> > > That commit followed the reference manual but unfortunately the imx7d
> > > manual is incorrect.
> >
> > I'd also add similar comment to DT file to prevent people from trying
> > to "fix" this in the future.
>
> I'll try to see if I can follow up internally with docs team to get
> this updated in the next revision of the reference manual.
>
Not sure if we are on the same page here, but what I meant is adding
the same explanation that is in your commit message to Device Tree
file as well so that if anyone looks at DT code and goes "Huh?" in the
future, they wouldn't have to research commit history to see the
reason why things the way they are.
> > Also, this change is going to break QEMU's mapping found here:
>
> I had no idea that existed, I guess somebody needs to fix that as well.
>
I take it it's a no to my "any chance you can fix that as well?" ;-).
I'll see if I can find time to do that this week.
> Do you have an imx7d board using pci or did you just test in emulation?
>
I used real i.MX7D Sabre board with i210 network card, when I was
porting i.MX7 PCIe patches. However, as per note I made in the
original submission:
https://lkml.org/lkml/2017/10/9/913
this IRQ swap patch came up as a result of "connecting" emulated ICH4
in QEMU which was using legacy interrupts.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Andrey Smirnov @ 2018-07-23 18:38 UTC (permalink / raw)
To: Leonard Crestez
Cc: Dong Aisheng, lorenzo.pieralisi, Richard Zhu, linux-pm,
Jingoo Han, linux-kernel, Bjorn Helgaas, Joao.Pinto, linux-imx,
Sascha Hauer, linux-pci, Fabio Estevam, Shawn Guo,
linux-arm-kernel, Lucas Stach
In-Reply-To: <42ff53eeea3067b19e3e16bed8392706502c8f23.camel@nxp.com>
On Mon, Jul 23, 2018 at 5:41 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> > On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> > >
> > > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> > >
> > > That commit followed the reference manual but unfortunately the imx7d
> > > manual is incorrect.
> >
> > I'd also add similar comment to DT file to prevent people from trying
> > to "fix" this in the future.
>
> I'll try to see if I can follow up internally with docs team to get
> this updated in the next revision of the reference manual.
>
Not sure if we are on the same page here, but what I meant is adding
the same explanation that is in your commit message to Device Tree
file as well so that if anyone looks at DT code and goes "Huh?" in the
future, they wouldn't have to research commit history to see the
reason why things the way they are.
> > Also, this change is going to break QEMU's mapping found here:
>
> I had no idea that existed, I guess somebody needs to fix that as well.
>
I take it it's a no to my "any chance you can fix that as well?" ;-).
I'll see if I can find time to do that this week.
> Do you have an imx7d board using pci or did you just test in emulation?
>
I used real i.MX7D Sabre board with i210 network card, when I was
porting i.MX7 PCIe patches. However, as per note I made in the
original submission:
https://lkml.org/lkml/2017/10/9/913
this IRQ swap patch came up as a result of "connecting" emulated ICH4
in QEMU which was using legacy interrupts.
Thanks,
Andrey Smirnov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 18:37 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20180723181318.GG13981@sirena.org.uk>
On 07/23/2018 02:13 PM, Mark Brown wrote:
> On Mon, Jul 23, 2018 at 01:58:26PM -0400, Peter Geis wrote:
>> SW2 and SW4 use a shared table to provide voltage to the cpu core and
>> devices on Tegra hardware.
>> Added this table to the cpcap regulator driver as the first step to
>> supporting this device on Tegra.
>
> This also doesn't apply against current code (though it does now parse
> OK), please check and resend - make sure you don't have other out of
> tree changes and are using an up to date kernel (ideally my regulator
> for-next branch) as a base.
>
Good Afternoon,
I thought it was my error in the patches being stripped, unfortunately
it seems to be a known Gmail behavior.
Any ideas on how to get around it?
Thanks,
Peter
^ permalink raw reply
* [PATCH, libv4l]: Make libv4l2 usable on devices with complex pipeline
From: Mauro Carvalho Chehab @ 2018-07-23 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180719205344.GA12098@amd>
Hi Pavel,
Em Thu, 19 Jul 2018 22:53:44 +0200
Pavel Machek <pavel@ucw.cz> escreveu:
> On Sun 2018-07-08 23:32:58, Pavel Machek wrote:
> >
> > Add support for opening multiple devices in v4l2_open(), and for
> > mapping controls between devices.
> >
> > This is necessary for complex devices, such as Nokia N900.
> >
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> Ping?
>
> There's a lot of work to do on libv4l2... timely patch handling would
> be nice.
As we're be start working at the new library in order to support
complex cameras, and I don't want to prevent you keeping doing your
work, IMHO the best way to keep doing it would be to create two
libv4l2 forks:
- one to be used by you - meant to support N900 camera;
- another one to be used by Google/Intel people that will
be working at the Complex camera.
This way, we can proceed with the development without causing
instability to v4l-utils. Once we have the projects done at the
separate repositories, we can work on merging them back upstream.
So, please send me, in priv, a .ssh key for me to add you an
account at linuxtv.org. I'll send you instructions about how to
use the new account.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH, libv4l]: Make libv4l2 usable on devices with complex pipeline
From: Mauro Carvalho Chehab @ 2018-07-23 18:36 UTC (permalink / raw)
To: Pavel Machek
Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, tony,
khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge,
abcloriens, clayton, martijn, sakari.ailus, Filip Matijević,
mchehab, sakari.ailus, linux-media, hans.verkuil
In-Reply-To: <20180719205344.GA12098@amd>
Hi Pavel,
Em Thu, 19 Jul 2018 22:53:44 +0200
Pavel Machek <pavel@ucw.cz> escreveu:
> On Sun 2018-07-08 23:32:58, Pavel Machek wrote:
> >
> > Add support for opening multiple devices in v4l2_open(), and for
> > mapping controls between devices.
> >
> > This is necessary for complex devices, such as Nokia N900.
> >
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> Ping?
>
> There's a lot of work to do on libv4l2... timely patch handling would
> be nice.
As we're be start working at the new library in order to support
complex cameras, and I don't want to prevent you keeping doing your
work, IMHO the best way to keep doing it would be to create two
libv4l2 forks:
- one to be used by you - meant to support N900 camera;
- another one to be used by Google/Intel people that will
be working at the Complex camera.
This way, we can proceed with the development without causing
instability to v4l-utils. Once we have the projects done at the
separate repositories, we can work on merging them back upstream.
So, please send me, in priv, a .ssh key for me to add you an
account at linuxtv.org. I'll send you instructions about how to
use the new account.
Thanks,
Mauro
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/8] migration: do not wait for free thread
From: Eric Blake @ 2018-07-23 18:36 UTC (permalink / raw)
To: guangrong.xiao, pbonzini, mst, mtosatti
Cc: qemu-devel, kvm, dgilbert, peterx, wei.w.wang, jiang.biao2,
Xiao Guangrong
In-Reply-To: <20180719121520.30026-2-xiaoguangrong@tencent.com>
On 07/19/2018 07:15 AM, guangrong.xiao@gmail.com wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>
> Instead of putting the main thread to sleep state to wait for
> free compression thread, we can directly post it out as normal
> page that reduces the latency and uses CPUs more efficiently
>
> A parameter, compress-wait-thread, is introduced, it can be
> enabled if the user really wants the old behavior
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---
> hmp.c | 8 ++++++++
> migration/migration.c | 21 +++++++++++++++++++++
> migration/migration.h | 1 +
> migration/ram.c | 45 ++++++++++++++++++++++++++-------------------
> qapi/migration.json | 23 ++++++++++++++++++-----
> 5 files changed, 74 insertions(+), 24 deletions(-)
>
> +++ b/qapi/migration.json
> @@ -462,6 +462,11 @@
> # @compress-threads: Set compression thread count to be used in live migration,
> # the compression thread count is an integer between 1 and 255.
> #
> +# @compress-wait-thread: Wait if no thread is free to compress the memory page
> +# if it's enabled, otherwise, the page will be posted out immediately
> +# in the main thread without compression. It's off on default.
> +# (Since: 3.0)
Is this a bug fix? It's awfully late in the release cycle to be adding
new features; is this something that we can live without until 3.1?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH v2 1/8] migration: do not wait for free thread
From: Eric Blake @ 2018-07-23 18:36 UTC (permalink / raw)
To: guangrong.xiao, pbonzini, mst, mtosatti
Cc: kvm, Xiao Guangrong, qemu-devel, peterx, dgilbert, wei.w.wang,
jiang.biao2
In-Reply-To: <20180719121520.30026-2-xiaoguangrong@tencent.com>
On 07/19/2018 07:15 AM, guangrong.xiao@gmail.com wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>
> Instead of putting the main thread to sleep state to wait for
> free compression thread, we can directly post it out as normal
> page that reduces the latency and uses CPUs more efficiently
>
> A parameter, compress-wait-thread, is introduced, it can be
> enabled if the user really wants the old behavior
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---
> hmp.c | 8 ++++++++
> migration/migration.c | 21 +++++++++++++++++++++
> migration/migration.h | 1 +
> migration/ram.c | 45 ++++++++++++++++++++++++++-------------------
> qapi/migration.json | 23 ++++++++++++++++++-----
> 5 files changed, 74 insertions(+), 24 deletions(-)
>
> +++ b/qapi/migration.json
> @@ -462,6 +462,11 @@
> # @compress-threads: Set compression thread count to be used in live migration,
> # the compression thread count is an integer between 1 and 255.
> #
> +# @compress-wait-thread: Wait if no thread is free to compress the memory page
> +# if it's enabled, otherwise, the page will be posted out immediately
> +# in the main thread without compression. It's off on default.
> +# (Since: 3.0)
Is this a bug fix? It's awfully late in the release cycle to be adding
new features; is this something that we can live without until 3.1?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* compilation on 4.14.52
From: Steve W Heim @ 2018-07-23 17:33 UTC (permalink / raw)
To: linux-rt-users
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
I'm trying to patch ubuntu 16.04 to use the latest stable kernel, 4.14.52
with preempt-rt, and at compilation, when running `CONCURRENCY_LEVEL=8
make-kpkg --rootcmd fakeroot --initrd kernel_image kernel_headers`, I get
the error
./include/linux/interrupt.h:758:2: error: #endif without #if
When diffing this file with the same file for the patched 4.9 preempt-rt
kernel (which I've successfully patched before), the missing parts seem to
be `#if defined(CONFIG_FUNCTION_GRAPH_TRACER) || defined(CONFIG_KASAN)`
but simply adding this (and the other missing lines) results in more
errors. Is this a known issue?
[-- Attachment #2: Type: text/html, Size: 734 bytes --]
^ permalink raw reply
* Re: Hash algorithm analysis
From: Jonathan Nieder @ 2018-07-23 18:35 UTC (permalink / raw)
To: demerphq
Cc: brian m. carlson, Johannes Schindelin, Git, Linus Torvalds, agl,
keccak
In-Reply-To: <CANgJU+X39NoEoMyLu+FX38=x19LrRqatz_dUpUAc+WFV+Uw+=A@mail.gmail.com>
Hi Yves,
demerphq wrote:
> On Sun, 22 Jul 2018 at 01:59, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> I will admit that I don't love making this decision by myself, because
>> right now, whatever I pick, somebody is going to be unhappy.
[...]
> I do not envy you this decision.
>
> Personally I would aim towards pushing this decision out to the git
> user base and facilitating things so we can choose whatever hash
> function (and config) we wish, including ones not invented yet.
There are two separate pieces to this.
One is configurability at compile time. So far that has definitely
been a goal, because we want to be ready to start the transition to
another hash, and quickly, as soon as the new hash is discovered to be
weak. This also means that people can experiment with new hashes and
in a controlled environment (where the users can afford to build from
source), some users might prefer some bespoke hash for reasons only
known to them. ;-)
Another piece is configurability at run time. This is a harder sell
because it has some negative effects in the ecosystem:
- performance impact from users having to maintain a translation table
between the different hash functions in use
- security impact, in the form of downgrade attacks
- dependency bloat, from Git having to be able to compute all hash
functions permitted in that run-time configuration
The security impact can be mitigated by keeping the list of supported
hashes small (i.e. two or three instead of 10ish). Each additional
hash function is a potential liability (just as in SSL), so they have
to earn their keep.
The performance impact is unavoidable if we encourage Git servers to
pick their favorite hash function instead of making a decision in the
project. This can in turn affect security, since it would increase
the switching cost away from SHA-1, with the likely effect being that
most users stay on SHA-1. I don't want to go there.
So I would say, support for arbitrary hash functions at compile time
and in file formats is important and I encourage you to hold us to
that (when reviewing patches, etc). But in the standard Git build
configuration that most people run, I believe it is best to support
only SHA-1 + our chosen replacement hash.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Tonghao Zhang @ 2018-07-23 17:31 UTC (permalink / raw)
To: toshiaki.makita1
Cc: makita.toshiaki, jasowang, mst, virtualization,
Linux Kernel Network Developers
In-Reply-To: <2b0efbf4-09e2-0ee9-091f-e2d9e10483a1@gmail.com>
On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
<toshiaki.makita1@gmail.com> wrote:
>
> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
> > On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
> > <makita.toshiaki@lab.ntt.co.jp> wrote:
> >>
> >> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
> >>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>
> >>> Factor out generic busy polling logic and will be
> >>> used for in tx path in the next patch. And with the patch,
> >>> qemu can set differently the busyloop_timeout for rx queue.
> >>>
> >>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>> ---
> >> ...
> >>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
> >>> + struct vhost_virtqueue *rvq,
> >>> + struct vhost_virtqueue *tvq,
> >>> + bool rx)
> >>> +{
> >>> + struct socket *sock = rvq->private_data;
> >>> +
> >>> + if (rx) {
> >>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
> >>> + vhost_poll_queue(&tvq->poll);
> >>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
> >>> + vhost_disable_notify(&net->dev, tvq);
> >>> + vhost_poll_queue(&tvq->poll);
> >>> + }
> >>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>> + vhost_poll_queue(&rvq->poll);
> >>
> >> Now we wait for vq_avail for rx as well, I think you cannot skip
> >> vhost_enable_notify() on tx. Probably you might want to do:
> > I think vhost_enable_notify is needed.
> >
> >> } else if (sock && sk_has_rx_data(sock->sk)) {
> >> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
> >> vhost_poll_queue(&rvq->poll);
> >> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
> >> vhost_disable_notify(&net->dev, rvq);
> >> vhost_poll_queue(&rvq->poll);
> >> }
> >> }
> > As Jason review as before, we only want rx kick when packet is pending at
> > socket but we're out of available buffers. So we just enable notify,
> > but not poll it ?
> >
> > } else if ((sock && sk_has_rx_data(sock->sk)) &&
> > !vhost_vq_avail_empty(&net->dev, rvq)) {
> > vhost_poll_queue(&rvq->poll);
> > else {
> > vhost_enable_notify(&net->dev, rvq);
> > }
>
> When vhost_enable_notify() returns true the avail becomes non-empty
> while we are enabling notify. We may delay the rx process if we don't
> check the return value of vhost_enable_notify().
I got it thanks.
> >> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
> > I cant find why it is better, if necessary, we can do it.
>
> The reason is pretty simple... we are busypolling the socket so we don't
> need rx wakeups during it?
OK, but one question, how about rx? do we use the
vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
> --
> Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests
From: Stefano Stabellini @ 2018-07-23 18:32 UTC (permalink / raw)
To: Andrii Anisov
Cc: Stefano Stabellini, julien.grall, Stefano Stabellini, xen-devel
In-Reply-To: <94e6cecd-12d7-29bf-51f0-c9e997da6d58@epam.com>
On Mon, 23 Jul 2018, Andrii Anisov wrote:
> Hello Stefano,
>
>
> On 07.07.18 02:11, Stefano Stabellini wrote:
> > Extend allocate_memory to work for non 1:1 mapped domUs. Specifically,
> > memory allocated for domU will be mapped into the domU pseudo-physical
> > address space at the appropriate addresses according to the guest memory
> > map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
> I would speculate about GUEST_RAMx_BASE and GUEST_RAMx_SIZE macros. Those
> values might not fit the real SoC memory map. And it becomes a problem once we
> decided to assign some peripheral directly to the guest because a RAM space
> specified to VM would overlap with IO range of the assigned device.
> In my practice, we always align those macros with the SoC memory map. This
> becomes more convenient and practical than IO remapping.
>
> It might be the moment to get those values configurable for the guests. At
> least for those, which are configured from the device tree. Here naturally fit
> making `memory` property similar to `reg` - the list of <base, size> values.
Yes, you are right. Those value should be made configurable. It is
already on my roadmap. But I would keep it separate from this series: it
is not just about the position of RAM in the guest address space, also
the GIC and timer addresses need to be configurable. I usually refer to
this (future) feature as arbitrary guest memory map.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [Bug 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set
From: bugzilla-daemon @ 2018-07-23 18:32 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106228-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #4 from David Francis <david.francis@amd.com> ---
Created attachment 140795
--> https://bugs.freedesktop.org/attachment.cgi?id=140795&action=edit
Patch that should fix the problem
Could you try out this patch and check if it works? Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1537 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls
From: Paul Moore @ 2018-07-23 18:31 UTC (permalink / raw)
To: sgrubb, rgb
Cc: cgroups, containers, linux-api, linux-audit, linux-fsdevel,
linux-kernel, netdev, ebiederm, luto, carlos, dhowells, viro,
simo, Eric Paris, serge
In-Reply-To: <2739536.aL1iVigTi9@x2>
On Mon, Jul 23, 2018 at 12:48 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Monday, July 23, 2018 11:11:48 AM EDT Richard Guy Briggs wrote:
> > On 2018-07-23 09:19, Steve Grubb wrote:
> > > On Sunday, July 22, 2018 4:55:10 PM EDT Richard Guy Briggs wrote:
> > > > On 2018-07-22 09:32, Steve Grubb wrote:
> > > > > On Saturday, July 21, 2018 4:29:30 PM EDT Richard Guy Briggs wrote:
> > > > > > > > + * audit_log_contid - report container info
> > > > > > > > + * @tsk: task to be recorded
> > > > > > > > + * @context: task or local context for record
> > > > > > > > + * @op: contid string description
> > > > > > > > + */
> > > > > > > > +int audit_log_contid(struct task_struct *tsk,
> > > > > > > > + struct audit_context *context,
> > > > > > > > char
> > > > > > > > *op)
> > > > > > > > +{
> > > > > > > > + struct audit_buffer *ab;
> > > > > > > > +
> > > > > > > > + if (!audit_contid_set(tsk))
> > > > > > > > + return 0;
> > > > > > > > + /* Generate AUDIT_CONTAINER record with container ID */
> > > > > > > > + ab = audit_log_start(context, GFP_KERNEL,
> > > > > > > > AUDIT_CONTAINER);
> > > > > > > > + if (!ab)
> > > > > > > > + return -ENOMEM;
> > > > > > > > + audit_log_format(ab, "op=%s contid=%llu",
> > > > > > > > + op, audit_get_contid(tsk));
> > > > > > >
> > > > > > > Can you explain your reason for including an "op" field in this
> > > > > > > record
> > > > > > > type? I've been looking at the rest of the patches in this
> > > > > > > patchset
> > > > > > > and it seems to be used more as an indicator of the record's
> > > > > > > generating context rather than any sort of audit container ID
> > > > > > > operation.
> > > > > >
> > > > > > "action" might work, but that's netfilter and numeric... "kind"?
> > > > > > Nothing else really seems to fit from a field name, type or lack of
> > > > > > searchability perspective.
> > > > > >
> > > > > > Steve, do you have an opinion?
> > > > >
> > > > > We only have 1 sample event where we have op=task. What are the other
> > > > > possible values?
> > > >
> > > > For the AUDIT_CONTAINER record we have op= "task", "target" (from the
> > > > ptrace and signals patch), "tty".
> > > >
> > > > For the AUDIT_CONTAINER_ID record we have "op=set".
> > >
> > > Since the purpose of this record is to log the container id, I think that
> > > is all that is needed. We can get the context from the other records in
> > > the event. I'd suggest dropping the "op" field.
> >
> > Ok, the information above it for two different audit container
> > identifier records. Which one should drop the "op=" field? Both? Or
> > just the AUDIT_CONTAINER record? The AUDIT_CONTAINER_ID record (which
> > might be renamed) could use it to distinguish a "set" record from a
> > dropped audit container identifier that is no longer registered by any
> > task or namespace.
>
> Neither of them need it. All they need to do is state the container that is
> being acted upon.
I think we should keep the "op" field for audit container ID
management operations, even though we really only have a "set"
operation at the moment, but the others should drop the "op" field
(see my previous emails in this thread).
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Joe Perches @ 2018-07-23 18:30 UTC (permalink / raw)
To: Guenter Roeck
Cc: Dmitry Torokhov, Greg Kroah-Hartman, dev-harsh1998, trivial,
Simon Budig, Andi Shyti, Luca Ceresoli, linux-input, linux-kernel
In-Reply-To: <20180723182412.GA2964@roeck-us.net>
On Mon, 2018-07-23 at 11:24 -0700, Guenter Roeck wrote:
> There are much more urgent issues to fix there (such as, for example,
> converting the "offending" drivers to the latest API, which would
> magically cause most of the offenders to disappear).
Perhaps posting a list of desired hwmon changes could help.
Documentation/hwmon/submitting-patches does not seem to specify
what the "latest API" is nor describe what changes would be
required in older drivers.
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-07-23
From: Kalle Valo @ 2018-07-23 17:27 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this first pull request for 4.19 got delayed as I was on vacation for
two weeks. I was supposed to send this before my vacation but didn't
manage to do it due to other urgent stuff, but I'll try to catch up with
everything this week so that we get everything ready on time for 4.19.
More info in the signed tag below and please let me know if there are
any problems.
Kalle
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2018-07-23
for you to fetch changes up to 4a07ed51cae18765c76d9aede5b9830d42db1546:
mt76x2: debugfs: add sw pulse statistics to dfs debugfs (2018-07-04 18:16=
:01 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.19
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
----------------------------------------------------------------
Andrey Shevchenko (1):
qtnfmac: enable source MAC address randomization support
Arnd Bergmann (2):
zd1211rw: stop using deprecated get_seconds()
ipw2x00: track time using boottime
Ben Greear (1):
ath10k: support use of channel 173
Brian Norris (6):
ath10k: use crash_dump enum instead of magic numbers
ath10k: snoc: use module_platform_driver() macro
ath10k: snoc: use correct bus-specific pointer in RX retry
ath10k: snoc: stop including pci.h
ath10k: snoc: drop unused WCN3990_CE_ATTR_FLAGS
ath10k: snoc: sort include files
Colin Ian King (3):
ath10k: fix memory leak of tpc_stats
ath9k: debug: fix spelling mistake "WATHDOG" -> "WATCHDOG"
brcmsmac: make function wlc_phy_workarounds_nphy_rev1 static
Dan Carpenter (1):
rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()
Daniel Mack (1):
libertas: fix suspend and resume for SDIO connected cards
Eyal Reizer (1):
wlcore: Use generic runtime pm calls for wowlan elp configuration
Felix Fietkau (9):
mt76: fix beacon timer drift
mt76: fix threshold for gain adjustment
mt76: fix swapped values for RXO-18 in gain control
mt76: adjust AGC control register 26 based on gain for VHT80
mt76: clear false CCA counters after changing gain settings
mt76: fix variable gain adjustment range
mt76: add a debugfs file to dump agc calibration information
mt76: track ewma rssi for gain adjustment per station
mt76: improve gain adjustment in noisy environments
Govind Singh (1):
ath10k: handle resource init failure case
Gustavo A. R. Silva (5):
ath10k: htt_tx: mark expected switch fall-throughs
ath5k: mark expected switch fall-through
ath6kl: mark expected switch fall-throughs
ath9k: mark expected switch fall-throughs
wlcore: Fix memory leak in wlcore_cmd_wait_for_event_or_timeout
Guy Chronister (1):
ath6kl: add support for Dell Wireless 1537
Igor Mitsyanko (1):
qtnfmac: implement net_device_ops callback to set MAC address
Johannes Berg (3):
bitfield: fix *_encode_bits()
bitfield: add u8 helpers
bitfield: add tests
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthikeyan Periyasamy (1):
ath10k: fix spectral scan for QCA9984 and QCA9888 chipsets
Lorenzo Bianconi (5):
mt76x2: fix mrr idx/count estimation in mt76x2_mac_fill_tx_status()
mt76: introduce mt76_{incr,decr} utility routines
mt76x2: dfs: add sw event ring buffer
mt76x2: dfs: add sw pattern detector
mt76x2: debugfs: add sw pulse statistics to dfs debugfs
Niklas Cassel (1):
ath10k: do not mix spaces and tabs in Kconfig
Omer Efrat (1):
wireless-drivers: use BIT_ULL for NL80211_STA_INFO_ attribute types
Rafa=C5=82 Mi=C5=82ecki (5):
brcmfmac: detect firmware support for monitor interface
brcmfmac: detect firmware support for radiotap monitor frames
brcmfmac: handle msgbuf packets marked with monitor mode flag
brcmfmac: define more bits for the flags of struct brcmf_sta_info_le
brcmfmac: update STA info struct to the v5
Sebastian Andrzej Siewior (3):
libertas_tf: use irqsave() in USB's complete callback
libertas: use irqsave() in USB's complete callback
zd1211rw: use irqsave() in USB's complete callback
Stefan Agner (1):
brcmsmac: fix wrap around in conversion from constant to s16
Surabhi Vishnoi (1):
ath10k: skip data calibration for non-bmi target
Tony Lindgren (7):
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
wlcore: Make sure PM calls are paired
wlcore: Add support for runtime PM
wlcore: Fix misplaced PM call for scan_complete_work()
wlcore: Fix timout errors after recovery
wlcore: Make sure firmware is initialized in wl1271_op_add_interface()
wlcore: Enable runtime PM autosuspend support
Varsha Rao (2):
brcmsmac: Remove unnecessary parentheses
net: ipw2x00: Replace NULL comparison with !priv
Wei Yongjun (1):
ath10k: make some functions static
Xinming Hu (1):
mwifiex: uap: do not chok ethernet header in bridge path
YueHaibing (4):
ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_sr=
c_ring_64
ath10k: use dma_zalloc_coherent instead of allocator/memset
atmel: use memdup_user to simplify the code
atmel: using strlcpy() to avoid possible buffer overflows
drivers/net/wireless/ath/ath10k/Kconfig | 24 +-
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
drivers/net/wireless/ath/ath10k/ce.h | 42 ++
drivers/net/wireless/ath/ath10k/core.c | 19 +-
drivers/net/wireless/ath/ath10k/core.h | 3 +-
drivers/net/wireless/ath/ath10k/debug.c | 21 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +-
drivers/net/wireless/ath/ath10k/hw.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 7 +-
drivers/net/wireless/ath/ath10k/pci.h | 42 --
drivers/net/wireless/ath/ath10k/snoc.c | 47 +-
drivers/net/wireless/ath/ath10k/snoc.h | 1 -
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 14 +-
drivers/net/wireless/ath/ath5k/pcu.c | 1 +
drivers/net/wireless/ath/ath6kl/cfg80211.c | 17 +-
drivers/net/wireless/ath/ath6kl/sdio.c | 1 +
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 18 +-
drivers/net/wireless/atmel/atmel.c | 14 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 40 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 25 +
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 6 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 43 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 18 +
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 2 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.h | 12 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 6 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 +-
drivers/net/wireless/marvell/libertas/cfg.c | 12 +-
drivers/net/wireless/marvell/libertas/dev.h | 1 +
drivers/net/wireless/marvell/libertas/if_sdio.c | 30 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 7 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 8 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +-
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 52 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 12 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 16 +-
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 22 +
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 377 ++++++++++++++-
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 64 +++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 39 +-
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 107 ++++-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 33 ++
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 +
drivers/net/wireless/quantenna/qtnfmac/commands.c | 57 ++-
drivers/net/wireless/quantenna/qtnfmac/core.c | 25 +
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 20 +
drivers/net/wireless/rndis_wlan.c | 6 +-
drivers/net/wireless/ti/wl18xx/debugfs.c | 29 +-
drivers/net/wireless/ti/wlcore/acx.c | 1 -
drivers/net/wireless/ti/wlcore/cmd.c | 10 +
drivers/net/wireless/ti/wlcore/debugfs.c | 90 ++--
drivers/net/wireless/ti/wlcore/main.c | 528 ++++++++++++++---=
----
drivers/net/wireless/ti/wlcore/ps.c | 146 ------
drivers/net/wireless/ti/wlcore/ps.h | 3 -
drivers/net/wireless/ti/wlcore/scan.c | 13 +-
drivers/net/wireless/ti/wlcore/sysfs.c | 13 +-
drivers/net/wireless/ti/wlcore/testmode.c | 20 +-
drivers/net/wireless/ti/wlcore/tx.c | 10 +-
drivers/net/wireless/ti/wlcore/vendor_cmd.c | 30 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 1 -
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 -
drivers/net/wireless/zydas/zd1211rw/zd_chip.c | 2 +-
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 21 +-
include/linux/bitfield.h | 7 +-
lib/Kconfig.debug | 7 +
lib/Makefile | 1 +
lib/test_bitfield.c | 168 +++++++
79 files changed, 1787 insertions(+), 704 deletions(-)
create mode 100644 lib/test_bitfield.c
^ permalink raw reply
* [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
From: Stefan Herbrechtsmeier @ 2018-07-23 18:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <f6624e7e-2b89-ff90-c648-c43316aca718@xilinx.com>
Hi Michal,
Am 23.07.2018 um 11:08 schrieb Michal Simek:
> On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote:
>> Am 12.07.2018 um 16:04 schrieb Michal Simek:
>>> There should be proper bank name setup to distiguish between different
>>> gpio drivers. Use dev->name for it.
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>> ---
>>>
>>> drivers/gpio/zynq_gpio.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
>>> index 26f69b1a713f..f793ee5754a8 100644
>>> --- a/drivers/gpio/zynq_gpio.c
>>> +++ b/drivers/gpio/zynq_gpio.c
>>> @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
>>> struct zynq_gpio_privdata *priv = dev_get_priv(dev);
>>> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
>>> + uc_priv->bank_name = dev->name;
>>> +
>>> if (priv->p_data)
>>> uc_priv->gpio_count = priv->p_data->ngpio;
>>>
>> Does this not lead to ugly names because the gpio number is append to
>> the bank_name? Have you check the "gpio status -a" output?
> Yes I was checking it. Names are composed together but also just numbers
> works as before.
>
> gpio at ff0a00000: input: 0 [ ]
> gpio at ff0a00001: input: 0 [ ]
> gpio at ff0a00002: input: 0 [ ]
> gpio at ff0a00003: input: 0 [ ]
> gpio at ff0a00004: input: 0 [ ]
> gpio at ff0a00005: input: 0 [ ]
> gpio at ff0a00006: input: 0 [ ]
> gpio at ff0a00007: input: 0 [ ]
> gpio at ff0a00008: input: 0 [ ]
> gpio at ff0a00009: input: 0 [ ]
Do you think that this are meaningful names? It isn't possible to
separate the device and pin number as well as it mix hex and decimal
numbers.
> If you know better way how to setup a bank name please let me know but I
> need to distinguish ps gpio from pl one and for pl we need to know the
> address.
I know the use case.
A lot of drivers use the bank_name from the device tree, some drivers
append an underscore to the bank name and others add the req_seq of the
device to an alphabetic character.
>> Other drivers use the gpio-bank-name from the device tree.
> I can't see this property inside Linux kernel. If this has been reviewed
> by dt guys please let me know.
This property is only used by u-boot. I think it isn't needed by the
Linux kernel.
Best regards
Stefan
^ permalink raw reply
* Re: [PATCH 3/5] coccinelle: exclude sha1dc source files from static analysis
From: Eric Sunshine @ 2018-07-23 18:27 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Git List, René Scharfe, Derrick Stolee,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20180723135100.24288-4-szeder.dev@gmail.com>
On Mon, Jul 23, 2018 at 9:51 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> sha1dc is an external library, that we carry in-tree for convenience
> or grab as a submodule, so there is no use in applying our semantic
> patches to its source files.
>
> Therefore, exclude sha1dc's source files from Coccinelle's static
> analysis.
>
> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> ---
> diff --git a/Makefile b/Makefile
> @@ -2666,10 +2666,16 @@ check: command-list.h
> +ifdef DC_SHA1_SUBMODULE
> +COCCI_SOURCES = $(filter-out sha1collisiondetection/%,$(C_SOURCES))
> +else
> +COCCI_SOURCES = $(filter-out sha1dc/%,$(C_SOURCES))
> +endif
Can't you just filter out both of these unconditionally without
worrying about DC_SHA1_SUBMODULE?
^ permalink raw reply
* [PATCH] net/mlx5: fix possible endless loop when clearing flow flags
From: Yongseok Koh @ 2018-07-23 18:27 UTC (permalink / raw)
To: shahafs; +Cc: dev, Yongseok Koh, Nelio Laranjeiro
If one of (*priv->rxqs)[] is null, the for loop can iterate infinitely as
idx can't be increased.
Fixes: cd24d526395e ("net/mlx5: add mark/flag flow action")
Cc: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
drivers/net/mlx5/mlx5_flow.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 32854198b..c156f01eb 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2762,22 +2762,20 @@ mlx5_flow_rxq_flags_clear(struct rte_eth_dev *dev)
{
struct priv *priv = dev->data->dev_private;
unsigned int i;
- unsigned int idx;
- for (idx = 0, i = 0; idx != priv->rxqs_n; ++i) {
+ for (i = 0; i != priv->rxqs_n; ++i) {
struct mlx5_rxq_ctrl *rxq_ctrl;
unsigned int j;
- if (!(*priv->rxqs)[idx])
+ if (!(*priv->rxqs)[i])
continue;
- rxq_ctrl = container_of((*priv->rxqs)[idx],
+ rxq_ctrl = container_of((*priv->rxqs)[i],
struct mlx5_rxq_ctrl, rxq);
rxq_ctrl->flow_mark_n = 0;
rxq_ctrl->rxq.mark = 0;
for (j = 0; j != MLX5_FLOW_TUNNEL; ++j)
rxq_ctrl->flow_tunnels_n[j] = 0;
rxq_ctrl->rxq.tunnel = 0;
- ++idx;
}
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 16/17] media: v4l2: async: Remove notifier subdevs array
From: Sakari Ailus @ 2018-07-23 17:24 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Sakari Ailus, linux-media, Steve Longerbeam,
Mauro Carvalho Chehab, Niklas Söderlund, Sebastian Reichel,
Hans Verkuil, open list
In-Reply-To: <a040c77f-2bee-5d0d-57ec-852ff30448e9@gmail.com>
On Mon, Jul 23, 2018 at 09:44:57AM -0700, Steve Longerbeam wrote:
>
>
> On 07/23/2018 05:35 AM, Sakari Ailus wrote:
> > Hi Steve,
> >
> > Thanks for the update.
> >
> > On Mon, Jul 09, 2018 at 03:39:16PM -0700, Steve Longerbeam wrote:
> > > All platform drivers have been converted to use
> > > v4l2_async_notifier_add_subdev(), in place of adding
> > > asd's to the notifier subdevs array. So the subdevs
> > > array can now be removed from struct v4l2_async_notifier,
> > > and remove the backward compatibility support for that
> > > array in v4l2-async.c.
> > >
> > > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > This set removes the subdevs and num_subdevs fieldsfrom the notifier (as
> > discussed previously) but it doesn't include the corresponding
> > driver changes. Is there a patch missing from the set?
>
> Hi Sakari, yes somehow patch 15/17 (the large patch to all drivers)
> got dropped by the ML, maybe because the cc-list was too big?
>
> I will resend with only linux-media and cc: you.
I noticed the patch in my inbox and I re-pushed my v4l2-fwnode branch,
including that patch. Please still resend to the list. Thanks.
--
Sakari Ailus
sakari.ailus@linux.intel.com
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Guenter Roeck @ 2018-07-23 18:27 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Anton Vasilyev, Greg Kroah-Hartman, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723172305.GD100814@dtor-ws>
On Mon, Jul 23, 2018 at 10:23:05AM -0700, Dmitry Torokhov wrote:
> On Mon, Jul 23, 2018 at 10:13:36AM -0700, Guenter Roeck wrote:
> > On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> > > static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> > > in vpd_probe() based on header's ro and rw sizes.
> > > In vpd_remove() vpd_section_destroy() performs deinitialization based
> > > on enabled flag, which is set to true by vpd_sections_init().
> > > This leads to call of vpd_section_destroy() on already destroyed section
> > > for probe-release-probe-release sequence if first probe performs
> > > ro_vpd initialization and second probe does not initialize it.
> > >
> >
> > I am not sure if the situation described can be seen in the first place.
> > The second probe would only not perform ro_vpd initialization if it fails
> > prior to that, ie if it fails to allocate memory or if there is a
> > consistency problem. In that case the remove function would not be called.
> >
> > However, there is a problem in the code: A partially failed probe will
> > leave the system in inconsistent state. Example: ro section initializes,
> > rw section fails to initialize. The probe will fail, but the ro section
> > will not be destroyed, its sysfs attributes still exist, and its memory
> > is still mapped. It would make more sense to fix _that_ problem.
> > Essentially, vpd_sections_init() should clean up after itself after it
> > fails to initialize a section.
> >
> > Note that I am not convinced that the "enabled" flag is needed in the first
> > place. It is only relevant if vpd_section_destroy() is called, which only
> > happens from the remove function. The remove function is only called if the
> > probe function succeeded. In that case it is always set for both sections.
>
> The problem will happen if coreboot memory changes between 2 probes so
> that header.ro_size is not 0 on the first pass and is 0 on the second
> pass. Not quite likely to ever happen in real life, but resetting a flag
> is pretty cheap to not do it.
>
If that can happen between probes, meaning it is not guaranteed to be
constant during the lifetime of the system, doesn't that mean it can
happen anytime ?
Guenter
^ permalink raw reply
* [PATCH v2] staging: gasket: use vzalloc instead of vmalloc/memset
From: Ivan Bornyakov @ 2018-07-23 18:30 UTC (permalink / raw)
To: devel; +Cc: linux-kernel, gregkh, benchan, jnjoseph, rspringer,
Ivan Bornyakov
In-Reply-To: <20180723153853.GA10528@kroah.com>
Use vzalloc instead of vmalloc followed by memset with 0.
Signed-off-by: Ivan Bornyakov <brnkv.i1@gmail.com>
---
drivers/staging/gasket/gasket_page_table.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c b/drivers/staging/gasket/gasket_page_table.c
index 9f8116112e0a..3ffc8d67ec05 100644
--- a/drivers/staging/gasket/gasket_page_table.c
+++ b/drivers/staging/gasket/gasket_page_table.c
@@ -330,7 +330,7 @@ int gasket_page_table_init(
pg_tbl = *ppg_tbl;
bytes = total_entries * sizeof(struct gasket_page_table_entry);
if (bytes != 0) {
- pg_tbl->entries = vmalloc(bytes);
+ pg_tbl->entries = vzalloc(bytes);
if (!pg_tbl->entries) {
gasket_nodev_error(
"No memory for address translation metadata.");
@@ -338,7 +338,6 @@ int gasket_page_table_init(
*ppg_tbl = NULL;
return -ENOMEM;
}
- memset(pg_tbl->entries, 0, bytes);
}
mutex_init(&pg_tbl->mutex);
@@ -1067,13 +1066,12 @@ static int gasket_alloc_extended_subtable(
subtable_bytes = sizeof(struct gasket_page_table_entry) *
GASKET_PAGES_PER_SUBTABLE;
- pte->sublevel = vmalloc(subtable_bytes);
+ pte->sublevel = vzalloc(subtable_bytes);
if (!pte->sublevel) {
free_page(page_addr);
memset(pte, 0, sizeof(struct gasket_page_table_entry));
return -ENOMEM;
}
- memset(pte->sublevel, 0, subtable_bytes);
/* Map the page into DMA space. */
if (pg_tbl->dma_ops) {
--
2.16.4
^ permalink raw reply related
* [PATCH i-g-t v7] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
From: Radhakrishna Sripada @ 2018-07-23 18:25 UTC (permalink / raw)
To: igt-dev; +Cc: intel-gfx, Daniel Vetter
From: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cleanup the testcases by moving the platform checks to a single function.
The earlier version of the path is posted here [1]
v2: Make use of the property enums to get the supported rotations
v3: Move hardcodings to a single function(Ville)
v4: Include the cherryview exception for reflect subtest(Maarten)
v5: Rebase and move the check from CNL to ICL for reflect-x case
v6: Fix the CI regression
v7: rebase
[1]: https://patchwork.freedesktop.org/patch/209647/
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
---
tests/kms_rotation_crc.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 6cb5858adb0f..f20b8a6d4ba1 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -43,6 +43,7 @@ typedef struct {
uint32_t override_fmt;
uint64_t override_tiling;
int devid;
+ int gen;
} data_t;
typedef struct {
@@ -284,6 +285,17 @@ static void prepare_fbs(data_t *data, igt_output_t *output,
igt_plane_set_position(plane, data->pos_x, data->pos_y);
}
+static void igt_check_rotation(data_t *data)
+{
+ if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
+ igt_require(data->gen >= 9);
+ if (data->rotation & IGT_REFLECT_X)
+ igt_require(data->gen >= 11 ||
+ (IS_CHERRYVIEW(data->devid) && (data->rotation & IGT_ROTATION_0)));
+ if (data->rotation & IGT_ROTATION_180)
+ igt_require(data->gen >= 4);
+}
+
static void test_single_case(data_t *data, enum pipe pipe,
igt_output_t *output, igt_plane_t *plane,
enum rectangle_type rect,
@@ -352,15 +364,18 @@ static void test_plane_rotation(data_t *data, int plane_type, bool test_bad_form
igt_display_require_output(display);
+ igt_check_rotation(data);
+
for_each_pipe_with_valid_output(display, pipe, output) {
igt_plane_t *plane;
int i, j;
- if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
- continue;
-
igt_output_set_pipe(output, pipe);
+ if (IS_CHERRYVIEW(data->devid) && (data->rotation & IGT_REFLECT_X) &&
+ pipe != kmstest_pipe_to_index('B'))
+ continue;
+
plane = igt_output_get_plane_type(output, plane_type);
igt_require(igt_plane_has_prop(plane, IGT_PLANE_ROTATION));
@@ -521,14 +536,13 @@ igt_main
};
data_t data = {};
- int gen = 0;
igt_skip_on_simulation();
igt_fixture {
data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
data.devid = intel_get_drm_devid(data.gfx_fd);
- gen = intel_gen(data.devid);
+ data.gen = intel_gen(data.devid);
kmstest_set_vt_graphics_mode();
@@ -541,16 +555,12 @@ igt_main
igt_subtest_f("%s-rotation-%s",
plane_test_str(subtest->plane),
rot_test_str(subtest->rot)) {
- igt_require(!(subtest->rot &
- (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
- gen >= 9);
data.rotation = subtest->rot;
test_plane_rotation(&data, subtest->plane, false);
}
}
igt_subtest_f("sprite-rotation-90-pos-100-0") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.pos_x = 100,
data.pos_y = 0;
@@ -560,7 +570,6 @@ igt_main
data.pos_y = 0;
igt_subtest_f("bad-pixel-format") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_fmt = DRM_FORMAT_RGB565;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -568,7 +577,6 @@ igt_main
data.override_fmt = 0;
igt_subtest_f("bad-tiling") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -579,9 +587,6 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
tiling_test_str(reflect_x->tiling),
rot_test_str(reflect_x->rot)) {
- igt_require(gen >= 10 ||
- (IS_CHERRYVIEW(data.devid) && reflect_x->rot == IGT_ROTATION_0
- && reflect_x->tiling == LOCAL_I915_FORMAT_MOD_X_TILED));
data.rotation = (IGT_REFLECT_X | reflect_x->rot);
data.override_tiling = reflect_x->tiling;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, false);
@@ -596,7 +601,7 @@ igt_main
enum pipe pipe;
igt_output_t *output;
- igt_require(gen >= 9);
+ igt_require(data.gen >= 9);
igt_display_require_output(&data.display);
for_each_pipe_with_valid_output(&data.display, pipe, output) {
--
2.9.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t v7] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
From: Radhakrishna Sripada @ 2018-07-23 18:25 UTC (permalink / raw)
To: igt-dev; +Cc: Anusha Srivatsa, intel-gfx, Daniel Vetter
From: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cleanup the testcases by moving the platform checks to a single function.
The earlier version of the path is posted here [1]
v2: Make use of the property enums to get the supported rotations
v3: Move hardcodings to a single function(Ville)
v4: Include the cherryview exception for reflect subtest(Maarten)
v5: Rebase and move the check from CNL to ICL for reflect-x case
v6: Fix the CI regression
v7: rebase
[1]: https://patchwork.freedesktop.org/patch/209647/
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
---
tests/kms_rotation_crc.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 6cb5858adb0f..f20b8a6d4ba1 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -43,6 +43,7 @@ typedef struct {
uint32_t override_fmt;
uint64_t override_tiling;
int devid;
+ int gen;
} data_t;
typedef struct {
@@ -284,6 +285,17 @@ static void prepare_fbs(data_t *data, igt_output_t *output,
igt_plane_set_position(plane, data->pos_x, data->pos_y);
}
+static void igt_check_rotation(data_t *data)
+{
+ if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
+ igt_require(data->gen >= 9);
+ if (data->rotation & IGT_REFLECT_X)
+ igt_require(data->gen >= 11 ||
+ (IS_CHERRYVIEW(data->devid) && (data->rotation & IGT_ROTATION_0)));
+ if (data->rotation & IGT_ROTATION_180)
+ igt_require(data->gen >= 4);
+}
+
static void test_single_case(data_t *data, enum pipe pipe,
igt_output_t *output, igt_plane_t *plane,
enum rectangle_type rect,
@@ -352,15 +364,18 @@ static void test_plane_rotation(data_t *data, int plane_type, bool test_bad_form
igt_display_require_output(display);
+ igt_check_rotation(data);
+
for_each_pipe_with_valid_output(display, pipe, output) {
igt_plane_t *plane;
int i, j;
- if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
- continue;
-
igt_output_set_pipe(output, pipe);
+ if (IS_CHERRYVIEW(data->devid) && (data->rotation & IGT_REFLECT_X) &&
+ pipe != kmstest_pipe_to_index('B'))
+ continue;
+
plane = igt_output_get_plane_type(output, plane_type);
igt_require(igt_plane_has_prop(plane, IGT_PLANE_ROTATION));
@@ -521,14 +536,13 @@ igt_main
};
data_t data = {};
- int gen = 0;
igt_skip_on_simulation();
igt_fixture {
data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
data.devid = intel_get_drm_devid(data.gfx_fd);
- gen = intel_gen(data.devid);
+ data.gen = intel_gen(data.devid);
kmstest_set_vt_graphics_mode();
@@ -541,16 +555,12 @@ igt_main
igt_subtest_f("%s-rotation-%s",
plane_test_str(subtest->plane),
rot_test_str(subtest->rot)) {
- igt_require(!(subtest->rot &
- (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
- gen >= 9);
data.rotation = subtest->rot;
test_plane_rotation(&data, subtest->plane, false);
}
}
igt_subtest_f("sprite-rotation-90-pos-100-0") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.pos_x = 100,
data.pos_y = 0;
@@ -560,7 +570,6 @@ igt_main
data.pos_y = 0;
igt_subtest_f("bad-pixel-format") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_fmt = DRM_FORMAT_RGB565;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -568,7 +577,6 @@ igt_main
data.override_fmt = 0;
igt_subtest_f("bad-tiling") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -579,9 +587,6 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
tiling_test_str(reflect_x->tiling),
rot_test_str(reflect_x->rot)) {
- igt_require(gen >= 10 ||
- (IS_CHERRYVIEW(data.devid) && reflect_x->rot == IGT_ROTATION_0
- && reflect_x->tiling == LOCAL_I915_FORMAT_MOD_X_TILED));
data.rotation = (IGT_REFLECT_X | reflect_x->rot);
data.override_tiling = reflect_x->tiling;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, false);
@@ -596,7 +601,7 @@ igt_main
enum pipe pipe;
igt_output_t *output;
- igt_require(gen >= 9);
+ igt_require(data.gen >= 9);
igt_display_require_output(&data.display);
for_each_pipe_with_valid_output(&data.display, pipe, output) {
--
2.9.3
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to 3-byte addressing.
From: Brian Norris @ 2018-07-23 18:25 UTC (permalink / raw)
To: NeilBrown
Cc: Marek Vasut, Cyrille Pitchen, David Woodhouse, Boris Brezillon,
Richard Weinberger, linux-mtd, Linux Kernel, Hou Zhiqiang
In-Reply-To: <87efjnvpjl.fsf@notabene.neil.brown.name>
Hi,
I'm a little late to this thread, but I recently noticed (and
complained about) commit: 59b356ffd0b0 ("mtd: m25p80: restore the
status of SPI flash when exiting").
On Mon, Apr 9, 2018 at 6:05 PM, NeilBrown <neil@brown.name> wrote:
> On Mon, Apr 09 2018, Marek Vasut wrote:
>
>> On 04/08/2018 11:56 PM, NeilBrown wrote:
>>> On Sun, Apr 08 2018, Marek Vasut wrote:
>>>
>>>> On 04/08/2018 09:04 AM, NeilBrown wrote:
>>>>>
>>>>> According to section
>>>>> 8.2.7 Write Extended Address Register (C5h)
>>>>>
>>>>> of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)
>>>>>
>>>>> The Extended Address Register is only effective when the device is
>>>>> in the 3-Byte Address Mode. When the device operates in the 4-Byte
>>>>> Address Mode (ADS=1), any command with address input of A31-A24
>>>>> will replace the Extended Address Register values. It is
>>>>> recommended to check and update the Extended Address Register if
>>>>> necessary when the device is switched from 4-Byte to 3-Byte Address
>>>>> Mode.
>>>>>
>>>>> This patch adds code to implement that recommendation. Without this,
>>>>> my GNUBEE-PC1 will not successfully reboot, as the Extended Address
>>>>> Register is left with a value of '1'. When the SOC attempts to read
>>>>> (in 3-byte address mode) the boot loader, it reads from the wrong
>>>>> location.
>>>>
>>>> Your board is broken by design and does not implement proper reset logic
>>>> for the SPI NOR chip, right ? That is, when the CPU resets, the SPI NOR
>>>> is left in some random undefined state instead of being reset too, yes?
>>>
>>> Thanks for the reply.
>>
>> Sorry for the delay.
>>
>>> "Broken" is an emotive word :-) Certain the board *doesn't* reset the NOR
>>> chip on reset.
>>
>> It's not emotive, it is descriptive of what it really is. Such boards
>> which do not correctly reset the SPI NOR can, during ie. reset, get into
>> a state where the system is unbootable or corrupts the content of the
>> SPI NOR. This stuff came up over and over on the ML, it seems HW
>> designers never learn.
>
> Ok, the board is broken.
> Still, Linux has a history of even supporting broken hardware - Spectre
> and Meltdown for example.
Except those can generally be worked around at the expense of
performance. This is impossible to workaround completely without
hardware changes.
> I wouldn't propose a fix that harms the kernel in any way (hurts
> maintainability or negatively affect other hardware), but I don't
> think my proposed patch does.
No, yours doesn't, but the original patch (Commit: 59b356ffd0b0 ("mtd:
m25p80: restore the status of SPI flash when exiting")) started us
down the slippery slope. If things work 99% of the time, people often
fail to notice that they are broken for the 1%. Thus, that patch can
harm future development, where unwitting designers think things are
working fine and fail to fix their hardware. That's not to say
designers always notice even when things are really really broken, but
that patch makes the brokenness much harder to notice.
>>> However the NOR chip doesn't have a dedicated RESET pin. It has a pin
>>> that defaults to "HOLD" and can be programmed to act as "RESET". This
>>> pin is tied to 3V3 on my board. If it were tied to a reset line, it
>>> would still need code changes to work (or switch from the default).
>>
>> I'm afraid this needs HW changes. The solution for SPI NORs without a
>> dedicated reset line is to just hard cut the power to them for a while
>> in case the CPU core reset out is asserted.
>>
>>> A few month ago:
>>> Commit: 8dee1d971af9 ("mtd: spi-nor: add an API to restore the status of SPI flash chip")
>>> Commit: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exiting")
>>
>> This works when reloading the driver, but not when restarting the system.
>
> I don't understand what you are saying.
> The second patch provides a ->shutdown function for the spi_driver.
> This is called by spi_drv_shutdown which is called by the driver
> ->shutdown function, which is called by device_shutdown(), which
> is only called by
> kernel_shutdown_prepare() and
> kernel_restart_prepare().
>
> So it works exactly when restarting the system, and not when reloading
> the driver.
>
>>
>>> were added to Linux. They appear to be designed to address a very
>>> similar situation to mine. Unfortunately they aren't complete as the
>>> code to disable 4-byte addressing doesn't follow documented requirements
>>> (at least for winbond) and doesn't work as intended (at least in one
>>> case - mine). This code should either be fixed (e.g. with my patch), or removed.
I would (and already did) vote for removal. The shutdown() hook just
papers over bugs and leads people to think that it is a good solution.
There's a reason we rejected such patches repeatedly in the past. This
one slipped through.
Brian
^ permalink raw reply
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.