* Re: [PATCH] usb: dwc2: Fix shutdown callback in platform
From: Doug Anderson @ 2020-05-29 18:45 UTC (permalink / raw)
To: Frank Mori Hess
Cc: Minas Harutyunyan, John Youn, Felipe Balbi, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, # 4.0+
In-Reply-To: <CAJz5OpdMDumfdYC+aj0N20p4qVEkEkHhNY3uKest6RSpPtrDWQ@mail.gmail.com>
Hi,
On Fri, May 29, 2020 at 11:21 AM Frank Mori Hess <fmh6jj@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 1:53 PM Doug Anderson <dianders@chromium.org> wrote:
> > >
> > > I don't get it. A hypothetical machine could have literally anything
> > > sharing the IRQ line, right?
> >
> > It's not a real physical line, though? I don't think it's common to
> > have a shared interrupt between different IP blocks in a given SoC.
> > Even if it existed, all the drivers should disable their interrupts?
>
> I don't know, it's a hypothetical machine so it can be whatever you
> want. The driver requests shared irqs, if it doesn't actually support
> irq sharing, it shouldn't request them.
I guess? As I understood it drivers have to be very carefully coded
up to support sharing their IRQ with someone else and I'm not
convinced dwc2 does that anyway. Certainly it doesn't hurt to keep
dwc2 clean, but until I see someone that's actually sharing dwc2's
interrupt and I can actually see an example I'm not sure I'm going to
spend too much time thinking about it.
> > > Anyways, my screaming interrupt occurs after a a new kernel has been
> > > booted with kexec. In this case, it doesn't matter if the old kernel
> > > called disable_irq or not. As soon as the new kernel re-enables the
> > > interrupt line, the kernel immediately disables it again with a
> > > backtrace due to the unhandled screaming interrupt. That's why the
> > > dwc2 hardware needs to have its interrupts turned off when the old
> > > kernel is shutdown.
> >
> > Isn't that a bug with your new kernel? I've seen plenty of bugs where
> > drivers enable their interrupt before their interrupt handler is set
> > to handle it. You never know what state the bootloader (or previous
> > kernel) might have left things in and if an interrupt was pending it
> > shouldn't kill you.
>
> It wouldn't hurt to add disabling of the dwc2 irq early in dwc2
> initialization,
More than it not hurting, I'd consider it a bug in the driver (and a
much more serious one than shutdown not disabling the interrupt).
> but why leave the irq screaming after shutdown?
Sure. So I guess the answer is to just do both disable the interrupt
and make sure that the interrupt handler has finished.
dwc2_disable_global_interrupts(hsotg);
disable_irq(hsotg->irq);
-Doug
^ permalink raw reply
* Re: [PATCH v2 3/3] selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
From: Sargun Dhillon @ 2020-05-29 18:46 UTC (permalink / raw)
To: Kees Cook
Cc: christian.brauner, containers, cyphar, jannh, jeffv, linux-api,
linux-kernel, palmer, rsesek, tycho, Matt Denton
In-Reply-To: <202005290036.3FEFFDA@keescook>
On Fri, May 29, 2020 at 12:41:51AM -0700, Kees Cook wrote:
> On Thu, May 28, 2020 at 04:08:58AM -0700, Sargun Dhillon wrote:
> > + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0);
> > +
> > + nextid = req.id + 1;
> > +
> > + /* Wait for getppid to be called for the second time */
> > + sleep(1);
>
> I always rebel at finding "sleep" in tests. ;) Is this needed? IIUC,
> userspace will immediately see EINPROGRESS after the NOTIF_SEND
> finishes, yes?
>
> Otherwise, yes, this looks good.
>
> --
> Kees Cook
I'm open to better suggestions, but there's a race where if getppid
is not called before the second SECCOMP_IOCTL_NOTIF_ADDFD is called,
you will just get an ENOENT, since the notification ID is not found.
The other approach is to "poll" the child, and wait for it to enter
the second syscall. Calling receive beforehand doesn't work because
it moves the state of the notification in the kernel to received,
and then the kernel doesn't error with EINPROGRESS.
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH v4] perf inject --jit: Remove //anon mmap events
From: Steve MacLean @ 2020-05-29 18:48 UTC (permalink / raw)
To: Ian Rogers
Cc: Steve MacLean, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Stephane Eranian, LKML
In-Reply-To: <CAP-5=fV7F4u66388HC-q8btOYWKxtb1gTTi4LK_Besb-zE25Rw@mail.gmail.com>
> I've been trying variants of:
>
> Before:
>/tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java -agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer -XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o /tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep class\ |wc -l
> 578
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 6
>
> After:
> /tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java -agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer -XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o /tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep class\ |wc -l
> 589
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 60
>
> So maybe the jit cache isn't behaving the way that the patch cures, the uptick in unknowns appears consistent in my testing though. I expect user error, is there an obvious explanation I'm missing?
That is certainly disturbing. I don't see an obvious user error, but I haven't played with java jitdump
Couple of ideas come to mind.
+ When I was drafting .NET jitdump support, I looked briefly at the java agent. My impression was the java agent support wasn't thread safe. The jitdump file format requires that certain records are collocated to simplify the reader. I wasn't sure how that was being accomplished by the writer if JAVA's JIT was multithreaded (like CoreCLR JIT is).
+ The way I implemented jitdump on CoreCLR was to hook into the existing system to write perf-map files. So I am pretty confident there is a 1:1 correspondence of perf-map records with jitdump records. Is it possible that Java choose to only emit interesting jitdump records? Perhaps skipping thunks/stubs/trampolines?
+ There are still some `unknown` records in CoreCLR, but I don't believe there is an increase. I am pretty sure some of our stubs are not being generated. They were present in our before case too.
+ Your methodology would be more repeatable if you record once, and analyze multiple times. record, report, inject / report, inject / report
+ I was focusing on eliminating duplicate symbols for the same address. So having the module name in the report allowed me to see if the symbol was from jitdump or from perf-map. In the before case I could see duplicate symbols for the same address. This was how the problem was first observed.
+ I would be more interested in looking at the diff of the reports. Possibly sorted by address. Probably with zero context.
If I were to guess, I would think Java choose to optimize jitdump and only record interesting code.
So if we need to support that scenario the approach of this patch wouldn't work.
We would need to use a different approach. Ideas...
+ Keep anon mappings from overwriting jitdump mappings. Introduce a weak add map method, that would only fill empty/anon.
+ Move the anon mapping timestamp to the beginning of time, so they are processed first
+ Fix the kernel perf map events
+ Keep the anon mappings in a separate fall back map
I kind of like the add weak map approach.
^ permalink raw reply
* Re: [PATCH 0/2] HMP: qom-get and set
From: Dr. David Alan Gilbert @ 2020-05-29 18:48 UTC (permalink / raw)
To: qemu-devel, armbru; +Cc: berrange, clg, afaerber
In-Reply-To: <20200520151108.160598-1-dgilbert@redhat.com>
* Dr. David Alan Gilbert (git) (dgilbert@redhat.com) wrote:
> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>
> HMP has had a qom-set for a long time, but not a matching qom-get;
> various attempts have been made to add one over the last 5 years.
> Here's another go.
>
> It's got simpler due to a suggestion by Markus to take the output
> from qmp's qom-get. While we're here, rework hmp's qom-set to be
> a wrapper around the qmp equivalent, which simplifies it a bit.
>
> In one post people didn't particularly like the use of JSON,
> but in the intervening 4 years no one has implemented anything to
> avoid it, and the output is trivially readable for non-structures
> and still pretty readable for (the very rare) structures.
>
> Dave
Queued
>
> Dr. David Alan Gilbert (2):
> hmp: Implement qom-get HMP command
> hmp: Simplify qom_set
>
> hmp-commands.hx | 14 ++++++++++++++
> include/monitor/hmp.h | 1 +
> qom/qom-hmp-cmds.c | 34 +++++++++++++++++++++++-----------
> tests/qtest/test-hmp.c | 1 +
> 4 files changed, 39 insertions(+), 11 deletions(-)
>
> --
> 2.26.2
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: dw: Make DMA request line assignments explicit for Intel Medfield
From: Andy Shevchenko @ 2020-05-29 18:49 UTC (permalink / raw)
To: Serge Semin; +Cc: Mark Brown, linux-spi
In-Reply-To: <20200529184050.bkn72tash33zgoo4@mobilestation>
On Fri, May 29, 2020 at 09:40:50PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 09:31:49PM +0300, Andy Shevchenko wrote:
> > The 2afccbd283ae ("spi: dw: Discard static DW DMA slave structures")
> > did a clean up of global variables, which is fine, but messed up with
> > the carefully provided information in the custom DMA slave structures.
> > There reader can find an assignment of the DMA request lines in use.
> >
> > Partially revert the above mentioned commit to restore readability
> > and maintainability of the code.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > v2: rebased against latest spi/for-next
> > drivers/spi/spi-dw-dma.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c
> > index 1b96cec6d8cd..53d5257662e8 100644
> > --- a/drivers/spi/spi-dw-dma.c
> > +++ b/drivers/spi/spi-dw-dma.c
> > @@ -61,10 +61,8 @@ static void dw_spi_dma_maxburst_init(struct dw_spi *dws)
> >
> > static int dw_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
> > {
> > - struct dw_dma_slave slave = {
> > - .src_id = 0,
> > - .dst_id = 0
> > - };
>
> > + struct dw_dma_slave dma_tx = { .dst_id = 1 }, *tx = &dma_tx;
> > + struct dw_dma_slave dma_rx = { .src_id = 0 }, *rx = &dma_rx;
>
> You know my attitude to these changes.) But anyway what's the point in having
> the *tx and *rx pointers here? Without any harm to the readability you can use
> the structures names directly, don't you?
I will wait for Mark to decide.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message
From: Markus Elfring @ 2020-05-29 18:50 UTC (permalink / raw)
To: Michael Ellerman, Liao Pingfang, linuxppc-dev
Cc: Yi Wang, Tony Luck, Kees Cook, Wang Liang, Anton Vorontsov,
kernel-janitors, LKML, Colin Cross, Paul Mackerras, Xue Zhihong,
Greg Kroah-Hartman, Thomas Gleixner, Allison Randal
> Please just remove the message instead, it's a tiny allocation that's
> unlikely to ever fail, and the caller will print an error anyway.
How do you think about to take another look at a previous update suggestion
like the following?
powerpc/nvram: Delete three error messages for a failed memory allocation
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/patchwork/patch/752720/
https://lkml.org/lkml/2017/1/19/537
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message
From: Markus Elfring @ 2020-05-29 18:50 UTC (permalink / raw)
To: Michael Ellerman, Liao Pingfang, linuxppc-dev
Cc: Allison Randal, Anton Vorontsov, Benjamin Herrenschmidt,
Colin Cross, Greg Kroah-Hartman, Kees Cook, Paul Mackerras,
Thomas Gleixner, Tony Luck, Wang Liang, Xue Zhihong, Yi Wang,
LKML, kernel-janitors
> Please just remove the message instead, it's a tiny allocation that's
> unlikely to ever fail, and the caller will print an error anyway.
How do you think about to take another look at a previous update suggestion
like the following?
powerpc/nvram: Delete three error messages for a failed memory allocation
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/patchwork/patch/752720/
https://lkml.org/lkml/2017/1/19/537
Regards,
Markus
^ permalink raw reply
* [PATCH] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
From: Christophe Leroy @ 2020-05-29 18:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
From: Christophe Leroy <christophe.leroy@c-s.fr>
'thread' doesn't exist in kuap_check() macro.
Use 'current' instead.
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/book3s/32/kup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/32/kup.h b/arch/powerpc/include/asm/book3s/32/kup.h
index db0a1c281587..668508c8a1b5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -75,7 +75,7 @@
.macro kuap_check current, gpr
#ifdef CONFIG_PPC_KUAP_DEBUG
- lwz \gpr, KUAP(thread)
+ lwz \gpr, THREAD + KUAP(\current)
999: twnei \gpr, 0
EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE)
#endif
--
2.25.0
^ permalink raw reply related
* Re: Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select CONFIG_PCIEASPM by default")
From: Heiner Kallweit @ 2020-05-29 18:50 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org
In-Reply-To: <2e1ee784-7493-284b-96f9-96b2e0c4b817@gmail.com>
On 28.05.2020 23:44, Heiner Kallweit wrote:
> For whatever reason with this change (and losing ASPM control) I also
> loose the PCIe PME interrupts. This prevents my network card from
> resuming from runtime-suspend.
> Reverting the change brings back ASPM control and the PCIe PME irq's.
>
> Affected system is a Zotac MiniPC with a N3450 CPU:
> PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
>
I checked a little bit further and w/o ASPM control the root ports
don't have the PME service bit set in their capabilities.
Not sure whether this is a chipset bug or whether there's a better
explanation. However more chipsets may have such a behavior.
W/o the "default y" for ASPM control we also have the situation now
that the config option description says "When in doubt, say Y."
but it takes the EXPERT mode to enable it. This seems to be a little
bit inconsistent.
To cut a long story short:
At least on some systems this change has unwanted side effects.
^ permalink raw reply
* Re: [PATCH v2 04/14] x86/traps: Implement #CP handler and extend #PF for shadow stacks
From: Andrew Cooper @ 2020-05-29 18:50 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel, Wei Liu, Roger Pau Monné
In-Reply-To: <21cfcf09-930d-c0cd-6860-92523732a594@suse.com>
On 28/05/2020 14:31, Jan Beulich wrote:
> On 28.05.2020 15:22, Andrew Cooper wrote:
>> On 28/05/2020 13:03, Jan Beulich wrote:
>>> On 27.05.2020 21:18, Andrew Cooper wrote:
>>>> @@ -940,7 +944,8 @@ autogen_stubs: /* Automatically generated stubs. */
>>>> entrypoint 1b
>>>>
>>>> /* Reserved exceptions, heading towards do_reserved_trap(). */
>>>> - .elseif vec == TRAP_copro_seg || vec == TRAP_spurious_int || (vec > TRAP_simd_error && vec < TRAP_nr)
>>>> + .elseif vec == X86_EXC_CSO || vec == X86_EXC_SPV || \
>>>> + vec == X86_EXC_VE || (vec > X86_EXC_CP && vec < TRAP_nr)
>>> Adding yet another || here adds to the fragility of the entire
>>> construct. Wouldn't it be better to implement do_entry_VE at
>>> this occasion, even its handling continues to end up in
>>> do_reserved_trap()? This would have the benefit of avoiding the
>>> pointless checking of %spl first thing in its handling. Feel
>>> free to keep the R-b if you decide to go this route.
>> I actually have a different plan, which deletes this entire clause, and
>> simplifies our autogen sanity checking somewhat.
>>
>> For vectors which Xen has no implementation of (for whatever reason),
>> use DPL0, non-present descriptors, and redirect #NP[IDT] into
>> do_reserved_trap().
> Except that #NP itself being a contributory exception, if the such
> covered exception is also contributory (e.g. #CP) or of page fault
> class (e.g. #VE), we'd get #DF instead of #NP afaict.
Hmm. Good point.
I also had some other cleanup plans. (In due course,) I'll see what I
can do to make the status quo better.
~Andrew
^ permalink raw reply
* [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Guenter Roeck @ 2020-05-29 18:52 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20200529174210.GF17541@heinlein>
On 5/29/20 10:42 AM, Patrick Williams wrote:
> Hi Guenter,
>
> Thanks for the initial look at this.
>
> One question for you below...
>
> On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
>> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
>>> + /* Enable TEMP1 by default */
>>> + config |= ADM1278_TEMP1_EN;
>>> + ret = i2c_smbus_write_byte_data(client,
>>> + ADM1275_PMON_CONFIG,
>>> + config);
>>> + if (ret < 0) {
>>> + dev_err(&client->dev,
>>> + "Failed to enable temperature config\n");
>>> + return -ENODEV;
>>> + }
>>
>> This can be handled in a single operation, together with ADM1278_VOUT_EN
>> below. There is no need for two separate write operations.
>
> I don't know if you noticed here but the change ends up enabling
> TEMP1_EN in all cases. Is this acceptable? If not, do you have any
> preference on how it is selected for enablement?
>
I did. We are doing the same for output voltage already, so I am not that
much concerned about it. If it is, we might consider adding _enable
attribute support (see Documentation/hwmon/sysfs-interface.rst) to the
PMBus core (presumably as virtual PMBus commands) and let the user
enable/disable individual attributes as needed.
What _should_ really be done, of course, is that the BIOS/ROMMON
configures the chip as desired. Obviously that is not happening here.
Guenter
>>> /* Enable VOUT if not enabled (it is disabled by default) */
>>> if (!(config & ADM1278_VOUT_EN)) {
>>> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
>>> }
>>> }
>>>
>>> - if (config & ADM1278_TEMP1_EN)
>>> - info->func[0] |=
>>> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>>> if (config & ADM1278_VIN_EN)
>>> info->func[0] |= PMBUS_HAVE_VIN;
>>> break;
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20200529/64248c86/attachment.sig>
^ permalink raw reply
* [PATCH] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
From: Christophe Leroy @ 2020-05-29 18:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
From: Christophe Leroy <christophe.leroy@c-s.fr>
'thread' doesn't exist in kuap_check() macro.
Use 'current' instead.
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/book3s/32/kup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/32/kup.h b/arch/powerpc/include/asm/book3s/32/kup.h
index db0a1c281587..668508c8a1b5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -75,7 +75,7 @@
.macro kuap_check current, gpr
#ifdef CONFIG_PPC_KUAP_DEBUG
- lwz \gpr, KUAP(thread)
+ lwz \gpr, THREAD + KUAP(\current)
999: twnei \gpr, 0
EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE)
#endif
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Guenter Roeck @ 2020-05-29 18:52 UTC (permalink / raw)
To: Patrick Williams
Cc: Manikandan Elumalai, linux-hwmon, linux-aspeed, linux-kernel,
openbmc, manikandan.e, saipsdasari, patrickw3, vijaykhemka
In-Reply-To: <20200529174210.GF17541@heinlein>
[-- Attachment #1.1: Type: text/plain, Size: 1851 bytes --]
On 5/29/20 10:42 AM, Patrick Williams wrote:
> Hi Guenter,
>
> Thanks for the initial look at this.
>
> One question for you below...
>
> On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
>> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
>>> + /* Enable TEMP1 by default */
>>> + config |= ADM1278_TEMP1_EN;
>>> + ret = i2c_smbus_write_byte_data(client,
>>> + ADM1275_PMON_CONFIG,
>>> + config);
>>> + if (ret < 0) {
>>> + dev_err(&client->dev,
>>> + "Failed to enable temperature config\n");
>>> + return -ENODEV;
>>> + }
>>
>> This can be handled in a single operation, together with ADM1278_VOUT_EN
>> below. There is no need for two separate write operations.
>
> I don't know if you noticed here but the change ends up enabling
> TEMP1_EN in all cases. Is this acceptable? If not, do you have any
> preference on how it is selected for enablement?
>
I did. We are doing the same for output voltage already, so I am not that
much concerned about it. If it is, we might consider adding _enable
attribute support (see Documentation/hwmon/sysfs-interface.rst) to the
PMBus core (presumably as virtual PMBus commands) and let the user
enable/disable individual attributes as needed.
What _should_ really be done, of course, is that the BIOS/ROMMON
configures the chip as desired. Obviously that is not happening here.
Guenter
>>> /* Enable VOUT if not enabled (it is disabled by default) */
>>> if (!(config & ADM1278_VOUT_EN)) {
>>> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
>>> }
>>> }
>>>
>>> - if (config & ADM1278_TEMP1_EN)
>>> - info->func[0] |=
>>> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>>> if (config & ADM1278_VIN_EN)
>>> info->func[0] |= PMBUS_HAVE_VIN;
>>> break;
>>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
From: Ilia Mirkin @ 2020-05-29 18:53 UTC (permalink / raw)
To: Marc MERLIN; +Cc: nouveau
In-Reply-To: <20200529180315.GA18804-xnduUnryOU1AfugRpC6u6w@public.gmane.org>
On Fri, May 29, 2020 at 2:35 PM Marc MERLIN <marc_nouveau-xnduUnryOU1AfugRpC6u6w@public.gmane.org> wrote:
>
> Howdy,
>
> So, I have a Thinkpad P70 with hybrid graphics.
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] (rev a2)
> that one works fine, I can use i915 for the main screen, and nouveau to
> display on the external ports (external ports are only wired to nvidia
> chip, so it's impossible to use them without turning the nvidia chip
> on).
>
> I now got a newer P73 also with the same hybrid graphics (setup as such
> in the bios). It runs fine with i915, and I don't need to use external
> display with nouveau for now (it almost works, but I only see the mouse
> cursor on the external screen, no window or anything else can get
> displayed, very weird).
> 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1)
>
> What I need for now is either nouveau, or bbswitch if it still works to
> turn the nvidia chip off every time I power on/reboot/plug/unplug
> external power.
> if I don't load the nouveau module, I get this in powertop:
> Bad Runtime PM for PCI Device NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q]
> powertop cannot really turn it off and I get
> The battery reports a discharge rate of 63.0 W
>
> If I load the nouveau driver, the chip gets turned off (great), but it's
> unstable and hard crashes my laptop when I plug/unplug it from power
> after a few times.
> This is what I got in my logs after the last crash:
> intel-lpss 0000:00:15.0: power state changed by ACPI to D3cold
> intel-lpss 0000:00:15.1: power state changed by ACPI to D3cold
> snd_hda_intel 0000:00:1f.3: PME# enabled
> intel-lpss 0000:00:1e.0: power state changed by ACPI to D3cold
> snd_hda_intel 0000:00:1f.3: power state changed by ACPI to D3hot
> xhci_hcd 0000:01:00.2: PME# enabled
> nvidia-gpu 0000:01:00.3: PME# enabled
> pcieport 0000:05:00.0: PME# enabled
> xhci_hcd 0000:2c:00.0: PME# enabled
> pcieport 0000:05:02.0: PME# enabled
> pcieport 0000:04:00.0: PME# enabled
> pcieport 0000:00:1c.0: PME# enabled
> pcieport 0000:00:1c.0: power state changed by ACPI to D3cold
> nouveau 0000:01:00.0: power state changed by ACPI to D3cold
> pcieport 0000:00:01.0: PME# enabled
> pcieport 0000:00:01.0: power state changed by ACPI to D3cold
>
> I am using TLP to manage battery use, the driver might not like things getting turned off to save power
> (although when it works, I can get the laptop down to 10W)
>
> Any suggestions on my best way to just keep the nvidia chip off reliably?
> nouveau? bbswitch? other?
> (and before you ask, no, you cannot turn it off in the bios, it's hybrid or nvidia only)
>
>
> If that helps, here is what I got when I tried to use hybrid graphics to power an external
> monitor (just pasting for completeness, I don't need this to work for now)
>
> pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported
> VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
> nouveau: detected PR support, will not use DSM
> nouveau 0000:01:00.0: runtime IRQ mapping not provided by arch
> nouveau 0000:01:00.0: NVIDIA TU104 (164000a1)
> nouveau 0000:01:00.0: bios: version 90.04.4d.00.2c
> nouveau 0000:01:00.0: enabling bus mastering
> nouveau 0000:01:00.0: fb: 8192 MiB GDDR6
> vga_switcheroo: enabled
> [TTM] Zone kernel: Available graphics memory: 32730618 KiB
> [TTM] Zone dma32: Available graphics memory: 2097152 KiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> nouveau 0000:01:00.0: DRM: VRAM: 8192 MiB
> nouveau 0000:01:00.0: DRM: GART: 536870912 MiB
> nouveau 0000:01:00.0: DRM: BIT table 'A' not found
> nouveau 0000:01:00.0: DRM: BIT table 'L' not found
> nouveau 0000:01:00.0: DRM: TMDS table version 2.0
> nouveau 0000:01:00.0: DRM: DCB version 4.1
> nouveau 0000:01:00.0: DRM: DCB outp 00: 02800f66 04600020
> nouveau 0000:01:00.0: DRM: DCB outp 01: 02011f52 00020010
> nouveau 0000:01:00.0: DRM: DCB outp 02: 01022f36 04600010
> nouveau 0000:01:00.0: DRM: DCB outp 03: 04033f76 04600010
> nouveau 0000:01:00.0: DRM: DCB outp 04: 04044f86 04600020
> nouveau 0000:01:00.0: DRM: DCB conn 00: 00020047
> nouveau 0000:01:00.0: DRM: DCB conn 01: 00010161
> nouveau 0000:01:00.0: DRM: DCB conn 02: 00001248
> nouveau 0000:01:00.0: DRM: DCB conn 03: 01000348
> nouveau 0000:01:00.0: DRM: DCB conn 04: 02000471
> nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
> nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
> nouveau 0000:01:00.0: DRM: unknown connector type 48
> nouveau 0000:01:00.0: DRM: unknown connector type 48
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> memmap_init_zone_device initialised 2097152 pages in 16ms
> nouveau 0000:01:00.0: DRM: DMEM: registered 8192MB of device memory
> nouveau 0000:01:00.0: DRM: allocated 2560x1600 fb: 0x200000, bo 0000000018f13ee1
> nouveau 0000:01:00.0: fb1: nouveaudrmfb frame buffer device
>
> sauron:~$ xrandr --setprovideroutputsource 1 0
> sauron:~$ xrandr --listactivemonitors
> Monitors: 1
> 0: +*eDP-1 3840/382x2160/214+0+0 eDP-1
>
> sauron:~$ xrandr --auto
> sauron:~$ xrandr --listactivemonitors
> Monitors: 2
> 0: +*eDP-1 3840/382x2160/214+0+0 eDP-1
> 1: +HDMI-1-1 2560/641x1600/400+3840+0 HDMI-1-1
>
> moving to new window moves the mouse, but not windows get displayed.
Do you see anything in dmesg after this is set up? I'd expect some
errors about timeouts or something else.
Which kernel are you using? There have been some turing-specific fixes recently.
Also note that TLP has a problem where it forces the audio
sub-function to always-on which prevents the GPU from suspending.
Cheers,
-ilia
^ permalink raw reply
* Re: [PATCH rfc v3] New ioctl BTRFS_IOC_GET_CHUNK_INFO.
From: Hans van Kranenburg @ 2020-05-29 18:54 UTC (permalink / raw)
To: kreijack, dsterba, linux-btrfs, Josef Bacik
In-Reply-To: <5d757a91-503b-64b7-3416-5a26bb03022f@inwind.it>
On 5/29/20 6:23 PM, Goffredo Baroncelli wrote:
> On 5/28/20 11:03 PM, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 5/26/20 10:19 PM, Goffredo Baroncelli wrote:
>>> On 5/25/20 7:14 PM, David Sterba wrote:
>>>> I'll start with the data structures
> [...]
>>>>
>>>> This looks like a copy of btrfs_chunk and stripe, only removing items
>>>> not needed for the chunk information. Rather than copying the
>>>> unnecessary fileds like dev_uuid in stripe, this should be designed for
>>>> data exchange with the usecase in mind.
>>>
>>> There are two clients for this api:
>>> - btrfs fi us
>>> - btrfs dev us
>>>
>>> We can get rid of:
>>> - "offset" fields (2x)
>>> - "uuid" fields
>>>
>>> However the "offset" fields can be used to understand where a logical map
>>> is on the physical disks. I am thinking about a graphical tool to show this
>>> mapping, which doesn't exits yet -).
>>> The offset field may be used as key to get further information (like the chunk
>>> usage, see below)
>>>
>>> Regarding the UUID field, I agree it can be removed because it is redundant (there
>>> is already the devid)
>>>
>>>
>>>>
>>>> The format does not need follow the exact layout that kernel uses, ie.
>>>> chunk info with one embedded stripe and then followed by variable length
>>>> array of further stripes. This is convenient in one way but not in
>>>> another one. Alternatively each chunk can be emitted as a single entry,
>>>> duplicating part of the common fields and adding the stripe-specific
>>>> ones. This is for consideration.
>>>>
>>>> I've looked at my old code doing the chunk dump based on the search
>>>> ioctl and found that it also allows to read the chunk usage, with one
>>>> extra search to the block group item where the usage is stored. As this
>>>> is can be slow, it should be optional. Ie. the main ioctl structure
>>>> needs flags where this can be requested.
>>>
>>> This info could be very useful. I think to something like a balance of
>>> chunks which are near filled (or near empty). The question is if we
>>> should have a different ioctl.
>>
>> Do you mean that you want to allow to a non root user to run btrfs balance?
> No at all. The balance is an expensive operation that IMHO need root
> privileges to be started.
>
>>
>> Otherwise, no. IMO convenience functions for quickly retrieving a
>> specific subset of data should be created as reusable library functions
>> in the calling code, not as a redundant extra IOCTL that has to be
>> maintained.
>
> I think that there is a misunderstood. There is no intention to take the
> place of the current balance ioctl.
Ok, I'll rephrase. Using it to improve balance is not an argument for
adding a new IOCTL, since it has to run as root anyway, and then you can
use the SEARCH IOCTL. And as long as there's a few helper functions
which do the plumbing, SEARCH isn't that bad at just getting some chunk
and block group info.
-# python3
>>> import btrfs
>>> with btrfs.FileSystem('/') as fs:
... for chunk in fs.chunks():
... print(fs.block_group(chunk.vaddr))
...
block group vaddr 13631488 length 8388608 flags DATA used 8388608
used_pct 100
block group vaddr 22020096 length 8388608 flags SYSTEM|DUP used 114688
used_pct 1
block group vaddr 30408704 length 1073741824 flags METADATA|DUP used
889061376 used_pct 83
block group vaddr 1104150528 length 1073741824 flags DATA used
1073741824 used_pct 100
block group vaddr 2177892352 length 1073741824 flags DATA used
1073741824 used_pct 100
[...]
> The aim of this ioctl is only to get information about the chunk distribution.
> Getting the chunk information could help to perform a better balance.
> I.e. a balance which start from the chunk more empty the go forward
> processing the chunk more filled.
An example of this is the existing btrfs-balance-least-used program.
> Another case use is to visulize how
> the chunk are filled, or how the disks are used..
An example of that is btrfs-heatmap.
Hfgl,
Hans
^ permalink raw reply
* Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message
From: Markus Elfring @ 2020-05-29 18:50 UTC (permalink / raw)
To: Michael Ellerman, Liao Pingfang, linuxppc-dev
Cc: Yi Wang, Tony Luck, Kees Cook, Wang Liang, Anton Vorontsov,
kernel-janitors, LKML, Colin Cross, Paul Mackerras, Xue Zhihong,
Greg Kroah-Hartman, Thomas Gleixner, Allison Randal
> Please just remove the message instead, it's a tiny allocation that's
> unlikely to ever fail, and the caller will print an error anyway.
How do you think about to take another look at a previous update suggestion
like the following?
powerpc/nvram: Delete three error messages for a failed memory allocation
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231d3a@users.sourceforge.net/
https://lore.kernel.org/patchwork/patch/752720/
https://lkml.org/lkml/2017/1/19/537
Regards,
Markus
^ permalink raw reply
* [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Guenter Roeck @ 2020-05-29 18:55 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <6F5BD2D3-997D-4607-BC0C-B36497B51D13@fb.com>
On 5/29/20 10:57 AM, Vijay Khemka wrote:
>
>
> ?On 5/29/20, 5:47 AM, "Manikandan Elumalai" <manikandan.hcl.ers.epl@gmail.com> wrote:
>
> The adm1278 temperature sysfs attribute need it for one of the openbmc platform .
> This functionality is not enabled by default, so PMON_CONFIG needs to be modified in order to enable it.
>
> Signed-off-by : Manikandan Elumalai <manikandan.hcl.ers.epl@gmail.com>
>
> v2:
> - Add Signed-off-by.
> - Removed ADM1278_TEMP1_EN check.
> ---
> drivers/hwmon/pmbus/adm1275.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 5caa37fb..ab5fceb 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -666,7 +666,23 @@ static int adm1275_probe(struct i2c_client *client,
> tindex = 3;
>
> info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
> - PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> +
> + config = i2c_smbus_read_byte_data(client, ADM1275_PMON_CONFIG);
> + if (config < 0)
> + return config;
> +
> + /* Enable TEMP1 by default */
> + config |= ADM1278_TEMP1_EN;
> + ret = i2c_smbus_write_byte_data(client,
> + ADM1275_PMON_CONFIG,
> + config);
> + if (ret < 0) {
> + dev_err(&client->dev,
> + "Failed to enable temperature config\n");
> + return -ENODEV;
> + }
> You don't need this above code removing check as below should be enough to
> populate sysfs entry you need.
>
You mean you are only interested in having the attribute, even if it doesn't
report anything useful because monitoring is disabled in the chip ?
Sorry, I don't understand. Can you elaborate ?
Thanks,
Guenter
> /* Enable VOUT if not enabled (it is disabled by default) */
> if (!(config & ADM1278_VOUT_EN)) {
> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
> }
> }
>
> - if (config & ADM1278_TEMP1_EN)
> - info->func[0] |=
> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> if (config & ADM1278_VIN_EN)
> info->func[0] |= PMBUS_HAVE_VIN;
> break;
> --
> 2.7.4
>
>
>
^ permalink raw reply
* Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
From: Guenter Roeck @ 2020-05-29 18:55 UTC (permalink / raw)
To: Vijay Khemka, Manikandan Elumalai, linux-hwmon@vger.kernel.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
Cc: saipsdasari@fb.com, Patrick Williams, manikandan.e@hcl.com
In-Reply-To: <6F5BD2D3-997D-4607-BC0C-B36497B51D13@fb.com>
On 5/29/20 10:57 AM, Vijay Khemka wrote:
>
>
> On 5/29/20, 5:47 AM, "Manikandan Elumalai" <manikandan.hcl.ers.epl@gmail.com> wrote:
>
> The adm1278 temperature sysfs attribute need it for one of the openbmc platform .
> This functionality is not enabled by default, so PMON_CONFIG needs to be modified in order to enable it.
>
> Signed-off-by : Manikandan Elumalai <manikandan.hcl.ers.epl@gmail.com>
>
> v2:
> - Add Signed-off-by.
> - Removed ADM1278_TEMP1_EN check.
> ---
> drivers/hwmon/pmbus/adm1275.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 5caa37fb..ab5fceb 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -666,7 +666,23 @@ static int adm1275_probe(struct i2c_client *client,
> tindex = 3;
>
> info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
> - PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> +
> + config = i2c_smbus_read_byte_data(client, ADM1275_PMON_CONFIG);
> + if (config < 0)
> + return config;
> +
> + /* Enable TEMP1 by default */
> + config |= ADM1278_TEMP1_EN;
> + ret = i2c_smbus_write_byte_data(client,
> + ADM1275_PMON_CONFIG,
> + config);
> + if (ret < 0) {
> + dev_err(&client->dev,
> + "Failed to enable temperature config\n");
> + return -ENODEV;
> + }
> You don't need this above code removing check as below should be enough to
> populate sysfs entry you need.
>
You mean you are only interested in having the attribute, even if it doesn't
report anything useful because monitoring is disabled in the chip ?
Sorry, I don't understand. Can you elaborate ?
Thanks,
Guenter
> /* Enable VOUT if not enabled (it is disabled by default) */
> if (!(config & ADM1278_VOUT_EN)) {
> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
> }
> }
>
> - if (config & ADM1278_TEMP1_EN)
> - info->func[0] |=
> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> if (config & ADM1278_VIN_EN)
> info->func[0] |= PMBUS_HAVE_VIN;
> break;
> --
> 2.7.4
>
>
>
^ permalink raw reply
* [dunfell/master][PATCH] HACK: toolchain: re-instate secondary toolchain for now
From: Denys Dmytriyenko @ 2020-05-29 18:53 UTC (permalink / raw)
To: meta-arago
From: Denys Dmytriyenko <denys@ti.com>
The proper implementation with multiconfig is taking longer, so re-instate
the older solution for now with minor fixes.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
meta-arago-distro/conf/distro/include/toolchain-arm.inc | 6 ++++++
.../recipes-core/meta/external-arm-secondary-sdk-toolchain.bb | 4 ++++
.../packagegroups/packagegroup-cross-canadian.bbappend | 10 ++++++++++
3 files changed, 20 insertions(+)
create mode 100644 meta-arago-distro/recipes-core/meta/external-arm-secondary-sdk-toolchain.bb
create mode 100644 meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend
diff --git a/meta-arago-distro/conf/distro/include/toolchain-arm.inc b/meta-arago-distro/conf/distro/include/toolchain-arm.inc
index 0ee0a4c..58efc00 100644
--- a/meta-arago-distro/conf/distro/include/toolchain-arm.inc
+++ b/meta-arago-distro/conf/distro/include/toolchain-arm.inc
@@ -9,6 +9,9 @@ EAT_TARGET_SYS_arm = "${EAT_TARGET_SYS_ARMV5}"
EAT_TARGET_SYS_armv7a = "${EAT_TARGET_SYS_ARMV7}"
EAT_TARGET_SYS_aarch64 = "${EAT_TARGET_SYS_ARMV8}"
+SECONDARY_TARGET_ARCH = "invalid"
+SECONDARY_TARGET_ARCH_k3 = "armv7a"
+
TARGET_VENDOR = ""
TOOLCHAIN_BASE ?= "/opt"
@@ -31,6 +34,9 @@ PREFERRED_PROVIDER_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= "external-arm
PREFERRED_PROVIDER_binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= "external-arm-sdk-toolchain-${TRANSLATED_TARGET_ARCH}"
#PREFERRED_PROVIDER_gdb-cross-canadian-${TRANSLATED_TARGET_ARCH} = "external-arm-sdk-toolchain-${TRANSLATED_TARGET_ARCH}"
+PREFERRED_PROVIDER_gcc-cross-canadian-${SECONDARY_TARGET_ARCH} ?= "external-arm-secondary-sdk-toolchain-${SECONDARY_TARGET_ARCH}"
+PREFERRED_PROVIDER_binutils-cross-canadian-${SECONDARY_TARGET_ARCH} ?= "external-arm-secondary-sdk-toolchain-${SECONDARY_TARGET_ARCH}"
+
# Special case for gdb to be built as part of canadian-cross-sdk, instead of packaged from external toolchain
bindir_pn-gdb-cross-canadian-${TRANSLATED_TARGET_ARCH} = "${exec_prefix}/bin"
PREFERRED_PROVIDER_gdb-cross-canadian-${TRANSLATED_TARGET_ARCH} = "gdb-cross-canadian-${TRANSLATED_TARGET_ARCH}"
diff --git a/meta-arago-distro/recipes-core/meta/external-arm-secondary-sdk-toolchain.bb b/meta-arago-distro/recipes-core/meta/external-arm-secondary-sdk-toolchain.bb
new file mode 100644
index 0000000..22a8aa0
--- /dev/null
+++ b/meta-arago-distro/recipes-core/meta/external-arm-secondary-sdk-toolchain.bb
@@ -0,0 +1,4 @@
+TARGET_ARCH := "${SECONDARY_TARGET_ARCH}"
+MACHINEOVERRIDES := "${SECONDARY_TARGET_ARCH}"
+
+require recipes-core/meta/external-arm-sdk-toolchain.bb
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend b/meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend
new file mode 100644
index 0000000..9f59ac8
--- /dev/null
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend
@@ -0,0 +1,10 @@
+PR_append = ".arago0"
+
+SECONDARY_TARGET_ARCH ?= "invalid"
+
+SECONDARY_TOOLCHAIN = "gcc-cross-canadian-${SECONDARY_TARGET_ARCH} \
+ binutils-cross-canadian-${SECONDARY_TARGET_ARCH}"
+
+RDEPENDS_${PN}_append = " \
+ ${@oe.utils.conditional('SECONDARY_TARGET_ARCH', 'invalid', '', '${SECONDARY_TOOLCHAIN}', d)} \
+"
--
2.7.4
^ permalink raw reply related
* [PATCH 05/10] core: extend struct driver_info to point to device
From: Walter Lozano @ 2020-05-29 18:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529181521.22073-6-walter.lozano@collabora.com>
On 29/5/20 15:15, Walter Lozano wrote:
> Currently when creating an U_BOOT_DEVICE entry a struct driver_info
> is declared, which contains the data needed to instantiate the device.
> However, the actual device is created at runtime and there is no proper
> way to get the device based on its struct driver_info.
>
> This patch extends struct driver_info adding a pointer to udevice which
> is populated during the bind process, allowing to generate a set of
> functions to get the device based on its struct driver_info.
>
> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> ---
> drivers/core/device.c | 26 +++++++++++++++++++++++---
> drivers/core/root.c | 4 ++++
> include/dm/device.h | 14 ++++++++++++++
> include/dm/platdata.h | 14 ++++++++++++++
> 4 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index a0ad080aaf..5adbc30849 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -250,6 +250,7 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
> {
> struct driver *drv;
> uint platdata_size = 0;
> + int ret = 0;
>
> drv = lists_driver_lookup_name(info->name);
> if (!drv)
> @@ -260,9 +261,16 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
> platdata_size = info->platdata_size;
> #endif
> - return device_bind_common(parent, drv, info->name,
> - (void *)info->platdata, 0, ofnode_null(), platdata_size,
> - devp);
> + ret = device_bind_common(parent, drv, info->name,
> + (void *)info->platdata, 0, ofnode_null(),
> + platdata_size, devp);
> + if (ret)
> + return ret;
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> + info->dev = *devp;
> +#endif
I have tried to test this using sandbox_spl_defconfig but I've received
a segmentation fault when trying to update info->dev, however this code
works on iMX6.
Could it be some kind of protection? Any thoughts?
> +
> + return ret;
> }
>
> static void *alloc_priv(int size, uint flags)
> @@ -727,6 +735,18 @@ int device_get_global_by_ofnode(ofnode ofnode, struct udevice **devp)
> return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
> }
>
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> +int device_get_by_driver_info(const struct driver_info *info,
> + struct udevice **devp)
> +{
> + struct udevice *dev;
> +
> + dev = info->dev;
> +
> + return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
> +}
> +#endif
> +
> int device_find_first_child(const struct udevice *parent, struct udevice **devp)
> {
> if (list_empty(&parent->child_head)) {
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index c9ee56478a..8f47a6b356 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -346,6 +346,10 @@ int dm_init_and_scan(bool pre_reloc_only)
> {
> int ret;
>
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> + populate_phandle_data();
> +#endif
> +
> ret = dm_init(IS_ENABLED(CONFIG_OF_LIVE));
> if (ret) {
> debug("dm_init() failed: %d\n", ret);
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 2cfe10766f..a3b3e5bc46 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -538,6 +538,20 @@ int device_find_global_by_ofnode(ofnode node, struct udevice **devp);
> */
> int device_get_global_by_ofnode(ofnode node, struct udevice **devp);
>
> +/**
> + * device_get_by_driver_info() - Get a device based on driver_info
> + *
> + * Locates a device by its struct driver_info.
> + *
> + * The device is probed to activate it ready for use.
> + *
> + * @info: Struct driver_info
> + * @devp: Returns pointer to device if found, otherwise this is set to NULL
> + * @return 0 if OK, -ve on error
> + */
> +int device_get_by_driver_info(const struct driver_info *info,
> + struct udevice **devp);
> +
> /**
> * device_find_first_child() - Find the first child of a device
> *
> diff --git a/include/dm/platdata.h b/include/dm/platdata.h
> index c972fa6936..238379b0e4 100644
> --- a/include/dm/platdata.h
> +++ b/include/dm/platdata.h
> @@ -22,12 +22,14 @@
> * @name: Driver name
> * @platdata: Driver-specific platform data
> * @platdata_size: Size of platform data structure
> + * @dev: Device created from this structure data
> */
> struct driver_info {
> const char *name;
> const void *platdata;
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
> uint platdata_size;
> + struct udevice *dev;
> #endif
> };
>
> @@ -43,4 +45,16 @@ struct driver_info {
> #define U_BOOT_DEVICES(__name) \
> ll_entry_declare_list(struct driver_info, __name, driver_info)
>
> +/* Get a pointer to a given driver */
> +#define DM_GET_DEVICE(__name) \
> + ll_entry_get(struct driver_info, __name, driver_info)
> +
> +/**
> + * populate_phandle_data() - Populates phandle data in platda
> + *
> + * This populates phandle data with an U_BOOT_DEVICE entry get by
> + * DM_GET_DEVICE. The implementation of this function will be done
> + * by dtoc when parsing dtb.
> + */
> +void populate_phandle_data(void);
> #endif
^ permalink raw reply
* [Bug 1877418] Re: qemu-nbd freezes access to VDI file
From: John Snow @ 2020-05-29 18:49 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <158887096525.4808.16857448132122344597.malonedeb@soybean.canonical.com>
I agree, the program doesn't stop you from doing such things. It should
work without error, but it might be slow. Just offering some advice you
may not want to use it like this.
Try to reproduce with qcow2 and qemu-nbd to see if the problem is with
our support of the disk image format or if it's a problem with e.g. the
access patterns and qemu-nbd itself, for instance.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1877418
Title:
qemu-nbd freezes access to VDI file
Status in QEMU:
New
Status in btrfs-progs package in Ubuntu:
New
Bug description:
Mounted Oracle Virtualbox .vdi drive (dynamically allocated), which has GTP+BTRFS:
sudo modprobe nbd max_part=16
sudo qemu-nbd -c /dev/nbd0 /storage/btrfs.vdi
mount /dev/nbd0p1 /mydata/
Then I am operating on the btrfs filesystem and suddenly it freezes.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1877418/+subscriptions
^ permalink raw reply
* Re: [PATCH v8 0/8] powerpc: switch VDSO to C implementation
From: Christophe Leroy @ 2020-05-29 18:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, nathanl
Cc: linux-arch, arnd, linux-kernel, luto, tglx, vincenzo.frascino,
linuxppc-dev
In-Reply-To: <cover.1588079622.git.christophe.leroy@c-s.fr>
Hi Michael,
Le 28/04/2020 à 15:16, Christophe Leroy a écrit :
> This is the seventh version of a series to switch powerpc VDSO to
> generic C implementation.
>
> Main changes since v7 are:
> - Added gettime64 on PPC32
>
> This series applies on today's powerpc/merge branch.
>
> See the last patches for details on changes and performance.
Do you have any plans for this series ?
Even if you don't feel like merging it this cycle, I think patches 1 to
3 are worth it.
Christophe
>
> Christophe Leroy (8):
> powerpc/vdso64: Switch from __get_datapage() to get_datapage inline
> macro
> powerpc/vdso: Remove __kernel_datapage_offset and simplify
> __get_datapage()
> powerpc/vdso: Remove unused \tmp param in __get_datapage()
> powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
> powerpc/vdso: Prepare for switching VDSO to generic C implementation.
> powerpc/vdso: Switch VDSO to generic C implementation.
> lib/vdso: force inlining of __cvdso_clock_gettime_common()
> powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
>
> arch/powerpc/Kconfig | 2 +
> arch/powerpc/include/asm/clocksource.h | 7 +
> arch/powerpc/include/asm/processor.h | 10 +-
> arch/powerpc/include/asm/vdso/clocksource.h | 7 +
> arch/powerpc/include/asm/vdso/gettimeofday.h | 175 +++++++++++
> arch/powerpc/include/asm/vdso/processor.h | 23 ++
> arch/powerpc/include/asm/vdso/vsyscall.h | 25 ++
> arch/powerpc/include/asm/vdso_datapage.h | 50 ++--
> arch/powerpc/kernel/asm-offsets.c | 49 +--
> arch/powerpc/kernel/time.c | 91 +-----
> arch/powerpc/kernel/vdso.c | 58 +---
> arch/powerpc/kernel/vdso32/Makefile | 32 +-
> arch/powerpc/kernel/vdso32/cacheflush.S | 2 +-
> arch/powerpc/kernel/vdso32/config-fake32.h | 34 +++
> arch/powerpc/kernel/vdso32/datapage.S | 7 +-
> arch/powerpc/kernel/vdso32/gettimeofday.S | 300 +------------------
> arch/powerpc/kernel/vdso32/vdso32.lds.S | 8 +-
> arch/powerpc/kernel/vdso32/vgettimeofday.c | 35 +++
> arch/powerpc/kernel/vdso64/Makefile | 23 +-
> arch/powerpc/kernel/vdso64/cacheflush.S | 9 +-
> arch/powerpc/kernel/vdso64/datapage.S | 31 +-
> arch/powerpc/kernel/vdso64/gettimeofday.S | 243 +--------------
> arch/powerpc/kernel/vdso64/vdso64.lds.S | 7 +-
> arch/powerpc/kernel/vdso64/vgettimeofday.c | 29 ++
> lib/vdso/gettimeofday.c | 2 +-
> 25 files changed, 460 insertions(+), 799 deletions(-)
> create mode 100644 arch/powerpc/include/asm/clocksource.h
> create mode 100644 arch/powerpc/include/asm/vdso/clocksource.h
> create mode 100644 arch/powerpc/include/asm/vdso/gettimeofday.h
> create mode 100644 arch/powerpc/include/asm/vdso/processor.h
> create mode 100644 arch/powerpc/include/asm/vdso/vsyscall.h
> create mode 100644 arch/powerpc/kernel/vdso32/config-fake32.h
> create mode 100644 arch/powerpc/kernel/vdso32/vgettimeofday.c
> create mode 100644 arch/powerpc/kernel/vdso64/vgettimeofday.c
>
^ permalink raw reply
* Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Serge Semin @ 2020-05-29 18:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Rob Herring, Jarkko Nikula, Wolfram Sang,
Alexey Malahov, Thomas Bogendoerfer, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200529184534.wyyv5i7hcto5y3d3@mobilestation>
On Fri, May 29, 2020 at 09:45:37PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 09:42:01PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2020 at 09:22:56PM +0300, Serge Semin wrote:
> > > On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> > > > On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> >
> > > > you're sending
> > > > new versions too fast. Give people time to review.
> > >
> > > Yeah, you did. Sorry for sending the new versions very fast. Normally I prefer
> > > to keep up with comments so to past a particular maintainer review as fast as
> > > possible without long delays. In my experience the longer you wait, the lesser
> > > maintainers remember about your patchset, the harder for one to continue the
> > > next versions review.
> >
>
> > Documentation/process/submitting-patches.rst:
> >
> > "Wait for a minimum of one week before resubmitting or pinging reviewers -
> > possibly longer during busy times like merge windows."
>
> Good to know what I already know.) How much do you personally wait before
> resubmitting? In my experience reviewing your DW APB GPIO patches, no longer
> than a few hours.
Moreover the statement you cited is about the patches, which doesn't get any
attention from the maintainers/reviewers for quite some time. In this case I
normally resubmit the patches no sooner than a week. I was talking about the
situation when you get the review comments, which need to be addressed.
-Sergey
>
> -Sergey
>
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
^ permalink raw reply
* [git pull] IOMMU Fixes for Linux v5.7-rc7
From: Joerg Roedel @ 2020-05-29 18:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, iommu
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
Hi Linus,
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.7-rc7
for you to fetch changes up to 7cc31613734c4870ae32f5265d576ef296621343:
iommu: Fix reference count leak in iommu_group_alloc. (2020-05-29 15:27:50 +0200)
----------------------------------------------------------------
IOMMU Fixes for Linux v5.7-rc7
Including:
- Two compile test fixes for issues introduced during the
5.7-rc1 merge window.
- A fix for a reference count leak in an error path of
iommu_group_alloc().
----------------------------------------------------------------
Krzysztof Kozlowski (2):
ia64: Hide the archdata.iommu field behind generic IOMMU_API
x86: Hide the archdata.iommu field behind generic IOMMU_API
Qiushi Wu (1):
iommu: Fix reference count leak in iommu_group_alloc.
arch/ia64/include/asm/device.h | 2 +-
arch/x86/include/asm/device.h | 2 +-
drivers/iommu/iommu.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Please pull.
Thanks,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
From: Christophe Leroy @ 2020-05-29 18:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5ce7982c72424eb3e7abf78063d454c38c42b343.1590778219.git.christophe.leroy@csgroup.eu>
Le 29/05/2020 à 20:50, Christophe Leroy a écrit :
> From: Christophe Leroy <christophe.leroy@c-s.fr>
>
> 'thread' doesn't exist in kuap_check() macro.
>
> Use 'current' instead.
>
> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Argh, can you drop this line ?
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reported-by: kbuild test robot <lkp@intel.com>
> ---
> arch/powerpc/include/asm/book3s/32/kup.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/32/kup.h b/arch/powerpc/include/asm/book3s/32/kup.h
> index db0a1c281587..668508c8a1b5 100644
> --- a/arch/powerpc/include/asm/book3s/32/kup.h
> +++ b/arch/powerpc/include/asm/book3s/32/kup.h
> @@ -75,7 +75,7 @@
>
> .macro kuap_check current, gpr
> #ifdef CONFIG_PPC_KUAP_DEBUG
> - lwz \gpr, KUAP(thread)
> + lwz \gpr, THREAD + KUAP(\current)
> 999: twnei \gpr, 0
> EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE)
> #endif
>
^ 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.