* Re: CFLAGS overridden by distribution build system
From: William Roberts @ 2020-05-29 17:15 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Laurent Bigonville, SElinux list
In-Reply-To: <CAEjxPJ5weFXrFpyjWdW7D4tgOnK+jHMyD37Zb4JFEzDt1rQ8Dw@mail.gmail.com>
On Fri, May 29, 2020 at 11:40 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 12:05 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Fri, May 29, 2020 at 8:31 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Sat, May 23, 2020 at 11:59 AM William Roberts
> > > <bill.c.roberts@gmail.com> wrote:
> > > >
> > > > On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > The current build system of the userspace is setting a lot of CFLAGS,
> > > > > but most of these are overridden by the distributions when building.
> > > > >
> > > > > Today I received a bug report[0] from Christian Göttsche asking me to
> > > > > set -fno-semantic-interposition again in libsepol. I see also the same
> > > > > flag and also a lot of others set in libselinux and libsemanage build
> > > > > system.
> > > >
> > > > Why would it be again? The old DSO design made that option impotent.
> > > > Clang does it by default.
> > > >
> > > > >
> > > > > For what I understand some of these are just needed for code quality
> > > > > (-W) and could be controlled by distributions but others might actually
> > > > > need to be always set (-f?).
> > > >
> > > > If you look at the Makefiles overall in all the projects, you'll see hardening
> > > > flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
> > > > they all get overridden by build time CFLAGS if you want.
> > > >
> > > > >
> > > > > Shouldn't the flags that always need to be set (which ones?) be moved to
> > > > > a "override CFLAGS" directive to avoid these to be unset by distributions?
> > > >
> > > > If you we're cleaver with CFLAGS before, you could acually circumvent
> > > > the buildtime
> > > > DSO stuff. While i'm not opposed to adding it to immutable flag, if
> > > > you're setting
> > > > CFLAGS, you're on your own. At least with the current design.
> > > >
> > > > I have no issues with adding it to override, but we would have to
> > > > overhaul a bunch
> > > > of them and make them consistent.
> > >
> > > I'm inclined to agree with Laurent here - we should always set this
> > > flag in order to preserve the same behavior prior to the patches that
> > > removed hidden_def/hidden_proto and switched to relying on this
> > > instead.
> >
> > Theirs a lot of features that rely on particular cflags, consider hardening
> > options. A lot of the warnings/error stuff is not just a code hygiene, but also
> > spotting potential issues that could arise as security issues. If one starts
> > tinkering with cflags, you can really change the code quite a bit. This is why
> > some places only approve sanctioned builds of crypto libraries.
>
> I think the difference here is that we made a change in the source
> code (hidden_def/hidden_proto removal) that requires use of
> -fno-semantic-interposition to preserve existing behavior.
>
> > But one of the things to consider is that for clang builds, clang
> > doesn't support
> > this option, so we would need to move the compiler checking code into each
> > projects root makefile and ensure any consuming subordinate leafs add a
> > default, or move it to the global makefile and make sure each leaf that needs it
> > has a default.
>
> I think clang does support it now? https://reviews.llvm.org/D72724
Yeah but that bug is all 2020 stuff. It is in the clang-10 release. I
verified that
with a local build from here:
- https://apt.llvm.org/
So anything sub clang-10 won't support it, do you want to tie us to that
new of a clang?
^ permalink raw reply
* Re: [PATCH] cw1200: Remove local sdio VENDOR and DEVICE id definitions
From: Kalle Valo @ 2020-05-29 17:15 UTC (permalink / raw)
To: Pali Rohár
Cc: Solomon Peachy, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20200520125410.31757-1-pali@kernel.org>
Pali Rohár <pali@kernel.org> wrote:
> They are already present in linux/mmc/sdio_ids.h.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
83cee4e625f8 cw1200: Remove local sdio VENDOR and DEVICE id definitions
--
https://patchwork.kernel.org/patch/11560329/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* External sysroots?
From: rich.tollerton @ 2020-05-29 17:15 UTC (permalink / raw)
To: openembedded-core
Suppose that I want to cut a meta-toolchain build against a sysroot
sourced from a different Linux distribution. (Obviously I would be
responsible for ensuring that all required package dependencies exist in
the sysroot.) In other words... like an external toolchain, but
inverted. The purpose being to apply OE's toolchain infrastructure to
other distros.
In principle, could this be effected by e.g. liberal use of
ASSUME_PROVIDED and by populating the target sysroot by hand? Or is
there another way to do this in principle? Has anybody ever tried
something like this before?
^ permalink raw reply
* Re: [virtio-comment] [PATCH v4 1/3] content: Document balloon feature page poison
From: David Hildenbrand @ 2020-05-29 17:15 UTC (permalink / raw)
To: Alexander Duyck
Cc: Michael S. Tsirkin, Cornelia Huck, virtio-comment, virtio-dev,
Wang, Wei W
In-Reply-To: <CAKgT0UcXr5MzeCRxBpf-+DCXDF3QHT-c21msQOU49Mygv5gmWg@mail.gmail.com>
On 29.05.20 18:57, Alexander Duyck wrote:
> On Fri, May 29, 2020 at 1:13 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 27.05.20 06:06, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> Page poison provides a way for the guest to notify the host that it is
>>> initializing or poisoning freed pages with some specific poison value. As a
>>> result of this we can infer a couple traits about the guest:
>>>
>>> 1. Free pages will contain a specific pattern within the guest.
>>> 2. Modifying free pages from this value may cause an error in the guest.
>>> 3. Pages will be immediately written to by the driver when deflated.
>>>
>>> There are currently no existing features that make use of this data. In the
>>> upcoming feature free page reporting we will need to make use of this to
>>> identify if we can evict pages from the guest without causing data
>>> corruption.
>>>
>>> Add documentation for the page poison feature describing the basic
>>> functionality and requirements.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>> conformance.tex | 2 ++
>>> content.tex | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++----
>>> 2 files changed, 57 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/conformance.tex b/conformance.tex
>>> index b6fdec090383..4ed9d62e8088 100644
>>> --- a/conformance.tex
>>> +++ b/conformance.tex
>>> @@ -149,6 +149,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \item \ref{drivernormative:Device Types / Memory Balloon Device / Feature bits}
>>> \item \ref{drivernormative:Device Types / Memory Balloon Device / Device Operation}
>>> \item \ref{drivernormative:Device Types / Memory Balloon Device / Device Operation / Memory Statistics}
>>> +\item \ref{drivernormative:Device Types / Memory Balloon Device / Device Operation / Page Poison}
>>> \end{itemize}
>>>
>>> \conformance{\subsection}{SCSI Host Driver Conformance}\label{sec:Conformance / Driver Conformance / SCSI Host Driver Conformance}
>>> @@ -331,6 +332,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \item \ref{devicenormative:Device Types / Memory Balloon Device / Feature bits}
>>> \item \ref{devicenormative:Device Types / Memory Balloon Device / Device Operation}
>>> \item \ref{devicenormative:Device Types / Memory Balloon Device / Device Operation / Memory Statistics}
>>> +\item \ref{devicenormative:Device Types / Memory Balloon Device / Device Operation / Page Poison}
>>> \end{itemize}
>>>
>>> \conformance{\subsection}{SCSI Host Device Conformance}\label{sec:Conformance / Device Conformance / SCSI Host Device Conformance}
>>> diff --git a/content.tex b/content.tex
>>> index 91735e3eb018..4a0ab90260ff 100644
>>> --- a/content.tex
>>> +++ b/content.tex
>>> @@ -5019,6 +5019,9 @@ \subsection{Feature bits}\label{sec:Device Types / Memory Balloon Device / Featu
>>> memory statistics is present.
>>> \item[VIRTIO_BALLOON_F_DEFLATE_ON_OOM (2) ] Deflate balloon on
>>> guest out of memory condition.
>>> +\item[ VIRTIO_BALLOON_F_PAGE_POISON(4) ] A hint to the device, that the driver
>>> + will immediately write \field{poison_val} to pages after deflating them.
>>> + Configuration field \field{poison_val} is valid.
>>>
>>
>> Here we have "that the driver will immediately" ...
>>
>> But we never document that in form of a normative statement (e.g., "The
>> driver MUST initialize pages with \field{poison_val} after deflating").
>
> I'm pretty sure we did document that. In the normative statement for
> the driver below we have:
> +The driver MUST initialize the deflated pages with \field{poison_val} when
> +they are reused by the driver.
>
Doh! I think I missed that somehow
Reviewed-by: David Hildenbrand <david@redhat.com>
Thanks!
--
Thanks,
David / dhildenb
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
From: Rob Herring @ 2020-05-29 17:14 UTC (permalink / raw)
To: Wan Ahmad Zainie
Cc: kishon, vkoul, linux-kernel, devicetree, andriy.shevchenko,
adrian.hunter
In-Reply-To: <20200526050452.8837-2-wan.ahmad.zainie.wan.mohamad@intel.com>
On Tue, May 26, 2020 at 01:04:51PM +0800, Wan Ahmad Zainie wrote:
> Binding description for Intel Keem Bay eMMC PHY.
>
> Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
> ---
> .../bindings/phy/intel,keembay-emmc-phy.yaml | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> new file mode 100644
> index 000000000000..d3e0f169eb0a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2020 Intel Corporation
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-phy.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Intel Keem Bay eMMC PHY bindings
> +
> +maintainers:
> + - Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
> +
> +properties:
> + compatible:
> + const: intel,keembay-emmc-phy
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + items:
> + - const: emmcclk
> +
> + "#phy-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + phy@20290000 {
> + compatible = "intel,keembay-emmc-phy";
> + reg = <0x0 0x20290000 0x0 0x54>;
Examples expect a single cell for address and size.
> + clocks = <&emmc>;
> + clock-names = "emmcclk";
> + #phy-cells = <0>;
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 1/2] b43: Fix connection problem with WPA3
From: Kalle Valo @ 2020-05-29 17:14 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Rui Salvaterra, Stable
In-Reply-To: <20200526155909.5807-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Since the driver was first introduced into the kernel, it has only
> handled the ciphers associated with WEP, WPA, and WPA2. It fails with
> WPA3 even though mac80211 can handle those additional ciphers in software,
> b43 did not report that it could handle them. By setting MFP_CAPABLE using
> ieee80211_set_hw(), the problem is fixed.
>
> With this change, b43 will handle the ciphers it knows in hardware,
> and let mac80211 handle the others in software. It is not necessary to
> use the module parameter NOHWCRYPT to turn hardware encryption off.
> Although this change essentially eliminates that module parameter,
> I am choosing to keep it for cases where the hardware is broken,
> and software encryption is required for all ciphers.
>
> Reported-and-tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
2 patches applied to wireless-drivers-next.git, thanks.
75d057bda1fb b43: Fix connection problem with WPA3
6a29d134c04a b43_legacy: Fix connection problem with WPA3
--
https://patchwork.kernel.org/patch/11570765/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: rng: document Silex Insight BA431 hwrng
From: Rob Herring @ 2020-05-29 17:13 UTC (permalink / raw)
To: Olivier Sobrie
Cc: linux-crypto, linux-kernel, sebastien.rabou, Herbert Xu,
devicetree, Waleed Ziad, Rob Herring, Matt Mackall, Arnd Bergmann,
Greg Kroah-Hartman
In-Reply-To: <20200525195606.2941649-3-olivier.sobrie@silexinsight.com>
On Mon, 25 May 2020 21:56:05 +0200, Olivier Sobrie wrote:
> This patch documents the device tree bindings of the BA431 hardware
> random number generator.
>
> This IP is for instance present in the Viper OEM boards sold by Silex
> Insight.
>
> Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> ---
> .../bindings/rng/silex-insight,ba431-rng.yaml | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
From: Eric Biggers @ 2020-05-29 17:13 UTC (permalink / raw)
To: Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
In-Reply-To: <40600d42-dfa9-b60c-6ce8-0eda6bdf7ddf@linaro.org>
On Fri, May 29, 2020 at 11:54:18AM -0400, Thara Gopinath wrote:
> On 5/7/20 2:08 PM, Eric Biggers wrote:
> > On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> > > Hi Thara,
> > >
> > > On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> > > >
> > > >
> > > > On 5/1/20 12:51 AM, Eric Biggers wrote:
> > > > > From: Eric Biggers <ebiggers@google.com>
> > > > >
> > > > > Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
> > > > >
> > > > > The standards-compliant parts, such as querying the crypto capabilities
> > > > > and enabling crypto for individual UFS requests, are already handled by
> > > > > ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> > > > > However, ICE requires vendor-specific init, enable, and resume logic,
> > > > > and it requires that keys be programmed and evicted by vendor-specific
> > > > > SMC calls. Make the ufs-qcom driver handle these details.
> > > > >
> > > > > I tested this on Dragonboard 845c, which is a publicly available
> > > > > development board that uses the Snapdragon 845 SoC and runs the upstream
> > > > > Linux kernel. This is the same SoC used in the Pixel 3 and Pixel 3 XL
> > > > > phones. This testing included (among other things) verifying that the
> > > > > expected ciphertext was produced, both manually using ext4 encryption
> > > > > and automatically using a block layer self-test I've written.
> > > > Hello Eric,
> > > >
> > > > I am interested in testing out this series on 845, 855 and if possile on 865
> > > > platforms. Can you give me some more details about your testing please.
> > > >
> > >
> > > Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> > >
> > > A basic manual test would be:
> > >
> > > 1. Build a kernel with:
> > >
> > > CONFIG_BLK_INLINE_ENCRYPTION=y
> > > CONFIG_FS_ENCRYPTION=y
> > > CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> >
> > Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
>
> Hi Eric,
>
> I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the dts
> file entries for 8150 and 8250).
>
> I also ran OsBench test case createfiles[1] on the above platforms.
> Following are the results on a non encrypted and encrypted directory on the
> same file system(lower the number better)
>
> 8250-MTP 8150-MTP DB845
>
> nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
> encrypt_dir(us) 70.0214426 37.5411254 92.3818296
>
>
>
> 1. https://github.com/mbitsnbites/osbench/blob/master/README.md
>
Great, thanks for testing.
Note that the benchmark you ran (creating many small files, then deleting them)
mostly tests the performance of filenames encryption and directory operations,
not file contents encryption. Inline encryption is only used for file contents.
In fact, since that benchmark doesn't sync the files before deleting them, there
is no guarantee that any file contents are actually written to disk, and hence
no guarantee that inline encryption got used at all.
It would be more relevant to test the performance of reading/writing file data.
Also, did you try doing any correctness tests? (See what I suggested earlier.)
- Eric
^ permalink raw reply
* [PATCH 0/2] fuzz: Skip QTest serialization
From: Alexander Bulekov @ 2020-05-29 16:57 UTC (permalink / raw)
To: qemu-devel; +Cc: darren.kenny, bsd, f4bug, stefanha, Alexander Bulekov
In the same vein as Philippe's patch:
https://patchew.org/QEMU/20200528165303.1877-1-f4bug@amsat.org/
This uses linker trickery to wrap calls to libqtest functions and
directly call the corresponding read/write functions, rather than
relying on the ASCII-serialized QTest protocol.
Alexander Bulekov (2):
fuzz: skip QTest serialization
fuzz: Add support for logging QTest commands
tests/qtest/fuzz/Makefile.include | 21 +++
tests/qtest/fuzz/fuzz.c | 20 ++-
tests/qtest/fuzz/fuzz.h | 3 +
tests/qtest/fuzz/qtest_wrappers.c | 252 ++++++++++++++++++++++++++++++
4 files changed, 295 insertions(+), 1 deletion(-)
create mode 100644 tests/qtest/fuzz/qtest_wrappers.c
--
2.26.2
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Silex Insight vendor prefix
From: Rob Herring @ 2020-05-29 17:12 UTC (permalink / raw)
To: Olivier Sobrie
Cc: Greg Kroah-Hartman, linux-crypto, Waleed Ziad, Matt Mackall,
sebastien.rabou, Rob Herring, Arnd Bergmann, Herbert Xu,
linux-kernel, devicetree
In-Reply-To: <20200525195606.2941649-2-olivier.sobrie@silexinsight.com>
On Mon, 25 May 2020 21:56:04 +0200, Olivier Sobrie wrote:
> Silex Insight is a microelectronic company whose headquarter is located
> in Belgium.
> Web site of the company: https://www.silexinsight.com/
>
> Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 3/3] hwrng: ba431-rng: add support for BA431 hwrng
From: Rob Herring @ 2020-05-29 17:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olivier Sobrie, Matt Mackall, Herbert Xu, Greg Kroah-Hartman,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, DTML,
linux-kernel@vger.kernel.org, Waleed Ziad, sebastien.rabou
In-Reply-To: <CAK8P3a3=HoQZuBoqyFgyde1X7BRfcH-GFQpu=8acOi_JhVU99g@mail.gmail.com>
On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> <olivier.sobrie@silexinsight.com> wrote:
> >
> > Silex insight BA431 is an IP designed to generate random numbers that
> > can be integrated in various FPGA.
> > This driver adds support for it through the hwrng interface.
> >
> > This driver is used in Silex Insight Viper OEM boards.
> >
> > Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> > Signed-off-by: Waleed Ziad <waleed94ziad@gmail.com>
>
> The driver looks good to me.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> > drivers/char/hw_random/Kconfig | 10 ++
> > drivers/char/hw_random/Makefile | 1 +
> > drivers/char/hw_random/ba431-rng.c | 240 +++++++++++++++++++++++++++++
>
> I wonder if we should move drivers/char/hw_random to its own top-level drivers
> subsystem outside of drivers/char. It seems to be growing steadily and is larger
> than a lot of other subsystems with currently 34 drivers in there.
>
> Not your problem though.
>
> > + /* Wait until the state changed */
> > + for (i = 0; i < BA431_RESET_READ_STATUS_RETRIES; ++i) {
> > + state = ba431_trng_get_state(ba431);
> > + if (state >= BA431_STATE_STARTUP)
> > + break;
> > +
> > + udelay(BA431_RESET_READ_STATUS_INTERVAL);
> > + }
>
> Looking for something to improve, I noticed that this loop can take over
> a millisecond to time out, and it always runs in non-atomic context.
> It may be better to use usleep_range() than udelay().
Or better yet, use the register polling helpers.
Rob
^ permalink raw reply
* Re: [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others
From: Andy Lutomirski @ 2020-05-29 17:11 UTC (permalink / raw)
To: Daniel Kiper
Cc: dpsmith, alexander.burmashev, krystian.hebel, hpa,
michal.zygowski, grub-devel, x86, javierm, kanth.ghatraju,
ross.philipson, xen-devel, leif, trenchboot-devel, alec.brown,
mtottenh, konrad.wilk, phcoder, piotr.krol, ard.biesheuvel,
andrew.cooper3, linux-kernel, mjg59, eric.snowberg, pjones,
lukasz.hawrylko
In-Reply-To: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl>
> On May 29, 2020, at 4:30 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
> sanitization. Now I would like to take feedback from other folks too.
> So, please take a look and complain...
> In general we want to pass the messages produced by the bootloader to the OS
> kernel and finally to the userspace for further processing and analysis. Below
> is the description of the structures which will be used for this thing.
Is the intent for a human to read these, or to get them into the system log file, or are they intended to actually change the behavior of the system?
IOW, what is this for?
^ permalink raw reply
* Re: [PATCH] Revert "rtw88: no need to set registers for SDIO"
From: Kalle Valo @ 2020-05-29 17:11 UTC (permalink / raw)
To: yhchuang; +Cc: linux-wireless, kevlo
In-Reply-To: <20200520055350.23328-1-yhchuang@realtek.com>
<yhchuang@realtek.com> wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> This reverts commit 07d0f5534935e2daf63a4e1012af13d68e089fed.
>
> For rtw88 driver, the SDIO is going to be supported, so there is
> no need to remove the SDIO related power sequence settings. And
> while the power sequence parser will pass in the mask of the HCI,
> the SDIO part will not be used to set registers accordingly.
>
> Moreover, the power sequence table is released as a whole package,
> so the next time if we are going to update, the SDIO settings will
> be overwritten. So, revert this now.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
dba5a189bf61 Revert "rtw88: no need to set registers for SDIO"
--
https://patchwork.kernel.org/patch/11559339/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: PANIC: double fault in fixup_bad_iret
From: Peter Zijlstra @ 2020-05-29 17:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Dmitry Vyukov, syzbot, LKML, syzkaller-bugs, Ingo Molnar,
Borislav Petkov, the arch/x86 maintainers, Oleg Nesterov
In-Reply-To: <20200529160711.GC706460@hirez.programming.kicks-ass.net>
On Fri, May 29, 2020 at 06:07:11PM +0200, Peter Zijlstra wrote:
> Like with KCSAN, we should blanket kill KASAN/UBSAN and friends (at the
> very least in arch/x86/) until they get that function attribute stuff
> sorted.
Something like so.
---
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 00e378de8bc0..a90d32b87d7e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -1,6 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
# Unified Makefile for i386 and x86_64
+#
+# Until such a time that __no_kasan and __no_ubsan work as expected (and are
+# made part of noinstr), don't sanitize anything.
+#
+KASAN_SANITIZE := n
+UBSAN_SANITIZE := n
+KCOV_INSTRUMENT := n
+
# select defconfig based on actual architecture
ifeq ($(ARCH),x86)
ifeq ($(shell uname -m),x86_64)
^ permalink raw reply related
* [PATCH 2/2] MIPS: Expose Loongson CPUCFG availability via HWCAP
From: WANG Xuerui @ 2020-05-29 17:10 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: WANG Xuerui, linux-mips, Paul Burton, Jiaxun Yang, Huacai Chen
In-Reply-To: <20200529171000.8905-1-git@xen0n.name>
The point is to allow userspace to probe for CPUCFG without possibly
triggering invalid instructions. In addition to that, future Loongson
feature bits could all be stuffed into CPUCFG bit fields (or "leaves"
in x86-speak) if Loongson does not make mistakes, so ELF HWCAP bits are
conserved.
The other existing Loongson-specific HWCAP bits are, to my best
knowledge, unused, as
(1) they are fairly recent additions,
(2) Loongson never back-ported the patch into their kernel fork, and
(3) Loongson's existing installed base rarely upgrade, if ever;
However, they are still considered userspace ABI, hence unfortunately
unremovable. But at least we could stop adding new Loongson HWCAP bits
in the future.
Cc: Paul Burton <paulburton@kernel.org>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Huacai Chen <chenhc@lemote.com>
Signed-off-by: WANG Xuerui <git@xen0n.name>
---
arch/mips/include/uapi/asm/hwcap.h | 1 +
arch/mips/loongson64/cpucfg-emul.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/uapi/asm/hwcap.h b/arch/mips/include/uapi/asm/hwcap.h
index 1ade1daa4921..b7e02bdc1985 100644
--- a/arch/mips/include/uapi/asm/hwcap.h
+++ b/arch/mips/include/uapi/asm/hwcap.h
@@ -17,5 +17,6 @@
#define HWCAP_LOONGSON_MMI (1 << 11)
#define HWCAP_LOONGSON_EXT (1 << 12)
#define HWCAP_LOONGSON_EXT2 (1 << 13)
+#define HWCAP_LOONGSON_CPUCFG (1 << 14)
#endif /* _UAPI_ASM_HWCAP_H */
diff --git a/arch/mips/loongson64/cpucfg-emul.c b/arch/mips/loongson64/cpucfg-emul.c
index c16023a13379..ca75f07252df 100644
--- a/arch/mips/loongson64/cpucfg-emul.c
+++ b/arch/mips/loongson64/cpucfg-emul.c
@@ -4,6 +4,7 @@
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cpu-info.h>
+#include <asm/elf.h>
#include <loongson_regs.h>
#include <cpucfg-emul.h>
@@ -128,7 +129,7 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
/* CPUs with CPUCFG support don't need to synthesize anything. */
if (cpu_has_cfg())
- return;
+ goto have_cpucfg_now;
c->loongson3_cpucfg_data[0] = 0;
c->loongson3_cpucfg_data[1] = 0;
@@ -217,4 +218,10 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
patch_cpucfg_sel1(c);
patch_cpucfg_sel2(c);
patch_cpucfg_sel3(c);
+
+have_cpucfg_now:
+ /* We have usable CPUCFG now, emulated or not.
+ * Announce CPUCFG availability to userspace via hwcap.
+ */
+ elf_hwcap |= HWCAP_LOONGSON_CPUCFG;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: update qtnfmac maintainers
From: Kalle Valo @ 2020-05-29 17:10 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless, Sergey Matyukevich, Mikhail Karpenko,
Sergey Matyukevich, Igor Mitsyanko
In-Reply-To: <20200520130800.1902-1-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> I am leaving Quantenna, so I will no longer have access to firmware and
> hardware. Meanwhile I plan to participate in reviewing qtnfmac patches
> for a while until my firmware knowledge becomes completely obsolete.
> Adding myself as a reviewer using my personal email address.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Patch applied to wireless-drivers-next.git, thanks.
3a8855d8cfcb MAINTAINERS: update qtnfmac maintainers
--
https://patchwork.kernel.org/patch/11560401/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 1/2] MIPS: Loongson64: Guard against future cores without CPUCFG
From: WANG Xuerui @ 2020-05-29 17:09 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: WANG Xuerui, linux-mips, Huacai Chen, Jiaxun Yang
In-Reply-To: <20200529171000.8905-1-git@xen0n.name>
Previously it was thought that all future Loongson cores would come with
native CPUCFG. From new information shared by Huacai this is definitely
not true (maybe some future 2K cores, for example), so collisions at
PRID_REV level are inevitable. The CPU model matching needs to take
PRID_IMP into consideration.
The emulation logic needs to be disabled for those future cores as well,
as we cannot possibly encode their non-discoverable features right now.
Reported-by: Huacai Chen <chenhc@lemote.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: WANG Xuerui <git@xen0n.name>
---
.../include/asm/mach-loongson64/cpucfg-emul.h | 11 ++++++
arch/mips/kernel/traps.c | 4 ++
arch/mips/loongson64/cpucfg-emul.c | 37 ++++++++++---------
3 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/cpucfg-emul.h b/arch/mips/include/asm/mach-loongson64/cpucfg-emul.h
index 01dc308df7b2..d64af19c210d 100644
--- a/arch/mips/include/asm/mach-loongson64/cpucfg-emul.h
+++ b/arch/mips/include/asm/mach-loongson64/cpucfg-emul.h
@@ -12,6 +12,12 @@
void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c);
+static inline bool loongson3_cpucfg_emulation_enabled(struct cpuinfo_mips *c)
+{
+ /* All supported cores have non-zero LOONGSON_CFG1 data. */
+ return c->loongson3_cpucfg_data[0] != 0;
+}
+
static inline u32 loongson3_cpucfg_read_synthesized(struct cpuinfo_mips *c,
__u64 sel)
{
@@ -53,6 +59,11 @@ static inline void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
{
}
+static inline bool loongson3_cpucfg_emulation_enabled(struct cpuinfo_mips *c)
+{
+ return false;
+}
+
static inline u32 loongson3_cpucfg_read_synthesized(struct cpuinfo_mips *c,
__u64 sel)
{
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 2d5b16daf331..caff4c921461 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -720,6 +720,10 @@ static int simulate_loongson3_cpucfg(struct pt_regs *regs,
int rs = (opcode & RS) >> 21;
__u64 sel = regs->regs[rs];
+ /* Do not emulate on unsupported core models. */
+ if (!loongson3_cpucfg_emulation_enabled(¤t_cpu_data))
+ return -1;
+
perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, 1, regs, 0);
regs->regs[rd] = loongson3_cpucfg_read_synthesized(
diff --git a/arch/mips/loongson64/cpucfg-emul.c b/arch/mips/loongson64/cpucfg-emul.c
index fdd52b21c1df..c16023a13379 100644
--- a/arch/mips/loongson64/cpucfg-emul.c
+++ b/arch/mips/loongson64/cpucfg-emul.c
@@ -134,13 +134,9 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
c->loongson3_cpucfg_data[1] = 0;
c->loongson3_cpucfg_data[2] = 0;
- /* Add CPUCFG features non-discoverable otherwise.
- *
- * All Loongson processors covered by CPUCFG emulation have distinct
- * PRID_REV, so take advantage of this.
- */
- switch (c->processor_id & PRID_REV_MASK) {
- case PRID_REV_LOONGSON3A_R1:
+ /* Add CPUCFG features non-discoverable otherwise. */
+ switch (c->processor_id & (PRID_IMP_MASK | PRID_REV_MASK)) {
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3A_R1:
c->loongson3_cpucfg_data[0] |= (LOONGSON_CFG1_LSLDR0 |
LOONGSON_CFG1_LSSYNCI | LOONGSON_CFG1_LSUCA |
LOONGSON_CFG1_LLSYNC | LOONGSON_CFG1_TGTSYNC);
@@ -153,8 +149,8 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
LOONGSON_CFG3_LCAMVW_REV1);
break;
- case PRID_REV_LOONGSON3B_R1:
- case PRID_REV_LOONGSON3B_R2:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2:
c->loongson3_cpucfg_data[0] |= (LOONGSON_CFG1_LSLDR0 |
LOONGSON_CFG1_LSSYNCI | LOONGSON_CFG1_LSUCA |
LOONGSON_CFG1_LLSYNC | LOONGSON_CFG1_TGTSYNC);
@@ -167,10 +163,10 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
LOONGSON_CFG3_LCAMVW_REV1);
break;
- case PRID_REV_LOONGSON2K_R1_0:
- case PRID_REV_LOONGSON2K_R1_1:
- case PRID_REV_LOONGSON2K_R1_2:
- case PRID_REV_LOONGSON2K_R1_3:
+ case PRID_IMP_LOONGSON_64R | PRID_REV_LOONGSON2K_R1_0:
+ case PRID_IMP_LOONGSON_64R | PRID_REV_LOONGSON2K_R1_1:
+ case PRID_IMP_LOONGSON_64R | PRID_REV_LOONGSON2K_R1_2:
+ case PRID_IMP_LOONGSON_64R | PRID_REV_LOONGSON2K_R1_3:
decode_loongson_config6(c);
probe_uca(c);
@@ -183,10 +179,10 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
c->loongson3_cpucfg_data[2] = 0;
break;
- case PRID_REV_LOONGSON3A_R2_0:
- case PRID_REV_LOONGSON3A_R2_1:
- case PRID_REV_LOONGSON3A_R3_0:
- case PRID_REV_LOONGSON3A_R3_1:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3A_R2_0:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3A_R2_1:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3A_R3_0:
+ case PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3A_R3_1:
decode_loongson_config6(c);
probe_uca(c);
@@ -203,6 +199,13 @@ void loongson3_cpucfg_synthesize_data(struct cpuinfo_mips *c)
LOONGSON_CFG3_LCAMKW_REV1 |
LOONGSON_CFG3_LCAMVW_REV1);
break;
+
+ default:
+ /* It is possible that some future Loongson cores still do
+ * not have CPUCFG, so do not emulate anything for these
+ * cores.
+ */
+ return;
}
/* This feature is set by firmware, but all known Loongson-64 systems
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
From: Cristian Ciocaltea @ 2020-05-29 17:10 UTC (permalink / raw)
To: Andreas Färber
Cc: Greg Kroah-Hartman, Manivannan Sadhasivam, linux-actions,
linux-kernel, linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <16ff435f-9172-e01d-dfe6-7aa8575c4bd6@suse.de>
On Fri, May 29, 2020 at 05:56:47PM +0200, Andreas Färber wrote:
> Hi,
>
> Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> > Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> > that enables OWL UART to be used for KGDB debugging over serial line.
> >
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> > ---
> > drivers/tty/serial/owl-uart.c | 45 ++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> > index c2fa2f15d50a..26dcc374dec5 100644
> > --- a/drivers/tty/serial/owl-uart.c
> > +++ b/drivers/tty/serial/owl-uart.c
> > @@ -12,6 +12,7 @@
> > #include <linux/console.h>
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> > @@ -20,13 +21,13 @@
> > #include <linux/tty.h>
> > #include <linux/tty_flip.h>
> > -#define OWL_UART_PORT_NUM 7
> > -#define OWL_UART_DEV_NAME "ttyOWL"
> > +#define OWL_UART_PORT_NUM 7
> > +#define OWL_UART_DEV_NAME "ttyOWL"
> > -#define OWL_UART_CTL 0x000
> > -#define OWL_UART_RXDAT 0x004
> > -#define OWL_UART_TXDAT 0x008
> > -#define OWL_UART_STAT 0x00c
> > +#define OWL_UART_CTL 0x000
> > +#define OWL_UART_RXDAT 0x004
> > +#define OWL_UART_TXDAT 0x008
> > +#define OWL_UART_STAT 0x00c
>
> Please do not unnecessarily re-indent kernel code. You can do so when you're
> actually adding something new.
>
Hi Andreas,
Thank you for reviewing!
Sure, I will revert unnecessary changes.
>
> > #define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
> > #define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
> > @@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port, int flags)
> > }
> > }
> > +#ifdef CONFIG_CONSOLE_POLL
> > +
> > +static int owl_uart_poll_get_char(struct uart_port *port)
> > +{
> > + u32 c = NO_POLL_CHAR;
> > +
> > + if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
> > + c = owl_uart_read(port, OWL_UART_RXDAT);
> > +
> > + return c;
> > +}
> > +
> > +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
> > +{
> > + /* Wait while TX FIFO is full */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
> > + cpu_relax();
> > +
> > + /* Send the character out */
> > + owl_uart_write(port, c, OWL_UART_TXDAT);
> > +
> > + /* Wait for transmitter to become empty */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
> > + cpu_relax();
> > +}
>
> How is this different from earlycon? I dislike that this is being
> open-coded. Please try to reuse existing functions for this.
>
I actually tried initially to reuse the existing code, but I found
a few (possible) issues:
- owl_uart_port_write() does more things than I think it's really
needed here, i.e. I'm not sure if the locking stuff and the IRQ
setup are required. From what I've noticed, most serial drivers provide
a very simple implementation (and lock free) for the callbacks, but
I couldn't figure out if locking could be required in some
circumstances.
- owl_console_putchar() could be a better alternative, but it depends
on CONFIG_SERIAL_OWL_CONSOLE which might not be enabled if the user
only chooses CONFIG_KGDB_SERIAL_CONSOLE, although this is probably
not a valid scenario.
Kind regards,
Cristi
>
> Regards,
> Andreas
>
> > +
> > +#endif /* CONFIG_CONSOLE_POLL */
> > +
> > static const struct uart_ops owl_uart_ops = {
> > .set_mctrl = owl_uart_set_mctrl,
> > .get_mctrl = owl_uart_get_mctrl,
> > @@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
> > .request_port = owl_uart_request_port,
> > .release_port = owl_uart_release_port,
> > .verify_port = owl_uart_verify_port,
> > +#ifdef CONFIG_CONSOLE_POLL
> > + .poll_get_char = owl_uart_poll_get_char,
> > + .poll_put_char = owl_uart_poll_put_char,
> > +#endif
> > };
> > #ifdef CONFIG_SERIAL_OWL_CONSOLE
> >
>
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (AG Nürnberg)
_______________________________________________
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 v6] drm/ioctl: Add a ioctl to set and get a label on GEM objects
From: Eric Anholt @ 2020-05-29 17:10 UTC (permalink / raw)
To: Rohan Garg; +Cc: kernel, Emil Velikov, DRI Development
In-Reply-To: <4235324.LvFx2qVVIh@saphira>
On Fri, May 29, 2020 at 6:44 AM Rohan Garg <rohan.garg@collabora.com> wrote:
>
> Hey Eric!
>
> On jueves, 28 de mayo de 2020 20:45:24 (CEST) Eric Anholt wrote:
> > On Thu, May 28, 2020 at 10:06 AM Rohan Garg <rohan.garg@collabora.com>
> wrote:
> > > DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
> > > with a handle, making it easier to debug issues in userspace
> > > applications.
> > >
> > > DRM_IOCTL_HANDLE_GET_LABEL lets you read the label associated
> > > with a buffer.
> > >
> > > Changes in v2:
> > > - Hoist the IOCTL up into the drm_driver framework
> > >
> > > Changes in v3:
> > > - Introduce a drm_gem_set_label for drivers to use internally
> > >
> > > in order to label a GEM object
> > >
> > > - Hoist string copying up into the IOCTL
> > > - Fix documentation
> > > - Move actual gem labeling into drm_gem_adopt_label
> > >
> > > Changes in v4:
> > > - Refactor IOCTL call to only perform string duplication and move
> > >
> > > all gem lookup logic into GEM specific call
> > >
> > > Changes in v5:
> > > - Fix issues pointed out by kbuild test robot
> > > - Cleanup minor issues around kfree and out/err labels
> > > - Fixed API documentation issues
> > > - Rename to DRM_IOCTL_HANDLE_SET_LABEL
> > > - Introduce a DRM_IOCTL_HANDLE_GET_LABEL to read labels
> > > - Added some documentation for consumers of this IOCTL
> > > - Ensure that label's cannot be longer than PAGE_SIZE
> > > - Set a default label value
> > > - Drop useless warning
> > > - Properly return length of label to userspace even if
> > >
> > > userspace did not allocate memory for label.
> > >
> > > Changes in v6:
> > > - Wrap code to make better use of 80 char limit
> > > - Drop redundant copies of the label
> > > - Protect concurrent access to labels
> > > - Improved documentation
> > > - Refactor setter/getter ioctl's to be static
> > > - Return EINVAL when label length > PAGE_SIZE
> > > - Simplify code by calling the default GEM label'ing
> > >
> > > function for all drivers using GEM
> > >
> > > - Do not error out when fetching empty labels
> > > - Refactor flags to the u32 type and add documentation
> > > - Refactor ioctls to use correct DRM_IOCTL{R,W,WR} macros
> > > - Return length of copied label to userspace
> > >
> > > Signed-off-by: Rohan Garg <rohan.garg@collabora.com>
> >
> > I don't think we should land this until it actually does something
> > with the label, that feels out of the spirit of our uapi merge rules.
> > I would suggest looking at dma_buf_set_name(), which would produce
> > useful output in debugfs's /dma_buf/buf_info. But also presumably you
> > have something in panfrost using this?
> >
>
> My current short term plan is to hook up glLabel to the labeling functionality
> in order for userspace applications to debug exactly which buffer objects
> could be causing faults in the kernel for speedier debugging.
So, something like "when a fault happens, dump/capture names of nearby
objects"? That would certainly be nice to have!
> The more long term plan is to label each buffer with a unique id that we can
> correlate to the GL calls being flushed in order to be able to profile (a set
> of) GL calls on various platforms in order to aid driver developers with
> performance work. This could be something that we corelate on the userspace
> side with the help of perfetto by using this [1] patch that emits ftrace
> events.
I'm curious how BO names are part of profiling? Do you have the
ability to sample instruction IP and use that to figure out where time
is spent in shaders, or something?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
From: Cristian Ciocaltea @ 2020-05-29 17:10 UTC (permalink / raw)
To: Andreas Färber
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, linux-arm-kernel, linux-kernel, linux-actions
In-Reply-To: <16ff435f-9172-e01d-dfe6-7aa8575c4bd6@suse.de>
On Fri, May 29, 2020 at 05:56:47PM +0200, Andreas Färber wrote:
> Hi,
>
> Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> > Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> > that enables OWL UART to be used for KGDB debugging over serial line.
> >
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> > ---
> > drivers/tty/serial/owl-uart.c | 45 ++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> > index c2fa2f15d50a..26dcc374dec5 100644
> > --- a/drivers/tty/serial/owl-uart.c
> > +++ b/drivers/tty/serial/owl-uart.c
> > @@ -12,6 +12,7 @@
> > #include <linux/console.h>
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> > @@ -20,13 +21,13 @@
> > #include <linux/tty.h>
> > #include <linux/tty_flip.h>
> > -#define OWL_UART_PORT_NUM 7
> > -#define OWL_UART_DEV_NAME "ttyOWL"
> > +#define OWL_UART_PORT_NUM 7
> > +#define OWL_UART_DEV_NAME "ttyOWL"
> > -#define OWL_UART_CTL 0x000
> > -#define OWL_UART_RXDAT 0x004
> > -#define OWL_UART_TXDAT 0x008
> > -#define OWL_UART_STAT 0x00c
> > +#define OWL_UART_CTL 0x000
> > +#define OWL_UART_RXDAT 0x004
> > +#define OWL_UART_TXDAT 0x008
> > +#define OWL_UART_STAT 0x00c
>
> Please do not unnecessarily re-indent kernel code. You can do so when you're
> actually adding something new.
>
Hi Andreas,
Thank you for reviewing!
Sure, I will revert unnecessary changes.
>
> > #define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
> > #define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
> > @@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port, int flags)
> > }
> > }
> > +#ifdef CONFIG_CONSOLE_POLL
> > +
> > +static int owl_uart_poll_get_char(struct uart_port *port)
> > +{
> > + u32 c = NO_POLL_CHAR;
> > +
> > + if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
> > + c = owl_uart_read(port, OWL_UART_RXDAT);
> > +
> > + return c;
> > +}
> > +
> > +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
> > +{
> > + /* Wait while TX FIFO is full */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
> > + cpu_relax();
> > +
> > + /* Send the character out */
> > + owl_uart_write(port, c, OWL_UART_TXDAT);
> > +
> > + /* Wait for transmitter to become empty */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
> > + cpu_relax();
> > +}
>
> How is this different from earlycon? I dislike that this is being
> open-coded. Please try to reuse existing functions for this.
>
I actually tried initially to reuse the existing code, but I found
a few (possible) issues:
- owl_uart_port_write() does more things than I think it's really
needed here, i.e. I'm not sure if the locking stuff and the IRQ
setup are required. From what I've noticed, most serial drivers provide
a very simple implementation (and lock free) for the callbacks, but
I couldn't figure out if locking could be required in some
circumstances.
- owl_console_putchar() could be a better alternative, but it depends
on CONFIG_SERIAL_OWL_CONSOLE which might not be enabled if the user
only chooses CONFIG_KGDB_SERIAL_CONSOLE, although this is probably
not a valid scenario.
Kind regards,
Cristi
>
> Regards,
> Andreas
>
> > +
> > +#endif /* CONFIG_CONSOLE_POLL */
> > +
> > static const struct uart_ops owl_uart_ops = {
> > .set_mctrl = owl_uart_set_mctrl,
> > .get_mctrl = owl_uart_get_mctrl,
> > @@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
> > .request_port = owl_uart_request_port,
> > .release_port = owl_uart_release_port,
> > .verify_port = owl_uart_verify_port,
> > +#ifdef CONFIG_CONSOLE_POLL
> > + .poll_get_char = owl_uart_poll_get_char,
> > + .poll_put_char = owl_uart_poll_put_char,
> > +#endif
> > };
> > #ifdef CONFIG_SERIAL_OWL_CONSOLE
> >
>
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (AG Nürnberg)
^ permalink raw reply
* [PATCH 0/2] CPUCFG emulation future-proofing & HWCAP addition
From: WANG Xuerui @ 2020-05-29 17:09 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: WANG Xuerui, linux-mips
This patch series future-proofs the CPUCFG emulation, in light of
possibility of new Loongson cores still lacking native CPUCFG.
Also an HWCAP flag bit is allocated and exposed for userspace's probing
convenience, per the earlier plan shared on the mailing list.
WANG Xuerui (2):
MIPS: Loongson64: Guard against future cores without CPUCFG
MIPS: Expose Loongson CPUCFG availability via HWCAP
.../include/asm/mach-loongson64/cpucfg-emul.h | 11 +++++
arch/mips/include/uapi/asm/hwcap.h | 1 +
arch/mips/kernel/traps.c | 4 ++
arch/mips/loongson64/cpucfg-emul.c | 46 +++++++++++--------
4 files changed, 44 insertions(+), 18 deletions(-)
--
2.26.2
^ permalink raw reply
* [peterz-queue:x86/entry 5/5] include/linux/compiler.h:392:38: error: call to '__compiletime_assert_211' declared with attribute error: BUILD_BUG_ON failed: N_EXCEPTION_STACKS != 6
From: kbuild test robot @ 2020-05-29 17:10 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/entry
head: d4a2e181448920eddbeb53a79df45e1d7cdddfee
commit: d4a2e181448920eddbeb53a79df45e1d7cdddfee [5/5] x86/entry: Remove DBn stacks
config: x86_64-defconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
git checkout d4a2e181448920eddbeb53a79df45e1d7cdddfee
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/export.h:43,
from include/linux/linkage.h:7,
from include/linux/kernel.h:8,
from include/linux/kallsyms.h:10,
from arch/x86/kernel/dumpstack_64.c:7:
arch/x86/kernel/dumpstack_64.c: In function 'stack_type_name':
>> include/linux/compiler.h:392:38: error: call to '__compiletime_assert_211' declared with attribute error: BUILD_BUG_ON failed: N_EXCEPTION_STACKS != 6
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'
373 | prefix ## suffix(); | ^~~~~~
include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
>> arch/x86/kernel/dumpstack_64.c:31:2: note: in expansion of macro 'BUILD_BUG_ON'
31 | BUILD_BUG_ON(N_EXCEPTION_STACKS != 6);
| ^~~~~~~~~~~~
In function 'in_exception_stack',
inlined from 'get_stack_info' at arch/x86/kernel/dumpstack_64.c:164:6:
include/linux/compiler.h:392:38: error: call to '__compiletime_assert_212' declared with attribute error: BUILD_BUG_ON failed: N_EXCEPTION_STACKS != 6
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'
373 | prefix ## suffix(); | ^~~~~~
include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
arch/x86/kernel/dumpstack_64.c:91:2: note: in expansion of macro 'BUILD_BUG_ON'
91 | BUILD_BUG_ON(N_EXCEPTION_STACKS != 6);
| ^~~~~~~~~~~~
vim +/__compiletime_assert_211 +392 include/linux/compiler.h
9a8ab1c39970a4 Daniel Santos 2013-02-21 378
9a8ab1c39970a4 Daniel Santos 2013-02-21 379 #define _compiletime_assert(condition, msg, prefix, suffix) \
9a8ab1c39970a4 Daniel Santos 2013-02-21 380 __compiletime_assert(condition, msg, prefix, suffix)
9a8ab1c39970a4 Daniel Santos 2013-02-21 381
9a8ab1c39970a4 Daniel Santos 2013-02-21 382 /**
9a8ab1c39970a4 Daniel Santos 2013-02-21 383 * compiletime_assert - break build and emit msg if condition is false
9a8ab1c39970a4 Daniel Santos 2013-02-21 384 * @condition: a compile-time constant condition to check
9a8ab1c39970a4 Daniel Santos 2013-02-21 385 * @msg: a message to emit if condition is false
9a8ab1c39970a4 Daniel Santos 2013-02-21 386 *
9a8ab1c39970a4 Daniel Santos 2013-02-21 387 * In tradition of POSIX assert, this macro will break the build if the
9a8ab1c39970a4 Daniel Santos 2013-02-21 388 * supplied condition is *false*, emitting the supplied error message if the
9a8ab1c39970a4 Daniel Santos 2013-02-21 389 * compiler has support to do so.
9a8ab1c39970a4 Daniel Santos 2013-02-21 390 */
9a8ab1c39970a4 Daniel Santos 2013-02-21 391 #define compiletime_assert(condition, msg) \
af9c5d2e3b3558 Vegard Nossum 2020-04-06 @392 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
9a8ab1c39970a4 Daniel Santos 2013-02-21 393
:::::: The code at line 392 was first introduced by commit
:::::: af9c5d2e3b355854ff0e4acfbfbfadcd5198a349 compiler.h: fix error in BUILD_BUG_ON() reporting
:::::: TO: Vegard Nossum <vegard.nossum@oracle.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 29356 bytes --]
^ permalink raw reply
* Re: Adding usb-ctrl from intel-bmc into phosphor-misc
From: James Feist @ 2020-05-29 17:09 UTC (permalink / raw)
To: Brad Bishop, 郁雷, openbmc; +Cc: Vernon Mauery
In-Reply-To: <555375f27645bf26067fba4cfbfc5f5f8ac8c101.camel@fuzziesquirrel.com>
On 5/28/2020 5:48 AM, Brad Bishop wrote:
> On Wed, 2020-05-27 at 11:07 +0800, 郁雷 wrote:
>> There is a script [usb-ctrl][1] hosted in intel-bmc.
>> It supports the VirtualMedia feature by insert/eject files to the host
>> as a USB mass-storage device.
>> Comparing to the existing [state_hook][2] in jsnbd, it supports
>> multiple UDCs, so it supports mount multiple files.
>>
>> In addition, I have some updates on the usb-ctrl script to make it
>> support the USB ECM device, which creates a USB ethernet device
>> between BMC and the host.
>>
>> So my proposal is to add the `usb-ctrl` script into the phosphor-misc
>> repo so that it gets reviewed and could be used by upstream.
>>
>> Any ideas?
>>
>> [1]:
>> https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-common/recipes-core/fw-update/files/usb-ctrl
>> [2]:
>> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/aspeed-layer/recipes-connectivity/jsnbd/jsnbd/state_hook
>>
>
> I'm the current maintainer of phosphor-misc and I am looking for help
> with that. I would be fine with adding this script to that repository.
> It would be nice, but not required, to hear from the Intel team that
> they would pull from the new location if we do this...
Yes, we could start using it from there. Just would have to move the
recipes to point to the right place. CCing Vernon who was the original
author.
>
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: iio: imu: bmi160: add regulators and mount-matrix
From: Rob Herring @ 2020-05-29 17:09 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming, daniel.baluta,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Jonathan Cameron
In-Reply-To: <20200525164615.14962-3-jonathan.albrieux@gmail.com>
On Mon, May 25, 2020 at 06:46:01PM +0200, Jonathan Albrieux wrote:
> Add vdd-supply and vddio-supply support.
> Add mount-matrix support.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> .../bindings/iio/imu/bosch,bmi160.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> index 0d0ef84e22b9..cfe40dbcd723 100644
> --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> @@ -37,6 +37,17 @@ properties:
> set if the specified interrupt pin should be configured as
> open drain. If not set, defaults to push-pull.
>
> + vdd-supply:
> + maxItems: 1
Supplies are always a single item, so don't need this.
> + description: provide VDD power to the sensor.
> +
> + vddio-supply:
> + maxItems: 1
> + description: provide VDD IO power to the sensor.
> +
> + mount-matrix:
> + description: an optional 3x3 mounting rotation matrix
> +
> required:
> - compatible
> - reg
> @@ -52,9 +63,14 @@ examples:
> bmi160@68 {
> compatible = "bosch,bmi160";
> reg = <0x68>;
> + vdd-supply = <&pm8916_l17>;
> + vddio-supply = <&pm8916_l6>;
> interrupt-parent = <&gpio4>;
> interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> interrupt-names = "INT1";
> + mount-matrix = "0", "1", "0",
> + "-1", "0", "0",
> + "0", "0", "1";
> };
> };
> - |
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PULL 0/5] Qcrypto next patches
From: Daniel P. Berrangé @ 2020-05-29 17:08 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20200529103555.2759928-1-berrange@redhat.com>
On Fri, May 29, 2020 at 11:35:50AM +0100, Daniel P. Berrangé wrote:
> The following changes since commit b8bee16e94df0fcd03bdad9969c30894418b0e6e:
>
> Merge remote-tracking branch 'remotes/kraxel/tags/vga-20200528-pull-request=
> ' into staging (2020-05-28 18:13:20 +0100)
>
> are available in the Git repository at:
>
> https://github.com/berrange/qemu tags/qcrypto-next-pull-request
>
> for you to fetch changes up to efd6cd2328064b569a7a92ad4aea1dc985d98601:
>
> crypto: Remove use of GCRYPT_VERSION macro. (2020-05-29 11:33:19 +0100)
>
> ----------------------------------------------------------------
> Misc crypto subsystem fixes
>
> * Add support for fetching secret from Linux keyring
> * Remove redundant version check in gcrypt initialization
> * Allow for RNG provider to be disabled at build time
>
> ----------------------------------------------------------------
>
> Alexey Krasikov (3):
> crypto/secret: move main logic from 'secret' to 'secret_common'.
> crypto/linux_keyring: add 'secret_keyring' secret object.
> test-crypto-secret: add 'secret_keyring' object tests.
>
> Marek Marczykowski-G=C3=B3recki (1):
> crypto: add "none" random provider
>
> Richard W.M. Jones (1):
> crypto: Remove use of GCRYPT_VERSION macro.
>
> configure | 73 ++++++
> crypto/Makefile.objs | 5 +-
> crypto/init.c | 2 +-
> crypto/random-none.c | 38 +++
> crypto/secret.c | 347 +--------------------------
> crypto/secret_common.c | 403 ++++++++++++++++++++++++++++++++
> crypto/secret_keyring.c | 148 ++++++++++++
> include/crypto/secret.h | 20 +-
> include/crypto/secret_common.h | 68 ++++++
> include/crypto/secret_keyring.h | 52 +++++
> tests/Makefile.include | 4 +
> tests/test-crypto-secret.c | 158 +++++++++++++
> 12 files changed, 959 insertions(+), 359 deletions(-)
> create mode 100644 crypto/random-none.c
> create mode 100644 crypto/secret_common.c
> create mode 100644 crypto/secret_keyring.c
> create mode 100644 include/crypto/secret_common.h
> create mode 100644 include/crypto/secret_keyring.h
Seems the mingw build is broken due to mistakes in configure, so
i'll respin this.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ 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.