On 10 October 2020 12:44:10 BST, Thomas Gleixner wrote:
>On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote:
>> On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote:
>>> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
>>> For the next submission, can you
On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote:
> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
> > On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
> > > >
> > > > (We'd want the x86_vector_domain to actually have an MSI compose
> &
From: David Woodhouse
Some hypervisors can allow the guest to use the Extended Destination ID
field in the MSI address to address up to 32768 CPUs.
This applies to all downstream devices which generate MSI cycles,
including HPET, I/OAPIC and PCI MSI.
HPET and PCI MSI use the same
From: David Woodhouse
This isn't really dependent on PCI MSI; it's just generic MSI which is
now supported by the generic x86_vector_domain. Move the HPET MSI
support back into hpet.c with the rest of the HPET support.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/hpet.h | 11
From: David Woodhouse
This allows the host to indicate that MSI emulation supports 15-bit
destination IDs, allowing up to 32768 CPUs without interrupt remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
From: David Woodhouse
The Intel IOMMU has an MSI-like configuration for its interrupt, but
it isn't really MSI. So it gets to abuse the high 32 bits of the address,
and puts the high 24 bits of the extended APIC ID there.
This isn't something that can be used in the general case for real MSIs
From: David Woodhouse
This shouldn't be dependent on PCI_MSI. HPET and I/OAPIC can deliver
interrupts through MSI without having any PCI in the system at all.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h | 8 +++-
arch/x86/kernel/apic/apic.c | 32
From: David Woodhouse
Currently, Linux as a hypervisor guest will enable x2apic only if there
are no CPUs present at boot time with an APIC ID above 255.
Hotplugging a CPU later with a higher APIC ID would result in a CPU
which cannot be targeted by external interrupts.
Add a filter
From: David Woodhouse
Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to
bits 19-4 of the address used in the resulting MSI cycle.
Historically, the x86 MSI format only used the top 8 of those 16 bits as
the destination APIC ID, and the "Extended Destination ID" in t
From: David Woodhouse
The I/OAPIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense,
but now is just a bunch of bits which get passed through in some
seemingly arbitrary order.
Instead of making IRQ remapping
.
v2:
• Minor cleanups.
• Move __irq_msi_compose_msg() to apic.c, make virt_ext_dest_id static.
• Generate I/OAPIC RTE directly from parent irqchip's MSI messages.
• Clean up HPET MSI support into hpet.c now that we can.
David Woodhouse (8):
x86/apic: Fix x2apic enablement without interrupt
On 9 October 2020 00:27:06 BST, Thomas Gleixner wrote:
>On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
>> On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
>>> >
>>> > (We'd want the x86_vector_domain to actually have an MSI compose
>>&
On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
> On Thu, Oct 08 2020 at 17:08, David Woodhouse wrote:
> > On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
> >
> > (We'd want the x86_vector_domain to actually have an MSI compose
> > function in the
On Thu, 2020-10-08 at 11:12 +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2020 at 01:20:44PM +0100, David Woodhouse wrote:
> > @@ -1861,7 +1863,8 @@ static void ioapic_configure_entry(struct irq_data
> > *irqd)
> > * ioapic chip to verify that.
> > */
>
On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
>
> In fact I'm really tempted to make Linux's io_apic.c just use
> irq_chip_compose_msi_msg() and swizzle the bits out of the message
> identically for IR and non-IR alike (modulo the pin hack), and delete
> the IR_IO_A
On Thu, 2020-10-08 at 13:54 +0200, Thomas Gleixner wrote:
> On Wed, Oct 07 2020 at 13:20, David Woodhouse wrote:
> >
> > + /*
> > +* If the hypervisor supports extended destination ID in IOAPIC
> > +* and MSI, that increases the maximum APIC ID that can
On Thu, 2020-10-08 at 14:05 +0200, Thomas Gleixner wrote:
> Why MSI_EXT_DEST_ID? It's enabling that for MSI and IO/APIC. The
> underlying mechanism might be the same, but APIC_EXT_DEST_ID is more
> general and then you might also make the explanation of that bit
> match the changelog.
It's
On Wed, 2020-09-30 at 20:32 +0200, Thomas Gleixner wrote:
> On Tue, Sep 15 2020 at 16:27, Dave Jiang wrote:
> > @@ -1303,9 +1303,10 @@ static void intel_irq_remapping_prepare_irte(struct
> > intel_ir_data *data,
> > case X86_IRQ_ALLOC_TYPE_HPET:
> > case X86_IRQ_ALLOC_TYPE_PCI_MSI:
> >
From: David Woodhouse
This allows the host to indicate that IOAPIC and MSI emulation supports
15-bit destination IDs, allowing up to 32768 CPUs without interrupt
remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
From: David Woodhouse
Currently, Linux as a hypervisor guest will enable x2apic only if there
are no CPUs present at boot time with an APIC ID above 255.
Hotplugging a CPU later with a higher APIC ID would result in a CPU
which cannot be targeted by external interrupts.
Add a filter
From: David Woodhouse
The Intel IOMMU has an MSI-like configuration for its interrupt, but
it isn't really MSI. So it gets to abuse the high 32 bits of the address,
and puts the high 24 bits of the extended APIC ID there.
This isn't something that can be used in the general case for real MSIs
From: David Woodhouse
The IOAPIC Redirection Table Entries contain an 8-bit Extended
Destination ID field which maps to bits 11-4 of the MSI address.
The lowest bit is used to indicate remappable format, when interrupt
remapping is in use. A hypervisor can use the other 7 bits to permit
guests
/ for qemu.
David Woodhouse (5):
x86/apic: Fix x2apic enablement without interrupt remapping
x86/msi: Only use high bits of MSI address for DMAR unit
x86/ioapic: Handle Extended Destination ID field in RTE
x86/apic: Support 15 bits of APIC ID in IOAPIC/MSI where available
From: David Woodhouse
Some hypervisors can allow the guest to use the Extended Destination ID
field in the IOAPIC RTE and MSI address to address up to 32768 CPUs.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/include/asm/x86_init.h | 2 ++
arch/x86
On Tue, 2020-10-06 at 09:37 +0100, David Woodhouse wrote:
> On Tue, 2020-10-06 at 06:47 +, Dexuan Cui wrote:
> > Hi all,
> > I'm running a single-CPU Linux VM on Hyper-V. The Linux kernel is v5.9-rc7
> > and I have CONFIG_NR_CPUS=256.
> >
> > The Hyper-V
On Tue, 2020-10-06 at 06:47 +, Dexuan Cui wrote:
> Hi all,
> I'm running a single-CPU Linux VM on Hyper-V. The Linux kernel is v5.9-rc7
> and I have CONFIG_NR_CPUS=256.
>
> The Hyper-V Host (Version 17763-10.0-1-0.1457) provides a guest firmware,
> which always reports 128 Local APIC entries
From: David Woodhouse
If the BIOS has enabled x2apic mode, then leave it enabled and don't
fall back to xapic just because some CPUs can't be targeted.
Previously, if there were CPUs with APIC IDs > 255, the kernel would
disable x2apic and fall back to xapic. And then not use the additio
On 15 September 2020 16:08:55 BST, Phil Chang wrote:
>Allowing the DMA32 zone be configurable in ARM64 but at most 4Gb.
I don't think 4,000,000 bits is a particularly sensible limit.
Perhaps you meant bytes, and perhaps you meant 4*1024*1024? That would be "4
GiB".
--
Sent from my Android
On Mon, 2020-09-14 at 17:23 +0200, Lukas Bulwahn wrote:
> > # /usr/lib/mailman/bin/config_list -o- linux-mediatek | grep -B5
> > ^generic_nonmember_action
> > # legal values are:
> > #0 = "Accept"
> > #1 = "Hold"
> > #2 = "Reject"
> > #3 = "Discard"
> > generic_nonmember_action =
On Mon, 2020-09-14 at 16:57 +0200, Lukas Bulwahn wrote:
> Well, I am happy to send any PATCH v2. I guess we, you, David, Matthias
> and I, now just need to determine if the list is moderated or not.
It really isn't.
# /usr/lib/mailman/bin/config_list -o- linux-mediatek | grep -B5
On Mon, 2020-09-14 at 16:01 +0200, Lukas Bulwahn wrote:
> > > I am not subscribed to linux-mediatek. When I sent an email to the list,
> > > it showed up really seconds later in the lore.kernel.org of the
> > > linux-mediatek public-inbox repository. So, either it was delivered
> > > quickly as it
On Thu, 2020-09-03 at 13:30 -0700, Sami Tolvanen wrote:
> With LTO, the compiler doesn't necessarily obey the link order for
> initcalls, and initcall variables need globally unique names to avoid
> collisions at link time.
>
> This change exports __KBUILD_MODNAME and adds the initcall_id()
On Tue, 2020-08-11 at 10:41 +0200, Frank Wunderlich wrote:
> Afair there is only mt7623a and mt7623n. Mt7623a uses mt7623.dtsi as
> common part. These 2 soc are released 5 years ago...and only these 2
> from that family).
>
>
On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote:
> I would like to put all device in mt7623.dtsi with some device's
> status is "disabled" and change its status in platform dtsi.
> I would like to see all device in mt7623.dtsi because of its name. If
> you move some device to platform dtsi,
On Wed, 2020-08-05 at 10:49 +0200, Frank Wunderlich wrote:
> > Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr
> > Von: "David Woodhouse"
> > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> > > mt7623.dtsi => mt7623a.dtsi =&g
From: David Woodhouse
Based on a patch in OpenWrt from Kristian Evensen
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/mt7623a-unielec-u7623-emmc.dts | 347 ++
2 files changed, 348 insertions(+)
create mode 100644
From: David Woodhouse
The MT7623A doesn't have a GPU; add it only for MT7623N boards.
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623.dtsi | 24 -
arch/arm/boot/dts/mt7623n-ba
From: David Woodhouse
This isn't needed in dtsi files.
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623a.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8ad9..a96075206cce 100644
--- a/arch/arm
On Wed, 2020-08-05 at 09:27 +0200, Frank Wunderlich wrote:
> or should we split dtsi to have a common part (mt7623.dtsi), and one for
> soc (mt7623n.dtsi/mt7623a.dtsi)?
>
> mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not
On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > Von: "David Woodhouse"
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
>
On Tue, 2020-08-04 at 18:55 +0200, Frank Wunderlich wrote:
> From: Ryder Lee
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu
> Signed-off-by: chunhui dai
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Ryder Lee
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank
From: René van Dorst
Modify mtk_gmac0_rgmii_adjust() so it can always be called.
mtk_gmac0_rgmii_adjust() sets-up the TRGMII clocks.
Signed-off-by: René van Dorst
Signed-off-By: David Woodhouse
Tested-by: Frank Wunderlich
---
On Mon, 2020-04-06 at 15:25 +0200, Frank Wunderlich wrote:
> h
The machine hosting lists.infradead.org and git.infradead.org suffered
a complete disk failure over the weekend; sadly the last backup of the
mailman config was fairly old (May 2018) so the subscriber lists and
archives have been reset to that date, but the lists should be running
again.
I've
On Wed, 2020-06-03 at 16:05 +0200, Arnd Bergmann wrote:
> I don't know if you can just run 'make headers_install' without configuring
> first, or if that is something that can be easily changed if it doesn't
> already
> work.
It would be kind of wrong for the exported ABI headers to depend on
On Wed, 2020-04-29 at 05:20 +, Williams, Dan J wrote:
> The *patch* is not trying to overrule NVME, and the best I can say is
> that the Intel Linux team was not in the loop when this was being
> decided between the platform BIOS implemenation and whomever thought
> they could just publish
On Mon, 2020-05-11 at 13:01 -0700, Linus Torvalds wrote:
> On Mon, May 11, 2020 at 12:52 PM Nick Desaulniers
> wrote:
> >
> > Interesting approach. Researching __builtin_choose_expr, it looks
> > like it was cited as prior art for C11's _Generic keyword.
>
> Well, the thing that made me think
On Mon, 2019-06-24 at 08:16 +0200, Christoph Hellwig wrote:
> On Thu, Jun 20, 2019 at 04:11:26PM +0800, Daniel Drake wrote:
> > On Thu, Jun 20, 2019 at 2:11 PM Christoph Hellwig wrote:
> > > The Linux NVMe driver will deal with NVMe as specified plus whatever
> > > minor tweaks we'll need for
On Thu, 2019-06-06 at 09:55 +0200, Rolf Eike Beer wrote:
> +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null ||
> -lcrypto)
That's going to run:
$ pkg-config --libs libcrypto || -lcrypto
If libcrypto.pc isn't there, it's going to get this:
-lcrypto: command not found
I
On Wed, 2019-06-05 at 14:50 +0200, Greg KH wrote:
> On Wed, Jun 05, 2019 at 01:52:01PM +0300, Talel Shenhar wrote:
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-al-fic.c
> > @@ -0,0 +1,289 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/**
>
> No need for kernel-doc format style here.
>
> >
On Tue, 2019-05-07 at 09:07 -0500, Bjorn Helgaas wrote:
> On Tue, May 07, 2019 at 02:02:34PM +0100, David Woodhouse wrote:
> > On Tue, 2019-05-07 at 07:49 -0500, Bjorn Helgaas wrote:
> > > No good reason; I just screwed up. Should be fixed in v5.2 (and marked
>
On Tue, 2019-05-07 at 07:49 -0500, Bjorn Helgaas wrote:
> No good reason; I just screwed up. Should be fixed in v5.2 (and marked for
> stable):
>
> https://lore.kernel.org/linux-pci/20190318160718.10925-1-jean-philippe.bruc...@arm.com
Aha, thanks. And I see 'dwc: Use
On Fri, 2018-03-09 at 13:00 -0600, Bjorn Helgaas wrote:
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -540,6 +540,16 @@ struct pci_host_bridge *pci_alloc_host_bridge(size_t
> priv)
> INIT_LIST_HEAD(>windows);
> bridge->dev.release = pci_release_host_bridge_dev;
>
On Mon, 2018-05-28 at 11:11 +0530, Srinath Mannam wrote:
> From: Pramod Kumar
>
> This commit adds stingray thermal driver to monitor six
> thermal zones temperature and trips at critical temperature.
This matches an ACPI "BRCM0500" device but then calls
devm_thermal_zone_of_sensor_register(),
On Wed, 2019-04-24 at 13:58 -0700, Sagi Grimberg wrote:
> > It isn't that the media is slow; the max timeout is based on the SLA
> > for certain classes of "fabric" outages. Linux copes *really* badly
> > with I/O errors, and if we can make the timeout last long enough to
> > cover the switch
On Wed, 2019-04-24 at 14:07 -0600, Keith Busch wrote:
> On Wed, Apr 24, 2019 at 09:55:16AM -0700, Sagi Grimberg wrote:
> >
> > > As different nvme controllers are connect via different fabrics, some
> > > require
> > > different timeout settings than others. This series implements
> > >
an AMZN0001 device.
> > - Adding a new entry in the MCFG quirk array
> >
> > Co-developed-by: Vladimir Aerov
> > Signed-off-by: Jonathan Chocron
> > Signed-off-by: Vladimir Aerov
> > Reviewed-by: David Woodhouse
>
> Late to the party, sorry :-) T
On Sun, 2019-03-31 at 18:16 +0530, Mukesh Ojha wrote:
> On 3/31/2019 6:04 PM, Hanna Hawa wrote:
> > Update driver license to be in-line with Linux conventions.
> >
> > Signed-off-by: Hanna Hawa
> > ---
> > drivers/irqchip/irq-alpine-msi.c | 5 +
> > 1 file changed, 1 insertion(+), 4
On Fri, 2019-03-29 at 10:44 +0100, Christoph Hellwig wrote:
> On Fri, Mar 29, 2019 at 09:39:20AM +, Maximilian Heyne wrote:
> > Some NVMe devices require specific io and admin timeouts that are
> > different from the default, for instance local vs. remote storage.
> >
> > This patch adds
On Wed, 2019-03-27 at 11:39 +, Lorenzo Pieralisi wrote:
> I just want to keep MCFG ECAM quirks as simple as possible, code as it
> stands is horrible enough and I wish I could remove the mechanism in
> the future rather than adding more to it, hopefully we are getting
> there.
Obviously I
On Wed, 2019-03-27 at 11:20 +, Lorenzo Pieralisi wrote:
> On Wed, Mar 27, 2019 at 09:52:15AM +0000, David Woodhouse wrote:
> > On Tue, 2019-03-26 at 15:58 +, Lorenzo Pieralisi wrote:
> > > > We did that internally. You really don't want me telling engineers to
>
On Tue, 2019-03-26 at 12:17 +, Lorenzo Pieralisi wrote:
> This code is basically identical to (apart from the string matching
> the DBI resource)
>
> drivers/pci/controller/pcie-hisi.c
>
> because, as you said, that's a DW quirk that is really not
> platform specific AFAICS.
>
> Not that I
On Tue, 2019-03-26 at 15:58 +, Lorenzo Pieralisi wrote:
> > We did that internally. You really don't want me telling engineers to
> > post to the list *first* without running things by me to get the basics
> > right. Not to start with, at least.
>
> Hi David,
>
> I am obviously in favour of
- Adding a new entry in the mcfg quirk array
> >
> > Co-developed-by: Vladimir Aerov
> > Signed-off-by: Jonathan Chocron
> > Signed-off-by: Vladimir Aerov
> > Reviewed-by: Benjamin Herrenschmidt
> > Reviewed-by: David Woodhouse
>
> Review tags should
On Mon, 2019-03-25 at 15:37 +0100, Daniel Borkmann wrote:
> On 03/25/2019 03:28 PM, David Woodhouse wrote:
> > On Mon, 2019-03-25 at 14:56 +0100, Daniel Borkmann wrote:
> > > More than 20 switch cases are not expected to be fast-path critical, but
> > > it would stil
On Mon, 2019-03-25 at 14:56 +0100, Daniel Borkmann wrote:
> More than 20 switch cases are not expected to be fast-path critical, but
> it would still be good to align with gcc behavior for versions < 8.4.0 in
> order to have consistency across supported gcc versions. vmlinux size is
> slightly
On Tue, 2019-02-26 at 11:48 +0100, Flavio Suligoi wrote:
> For the x86 machines a m25p80-compatible device have to be declared using
> an ACPI table (which can be directly a part of the BIOS ACPI tables).
>
> In this case it is necessary to add the device in the "of_device_id" structure
> list,
On Thu, 2019-02-28 at 03:12 -0800, tip-bot for Daniel Borkmann wrote:
> Commit-ID: ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Gitweb:
> https://git.kernel.org/tip/ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Author: Daniel Borkmann
> AuthorDate: Thu, 21 Feb 2019 23:19:41 +0100
>
On Thu, 2019-02-07 at 13:09 -0800, Raj, Ashok wrote:
> You are right.. they are completely orthogonal. We just don't have
> a way to handle the page-requests for request without PASID's.
>
> There are some of the vIOMMU work to pass the PRI to who owns
> the device, and we can certainly relax it
On Thu, 2019-02-07 at 10:44 -0800, sathyanarayanan.kuppusw...@linux.intel.com
wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Intel IOMMU Page Request Services (PRS) only works with devices which
> supports/uses PASID. So enable PRI only if the device also enables
> PASID support. For more
On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote:
> > I wonder if we can declare the common case functions as 'weak' so that
> > the link failures don't happen when they're absent.
>
> I experimented a previous version with alias. I avoided weak alias
> usage, because I [mis?]understood not
On Wed, 2018-12-05 at 19:13 +0100, Paolo Abeni wrote:
> +/*
> + * We can use INDIRECT_CALL_$NR for ipv6 related functions only if ipv6 is
> + * builtin, this macro simplify dealing with indirect calls with only
> ipv4/ipv6
> + * alternatives
> + */
> +#if IS_BUILTIN(CONFIG_IPV6)
> +#define
On Thu, 2018-11-22 at 16:45 +0100, Rolf Eike Beer wrote:
> -HOSTLDLIBS_sign-file = -lcrypto
> -HOSTLDLIBS_extract-cert = -lcrypto
> +HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null
> || -lcrypto)
> +HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2>
On Thu, 2018-11-22 at 16:45 +0100, Rolf Eike Beer wrote:
> -HOSTLDLIBS_sign-file = -lcrypto
> -HOSTLDLIBS_extract-cert = -lcrypto
> +HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null
> || -lcrypto)
> +HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2>
On Mon, 2018-11-12 at 15:40 -0800, Daniel Walker wrote:
> On Mon, Nov 12, 2018 at 03:11:32PM -0800, David Woodhouse wrote:
> > On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> > > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
> >
On Mon, 2018-11-12 at 15:40 -0800, Daniel Walker wrote:
> On Mon, Nov 12, 2018 at 03:11:32PM -0800, David Woodhouse wrote:
> > On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> > > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
> >
On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
Hm, how many decades will it take for the 'mtdblock' thing to die?
JFFS2 doesn't use block devices :)
> It looks like the took slightly more than twice as long to mount.
On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
Hm, how many decades will it take for the 'mtdblock' thing to die?
JFFS2 doesn't use block devices :)
> It looks like the took slightly more than twice as long to mount.
On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> But we can hypothesise and handwave about it until the cows come home;
> I'd like to see a real test of whether it actually makes a difference
> that we care about.
>
> If it does, one option might be to just
On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> But we can hypothesise and handwave about it until the cows come home;
> I'd like to see a real test of whether it actually makes a difference
> that we care about.
>
> If it does, one option might be to just
On Wed, 2018-11-07 at 19:14 +0100, Richard Weinberger wrote:
> On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> > I had tried to use configs to start with via the following patch however I
> > was advised to have a mount option:
> >
On Wed, 2018-11-07 at 19:14 +0100, Richard Weinberger wrote:
> On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> > I had tried to use configs to start with via the following patch however I
> > was advised to have a mount option:
> >
> On Wed, Nov 07, 2018 at 04:12:14PM -0000, David Woodhouse wrote:
>>
>> > Yes, this may slow things down. I am not sure I agree with the impl.
>> > either.
>> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
>> to
>>
> On Wed, Nov 07, 2018 at 04:12:14PM -0000, David Woodhouse wrote:
>>
>> > Yes, this may slow things down. I am not sure I agree with the impl.
>> > either.
>> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
>> to
>>
> Yes, this may slow things down. I am not sure I agree with the impl.
> either.
> Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> a func. with the correct endian?
On x86 retpoline would make that quite slow.
--
dwmw2
> Yes, this may slow things down. I am not sure I agree with the impl.
> either.
> Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> a func. with the correct endian?
On x86 retpoline would make that quite slow.
--
dwmw2
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
> This patch allows the endianness of the JFSS2 filesystem to be
> specified by mount option 'force_endian=big|little|native'. If
> endianness is not specified, it defaults to 'native' endianness
> thus retaining the existing behavior.
>
>
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
> This patch allows the endianness of the JFSS2 filesystem to be
> specified by mount option 'force_endian=big|little|native'. If
> endianness is not specified, it defaults to 'native' endianness
> thus retaining the existing behavior.
>
>
On Wed, 2018-10-10 at 13:34 +0300, Talel Shenhar wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >
> > > The dw spi controller has an auto-deselect of Chip-Select, in
> > > case there is
> > > no data inside the Tx FIFO. While working on platforms with
> > > Alpine
On Wed, 2018-10-10 at 13:34 +0300, Talel Shenhar wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >
> > > The dw spi controller has an auto-deselect of Chip-Select, in
> > > case there is
> > > no data inside the Tx FIFO. While working on platforms with
> > > Alpine
On Thu, 2018-03-01 at 16:22 +0200, Or Idgar wrote:
> +
> +static const struct acpi_device_id vmgenid_ids[] = {
> + {"QEMUVGID", 0},
> + {"", 0},
> +};
> +
This is wrong. You're supposed to match on the _CID "VM_Gen_Counter".
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2018-03-01 at 16:22 +0200, Or Idgar wrote:
> +
> +static const struct acpi_device_id vmgenid_ids[] = {
> + {"QEMUVGID", 0},
> + {"", 0},
> +};
> +
This is wrong. You're supposed to match on the _CID "VM_Gen_Counter".
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > > > Yes. It shouldn't be much code, either. You still have to check for
> > > > X.509
> > > > DER since the kernel currently supports that.
> > >
> > > For reasons of backward compatibility, correct? The kernel also
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > > > Yes. It shouldn't be much code, either. You still have to check for
> > > > X.509
> > > > DER since the kernel currently supports that.
> > >
> > > For reasons of backward compatibility, correct? The kernel also
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote:
> Hi David,
>
> On 09/18/2018 10:50 AM, David Howells wrote:
> > Denis Kenzior wrote:
> >
> > > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
> > > -out /tmp/privkey.2048.der
> >
> > You can
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote:
> Hi David,
>
> On 09/18/2018 10:50 AM, David Howells wrote:
> > Denis Kenzior wrote:
> >
> > > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \
> > > -out /tmp/privkey.2048.der
> >
> > You can
On Tue, 2018-09-18 at 16:02 +0100, David Howells wrote:
> It's meant to be stripping off the PEM wrapper and outputting the DER, but see
> below.
>
> > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I
> > get no output at all.
>
> I lost a bit from the cover note. It
On Tue, 2018-09-18 at 16:02 +0100, David Howells wrote:
> It's meant to be stripping off the PEM wrapper and outputting the DER, but see
> below.
>
> > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I
> > get no output at all.
>
> I lost a bit from the cover note. It
On Tue, 2018-09-18 at 15:03 +0200, Peter Zijlstra wrote:
> > > In original code, it will go to "call *%[thunk_target]\n" while
> > > we have set SPECTRE_V2_RETPOLINE_MINIMAL or
> > > SPECTRE_V2_RETPOLINE_MINIMAL_AMD. Is this expected?
> >
> > Yes, that is exactly right -- it does that with or
On Tue, 2018-09-18 at 15:03 +0200, Peter Zijlstra wrote:
> > > In original code, it will go to "call *%[thunk_target]\n" while
> > > we have set SPECTRE_V2_RETPOLINE_MINIMAL or
> > > SPECTRE_V2_RETPOLINE_MINIMAL_AMD. Is this expected?
> >
> > Yes, that is exactly right -- it does that with or
On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote:
> Marcel Holtmann wrote:
>
> >
> > so I have reviewed and tested this code. In addition, we have test cases for
> > it in ELL (embedded linux library).
>
> I wonder if there's any practical way to add a test for this to the keyutils
>
201 - 300 of 4023 matches
Mail list logo
