* [PATCH v3 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-08 11:40 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, linux-arm-kernel
This patchsets converts the Amlogic Meson DWMAC glue bindings over to
YAML schemas using the already converted dwmac bindings.
The first patch is needed because the Amlogic glue needs a supplementary
reg cell to access the DWMAC glue registers.
Changes since v2:
- Added review tags
- Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Neil Armstrong (2):
dt-bindings: net: snps,dwmac: update reg minItems maxItems
dt-bindings: net: meson-dwmac: convert to yaml
.../net/allwinner,sun7i-a20-gmac.yaml | 3 +
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 8 +-
4 files changed, 123 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Dave Martin @ 2019-08-08 11:31 UTC (permalink / raw)
To: Stefan Agner
Cc: Marc Zyngier, ynorov, will.deacon, linux-arm-kernel,
suzuki.poulose
In-Reply-To: <2adcb1ed626fb7829481b2b8d0ff54d1@agner.ch>
On Thu, Aug 08, 2019 at 12:17:26PM +0200, Stefan Agner wrote:
> On 2019-08-08 11:04, Marc Zyngier wrote:
[...]
> > Hey, you could create a VM, a vcpu and dump the ID registers by issuing
> > a set of KVM_GET_ONE_REG ioctls. Not necessarily recommended... ;-)
>
> I see, no no, I think I leave that exercise for somebody else to try :)
I think KVM guest AArch32 support can exist even when compat is
configured out though. So just because it works in a guest doesn't mean
that the host kernel supports it for userspace, IIUC.
Otherwise, this would be a fun hack ;)
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Dave Martin @ 2019-08-08 11:28 UTC (permalink / raw)
To: Stefan Agner
Cc: Marc Zyngier, ynorov, will.deacon, linux-arm-kernel,
suzuki.poulose
In-Reply-To: <09a5d28f865ef0bd034ba9acbe1b5334@agner.ch>
On Thu, Aug 08, 2019 at 12:30:03PM +0200, Stefan Agner wrote:
> On 2019-08-08 11:35, Dave Martin wrote:
> > On Thu, Aug 08, 2019 at 09:36:42AM +0200, Stefan Agner wrote:
> >> [resend this time with the correct mailing list address]
> >>
> >> Hello,
> >>
> >> I am trying to detect whether an ARMv8 system running in AArch64 state
> >> supports AArch32 state from a user space process. The arm64_features[]
> >> in
> >
> > Why? Is this just for diagnostic purposes, or some programmatic reason?
>
> The use case I currently have in mind is to decide whether to show
> 32-bit ARM Docker images in a UI (or arm32v7 images how it is nowadays
> called in Docker land).
>
> >
> > In the latter case, just try to do what ever it is you want to do that
> > depends on AArch32: if it fails, you don't have AArch32.
>
>
> Yeah one option I considered was just fetching a minimalistic arm32v7
> container, but still seems a bit excessive.
Ah, right.
So, I guess trying to set the personality or trying to exec a trivial
32-bit binary would answer that.
You could ship a trivial static binary with docker for that: trying
to run a whole container is probably overkill.
If trying to set the personality is more convenient though, that seems
an equally good approach in practice.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.19 1452/1504] drivers/staging/xroeframer/xroe_framer.o:(.bss+0x0): multiple definition of `lp'
From: kbuild test robot @ 2019-08-08 11:12 UTC (permalink / raw)
To: Bharat Kumar Gogada; +Cc: Michal Simek, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.19
head: f0be99aa3709d7b1813796fc828053c4099c6b44
commit: 7d67b5fe62ec7a2b6c8fea1c4303a4e60a2989f5 [1452/1504] pci: xdma: pl: Remove of_pci_get_host_bridge_resources
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7d67b5fe62ec7a2b6c8fea1c4303a4e60a2989f5
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/staging/xroeframer/xroe_framer.o:(.bss+0x0): multiple definition of `lp'
drivers/net/ethernet/xilinx/xilinx_tsn_switch.o:(.bss+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61001 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] arm64: Clarify when cpu_enable() is called
From: Suzuki K Poulose @ 2019-08-08 11:05 UTC (permalink / raw)
To: broonie, will; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190807165143.GI4048@sirena.co.uk>
On 07/08/2019 17:51, Mark Brown wrote:
> On Wed, Aug 07, 2019 at 05:01:08PM +0100, Will Deacon wrote:
>> On Tue, Aug 06, 2019 at 06:00:43PM +0100, Mark Brown wrote:
>
>>> - * Take the appropriate actions to enable this capability for this CPU.
>>> - * For each successfully booted CPU, this method is called for each
>>> - * globally detected capability.
>>> + * Take the appropriate actions to configure this capability for this
>>> + * CPU. This will be called on all CPUs in the system if the
>>> + * capability is detected anywhere in the system.
>
>> That's not quite right though either, is it? We need to take into account
>> the scope of the capability/erratum as well, since we don't /always/ call
>> this function for everybody.
>
> I guess you're thinking of the ARM64_CPUCAP_SYSTEM_FEATURE case where we
> match the feature on all CPUs so we could see the feature on some CPUs
> but not detect it as we're requiring a match on all?
We don't run the "match" check (i.e, detect) on all CPUs for SYSTEM scoped
features. Instead, we use sanitised feature set to detect the system features.
> Possibly the above
> should be "detected and enabled" rather than just "detected"? I can see
> how that might not be 100% clear, I was thinking of detection as passing
> all the match requirements including cross-CPU requirements but that
> could be more explicit. Perhaps something like:
>
> If this is called for any CPU in the system then it will be
> called for all of them.
>
> might cover it?
* Take the appropriate actions to configure this capability for the
* current CPU. If this capability is detected by the kernel, this will
* called on all the CPUs in the system, including the hotplugged
* CPUs.
*/
>
>> Suzuki, are there any cases where ->cpu_enable() may be called on a CPU
>> without the feature outside of ARM64_CPUCAP_LOCAL_CPU_ERRATUM or
>> ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE?
>
> There's at least ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE, that was what
> caused me to notice what was happening (and get confused about why
> cpu_enable() was being called on non-matching CPUs).
Well, this is true for the ERRATUM too. In a nutshell, any LOCAL_CPU scoped
capability can trigger this on the CPUs.
>
> I don't see where we limit where cpu_enable() is called after we start
> calling it. When we're looping through in cpu_enable_non_boot_scope()
> we skip SCOPE_BOOT_CPU but those get cpu_enable() called in
> enable_cpu_capabilites() or verify_local_cpu_capabilities() depending on
> if it's the boot CPU or not. It's possible I'm missing something
> though.
There are two phases for any capability:
1) Detection - The kernel runs the matches() for the capability and marks
the cap available when it returns true. Depending on the scope of the
capability this could be done :
a) BOOT_CPU scope - Only on boot CPU. This must be only used for
features that are enabled very early in the kernel and get used
right away by the boot CPU. The checks use the raw CPU registers.
e.g, VHE - kernel runs in EL2, GIC NMI via Priority masking.
b) LOCAL_SCOPE - On boot CPU and all the secondary CPUs booted by the
kernel during smp bring up (before smp_cpus_done()) and before the
userspace gets control. The checks use the raw CPU registers.
e.g, CPU erratums
c) SYSTEM_SCOPE - After all the smp CPUs are booted by the kernel,
(i.e, from smp_cpus_done()). The checks are usually run with
sanitised feature register set, and gives you the system wide
state of the features.
The kernel finalizes the capabilities at this point and cannot be changed.
Thus, the hotplugged CPUs cannot affect the feature state and must comply
to the now advertised set of capabilities/features.
2) Enabling a capability - Once the kernel has detected the capability and has
been advertised (via cpu_hwcaps), each capability can take some action using
the cpu_enable() callback. This could include changing system/control register
configurations (e.g, trapping access to registers). The cpu_enable() is called
on all online CPUs in the system. Depending on the SCOPE of the capabilities,
the "cpu_enable" operation is triggered. For all CPUs that are brought online
after the capability was enabled (e.g hotplugged CPUs), this gets called via
check_local_cpu_capabilities()->verify_local_cpu_capabilities().
a) BOOT_CPU - The BOOT scope capabilities are enabled after the
boot CPU detects the features.
i.e, from setup_boot_cpu_capabilities() and is applied directly
on the boot CPU (because there are no other online CPUs). Thus, all
other CPUs (including the secondaries brought up by the kernel) trigger
the cpu_enable() for BOOT scope CPUs via check_local_cpu_capabilities().
b) All the other capabilities trigger the "cpu_enable" on all the online CPUs
after the system establishes the feature set in setup_system_capabilities().
And the cpu_enable() operations are batched via stop_machine() with
cpu_enable_non_boot_scope_capabilities() [ The boot CPU scope capabilities
are already enabled by now on all online CPUs].
Any new CPU that the kernel brings up must be triggered by the userspace and
they trigger the cpu_enable() operation as they are brought up individually
via check_local_cpu_capabilities()->verify_local_cpu_capabilities().
Does this help ?
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Robin Murphy @ 2019-08-08 10:43 UTC (permalink / raw)
To: Greg KH; +Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <20190808100726.GB23844@kroah.com>
On 2019-08-08 11:07 am, Greg KH wrote:
> On Thu, Aug 08, 2019 at 10:46:24AM +0100, Robin Murphy wrote:
>> On 2019-08-08 9:58 am, Greg KH wrote:
>>> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
>>>> Hello linux-usb and linux-arm.
>>>>
>>>> Ccing security@ because "the kernel dma code is mapping randomish
>>>> kernel/user mem to a user process" seems to have security implications
>>>> even though i didnt research that aspect past "its a 100% reliable way
>>>> to crash a raspi from userspace".
>>>>
>>>> tried submitting this through linux-arm-kernel ~2 weeks ago but
>>>> the only "response" i got was phishing-spam.
>>>> tried to follow up through raspi-internals chat, they suggested
>>>> i try linux-usb instead, but otoh the original reporter was
>>>> deflected from -usb to "try some other mls, they might care".
>>>> https://www.spinics.net/lists/linux-usb/msg173277.html
>>>>
>>>> if i am not following some arcane ritual or indenting convention required
>>>> by regular users of these lists i apologize in advance, but i am not a
>>>> kernel developer, i am just here as a user with a bug and a patch.
>>>> (and the vger FAQ link 404s...)
>>>
>>> The "arcane ritual" should be really well documented by now, it's in
>>> Documentation/SubmittingPatches in your kernel tree, and you can read it
>>> online at:
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>
>>>
>>>> i rediffed against HEAD even though the two weeks old patch still applied
>>>> cleanly with +2 offset.
>>>>
>>>> # stepping off soap box # actual technical content starts here #
>>>>
>>>> this is a followup to that thread from 2018-11:
>>>> https://www.spinics.net/lists/arm-kernel/msg685598.html
>>>>
>>>> the issue was discussed in more detail than i can claim
>>>> to fully understand back then, but no fix ever merged.
>>>> but i would really like to use rtl_433 on a raspi without
>>>> having to build a custom-patched kernel first.
>>>>
>>>> the attached patch is my stripdown/cleanup of a devel-diff
>>>> provided to me by the original reporter Steve Markgraf.
>>>> credits to him for the good parts, blame to me for the bad parts.
>>>>
>>>> this does not cover the additional case of "PIO-based usb controllers"
>>>> mainly because i dont understand what that means (or how to handle it)
>>>> and if its broken right now (as the thread indicates) it might
>>>> as well stay broken until someone who understands cares enough.
>>>>
>>>> could you please get this on track for merging?
>>>
>>>
>>>>
>>>> regards,
>>>> x23
>>>>
>>>>
>>>>
>>>
>>>> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
>>>> index b265ab5405f9..69594c2169ea 100644
>>>> --- a/drivers/usb/core/devio.c
>>>> +++ b/drivers/usb/core/devio.c
>>>> @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
>>>> usbm->vma_use_count = 1;
>>>> INIT_LIST_HEAD(&usbm->memlist);
>>>> +#ifdef CONFIG_X86
>>>> if (remap_pfn_range(vma, vma->vm_start,
>>>> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
>>>> size, vma->vm_page_prot) < 0) {
>>>> +#else /* !CONFIG_X86 */
>>>> + if (dma_mmap_coherent(ps->dev->bus->sysdev,
>>>> + vma, mem, dma_handle, size) < 0) {
>>>> +#endif /* !CONFIG_X86 */
>>>> dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
>>>> return -EAGAIN;
>>>> }
>>>
>>> First off, we need this in a format we could apply it in (hint, read the
>>> above links).
>>>
>>> But the main issue here is what exactly is this "fixing"? What is wrong
>>> with the existing code that non-x86 systems have such a problem with?
>>> Shouldn't all of these dma issues be handled by the platform with the
>>> remap_pfn_range() call itself?
>>
>> If usbm->mem is (or ever can be) a CPU address returned by
>> dma_alloc_coherent(), then doing virt_to_phys() on it is bogus and may yield
>> a nonsense 'PFN' to begin with. However, it it can can ever come from a
>> regular page allocation/kmalloc/vmalloc then unconditionally passing it to
>> dma_mmap_coherent wouldn't be right either.
>
> usbm->mem comes from a call to usb_alloc_coherent() which calls
> hcd_buffer_alloc() which tries to allocate memory in the best possible
> way for that specific host controller. If the host controller has a
> pool of memory, it uses that, if the host controller has PIO it uses
> kmalloc(), if there are some "pools" of host controller memory it uses
> dma_pool_alloc() and as a total last resort, calls dma_alloc_coherent().
>
> So yes, this could happen.
>
> So how to fix this properly? What host controller driver is being used
> here that ends up defaulting to dma_alloc_coherent()? Shouldn't that be
> fixed up no matter what?
>
> And then, if what you say is correct then a real fix for devio.c could
> be made, but that is NOT going to just depend on the arch the system is
> running on, as all of this depends on the host controller being accessed
> at that moment for that device.
Right, in that case we'd probably want some kind of usb_mmap_coherent()
helper to encapsulate equivalent logic to usb_{alloc,free}_coherent() to
figure out which remap operation is appropriate. It's absolutely not an
arch-specific thing.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Stefan Agner @ 2019-08-08 10:41 UTC (permalink / raw)
To: Will Deacon; +Cc: Marc Zyngier, ynorov, linux-arm-kernel, suzuki.poulose
In-Reply-To: <6c493b15d1be8eb8566fa4b07974e7b9@agner.ch>
On 2019-08-08 12:22, Stefan Agner wrote:
> On 2019-08-08 11:15, Will Deacon wrote:
>> On Thu, Aug 08, 2019 at 10:04:27AM +0100, Marc Zyngier wrote:
>>> On 08/08/2019 08:36, Stefan Agner wrote:
>>> > I started to ask myself what PER_LINUX32 actually changes. From what I
>>> > can tell it only changes the behavior of /proc/cpuinfo? The personality
>>> > seems not to be applied automatically to 32-bit processes, so this is a
>>> > opt-in backward compatibility feature?
>>>
>>> It's all about giving the illusion that the process runs in a "real"
>>> 32bit environment, with all its warts. It doesn't change the CPU mode
>>> you're running in (that'd be a bit harsh). It's only once you exec
>>> something that requires AArch32 that we engage the COMPAT mode.
>>>
>>> Provided that your kernel contains 00377277166b or a backport of it (or
>>> that it predates 4378a7d4be30), the following program should do the
>>> right thing:
>>>
>>> #include <sys/personality.h>
>>> #include <stdio.h>
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> int old, new;
>>>
>>> old = personality(PER_LINUX32);
>>> if (old < 0) {
>>> perror("No 32bit for you");
>>> return 1;
>>> }
>>>
>>> new = personality(0xffffffff);
>>> printf("Running with personality %d\n", new);
>>>
>>> personality(old);
>>> new = personality(0xffffffff);
>>>
>>> printf("Running with personality %d\n", new);
>>>
>>> return 0;
>>> }
>>
>> Or you can use the setarch/linux32 utility.
>
> Wasn't aware of this utility. I guess something like this should work:
>
> $ setarch linux32 true
>
> Thanks for the pointer.
FWIW, tested on a Cavium ThunderX on Packet:
test@arm64test:~$ setarch linux32 true
setarch: failed to set personality to linux32: Invalid argument
test@arm64test:~$ echo $?
1
And works on our i.MX 8QuadMax based machine:
apalis-imx8-06446438:~$ setarch linux32 true
apalis-imx8-06446438:~$ echo $?
0
--
Stefan
_______________________________________________
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 v4 0/3] DCMI bridge support
From: Hugues FRUCHET @ 2019-08-08 10:40 UTC (permalink / raw)
To: Hans Verkuil, Alexandre TORGUE, Mauro Carvalho Chehab,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel@vger.kernel.org, Philippe CORNU,
Yannick FERTRE, Benjamin Gaignard,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <c58613a7-a1d2-cc1b-5f94-beb2bd753e5e@xs4all.nl>
Hi Hans,
On 8/8/19 11:41 AM, Hans Verkuil wrote:
> Hi Hugues,
>
> On 8/8/19 11:38 AM, Hugues FRUCHET wrote:
>> Hi Hans,
>>
>> You're welcome, here it is:
>>
>> 1) v4l-utils master branch, commit
>> 6aa15f7447d4aeca6af1ed7ee9644a0c7e891ece "v4l2-ctl: fix double
>> decrementing of stream_count"
>>
>> 2) Cropping test is failed as usual because of OV5640 discrete framesizes
>>
>> 3) No more /dev/media* and /dev/v4l-*:
>> root@stm32mp1-av96:~# ls -al /dev/video0
>> crw-rw---- 1 root video 81, 0 Mar 19 17:42 /dev/video0
>> root@stm32mp1-av96:~# ls -al /dev/media*
>> ls: cannot access '/dev/media*': No such file or directory
>> root@stm32mp1-av96:~# ls -al /dev/v4l-*
>> ls: cannot access '/dev/v4l-*': No such file or directory
>
> Good. One more question: is this tested with two subdevs? So a bridge+sensor?
Yes, tested with ov5640 (CSI) => st-mipid02 => stm32-dcmi.
In term of hardware setup, it's an Avenger96 96 board [1] embedding an
STM32MP157 (DCMI //) and an ST MIPID02 bridge (CSI to //) in order to
enable CSI video input on high speed expansion connector + a D3
engineering mezzanine board [2] embedding an OV5640 CSI camera.
&dcmi {
...
port {
dcmi_0: endpoint {
remote-endpoint = <&mipid02_2>;
mipid02: mipid02@14 {
...
port@0 {
reg = <0>;
mipid02_0: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&ov5640_0>;
};
};
port@2 {
reg = <2>;
mipid02_2: endpoint {
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;
pclk-sample = <0>;
remote-endpoint = <&dcmi_0>;
};
ov5640: camera@3c {
...
ov5640_0: endpoint {
remote-endpoint = <&mipid02_0>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
[1]
https://www.96boards.org/product/avenger96/
https://wiki.dh-electronics.com/index.php/Avenger96
[2] https://www.96boards.org/product/d3camera/
>
> Regards,
>
> Hans
>
>>
>>
>> root@stm32mp1-av96:~# v4l2-compliance -s
>> v4l2-compliance SHA: 6aa15f7447d4aeca6af1ed7ee9644a0c7e891ece, 32 bits
>>
>> Compliance test for stm32-dcmi device /dev/video0:
>>
>> Driver Info:
>> Driver name : stm32-dcmi
>> Card type : STM32 Camera Memory Interface
>> Bus info : platform:dcmi
>> Driver version : 4.19.49
>> Capabilities : 0x85200001
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps : 0x05200001
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>>
>> Required ioctls:
>> test VIDIOC_QUERYCAP: OK
>>
>> Allow for multiple opens:
>> test second /dev/video0 open: OK
>> test VIDIOC_QUERYCAP: OK
>> test VIDIOC_G/S_PRIORITY: OK
>> test for unlimited opens: OK
>>
>> Debug ioctls:
>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>> test VIDIOC_LOG_STATUS: OK
>>
>> Input ioctls:
>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>> test VIDIOC_G/S/ENUMINPUT: OK
>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>
>> Output ioctls:
>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>
>> Input/Output configuration ioctls:
>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>
>> Control ioctls (Input 0):
>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>> test VIDIOC_QUERYCTRL: OK
>> test VIDIOC_G/S_CTRL: OK
>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>> Standard Controls: 18 Private Controls: 0
>>
>> Format ioctls (Input 0):
>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>> test VIDIOC_G/S_PARM: OK
>> test VIDIOC_G_FBUF: OK (Not Supported)
>> test VIDIOC_G_FMT: OK
>> test VIDIOC_TRY_FMT: OK
>> test VIDIOC_S_FMT: OK
>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>> fail:
>> ../../../../../../../../../sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(1414):
>> node->frmsizes_count[pixfm
>> t] > 1
>> test Cropping: FAIL
>> test Composing: OK (Not Supported)
>> test Scaling: OK (Not Supported)
>>
>> Codec ioctls (Input 0):
>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>
>> Buffer ioctls (Input 0):
>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>> test VIDIOC_EXPBUF: OK
>> test Requests: OK (Not Supported)
>>
>> Test input 0:
>>
>> Streaming ioctls:
>> test read/write: OK
>> test blocking wait: OK
>> test MMAP (no poll): OK
>> test MMAP (select): OK
>> test MMAP (epoll): OK
>> test USERPTR (no poll): OK (Not Supported)
>> test USERPTR (select): OK (Not Supported)
>> test DMABUF: Cannot test, specify --expbuf-device
>>
>> Total for stm32-dcmi device /dev/video0: 51, Succeeded: 50, Failed: 1,
>> Warnings: 0
>>
>>
>> On 8/7/19 12:15 PM, Hans Verkuil wrote:
>>> Hi Hugues,
>>>
>>> Can you provide the output of the most recent v4l2-compliance?
>>>
>>> Use 'v4l2-compliance -s'.
>>>
>>> Also, just to confirm, with this v4 there are no /dev/mediaX or
>>> /dev/v4l-subdevX devices created anymore, right?
>>>
>>> This v4 looks good to me, I just want to have these final checks
>>> done.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>
>> Best regards,
>> Hugues.
>>
>
Best regards,
Hugues.
_______________________________________________
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] arm64/cache: silence -Woverride-init warnings
From: Mark Rutland @ 2019-08-08 10:38 UTC (permalink / raw)
To: Qian Cai
Cc: catalin.marinas, will, linux-kernel, linux-arm-kernel,
clang-built-linux
In-Reply-To: <20190808032916.879-1-cai@lca.pw>
On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC (and
> Clang) with -Winitializer-overrides),
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VIPT] = "VIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> 'icache_policy_str[2]')
> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_PIPT] = "PIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> 'icache_policy_str[3]')
> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VPIPT] = "VPIPT",
> ^~~~~~~
> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> 'icache_policy_str[0]')
>
> because it initializes icache_policy_str[0 ... 3] twice. Since
> arm64 developers are keen to keep the style of initializing a static
> array with a non-zero pattern first, just disable those warnings for
> both GCC and Clang of this file.
>
> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> Signed-off-by: Qian Cai <cai@lca.pw>
This is _not_ a fix, and should not require backporting to stable trees.
What about all the other instances that we have in mainline?
I really don't think that we need to go down this road; we're just going
to end up adding this to every file that happens to include a header
using this scheme...
Please just turn this off by default for clang.
If we want to enable this, we need a mechanism to permit overridable
assignments as we use range initializers for.
Thanks,
Mark.
> ---
> arch/arm64/kernel/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 478491f07b4f..397ed5f7be1e 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -11,6 +11,9 @@ CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
> CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
> CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
>
> +CFLAGS_cpuinfo.o += $(call cc-disable-warning, override-init)
> +CFLAGS_cpuinfo.o += $(call cc-disable-warning, initializer-overrides)
> +
> # Object file lists.
> obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> entry-fpsimd.o process.o ptrace.o setup.o signal.o \
> --
> 2.20.1 (Apple Git-117)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Will Deacon @ 2019-08-08 10:32 UTC (permalink / raw)
To: Mark Rutland
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, Maarten Lankhorst,
LKML, dri-devel, David Airlie, Rob Clark, linux-arm-kernel,
Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner, Sean Paul,
Christoph Hellwig, Allison Randal
In-Reply-To: <20190808102053.GA46901@lakrids.cambridge.arm.com>
On Thu, Aug 08, 2019 at 11:20:53AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > > For arm64, we can tear down portions of the linear map, but that has to
> > > be done explicitly, and this is only possible when using rodata_full. If
> > > not using rodata_full, it is not possible to dynamically tear down the
> > > cacheable alias.
> >
> > Interesting. For this or next merge window I plan to add support to the
> > generic DMA code to remap pages as uncachable in place based on the
> > openrisc code. Aѕ far as I can tell the requirement for that is
> > basically just that the kernel direct mapping doesn't use PMD or bigger
> > mapping so that it supports changing protection bits on a per-PTE basis.
> > Is that the case with arm64 + rodata_full?
>
> Yes, with the added case that on arm64 we can also have contiguous
> entries at the PTE level, which we also have to disable.
>
> Our kernel page table creation code does that for rodata_full or
> DEBUG_PAGEALLOC. See arch/arm64/mmu.c, in map_mem(), where we pass
> NO_{BLOCK,CONT}_MAPPINGS down to our pagetable creation code.
FWIW, we made rodata_full the default a couple of releases ago, so if
solving the cacheable alias for non-cacheable DMA buffers requires this
to be present, then we could probably just refuse to probe non-coherent
DMA-capable devices on systems where rodata_full has been disabled.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Stefan Agner @ 2019-08-08 10:30 UTC (permalink / raw)
To: Dave Martin
Cc: Marc Zyngier, ynorov, will.deacon, linux-arm-kernel,
suzuki.poulose
In-Reply-To: <20190808093522.GG10425@arm.com>
On 2019-08-08 11:35, Dave Martin wrote:
> On Thu, Aug 08, 2019 at 09:36:42AM +0200, Stefan Agner wrote:
>> [resend this time with the correct mailing list address]
>>
>> Hello,
>>
>> I am trying to detect whether an ARMv8 system running in AArch64 state
>> supports AArch32 state from a user space process. The arm64_features[]
>> in
>
> Why? Is this just for diagnostic purposes, or some programmatic reason?
The use case I currently have in mind is to decide whether to show
32-bit ARM Docker images in a UI (or arm32v7 images how it is nowadays
called in Docker land).
>
> In the latter case, just try to do what ever it is you want to do that
> depends on AArch32: if it fails, you don't have AArch32.
Yeah one option I considered was just fetching a minimalistic arm32v7
container, but still seems a bit excessive.
>
>> arch/arm64/kernel/cpufeature.c lists a CPU feature "32-bit EL0 Support".
>> However, afaik this CPU feature is not directly exposed to user-space.
>> The features do get printed in the kernel log, but that requires
>> privileges and only works directly after boot. There is
>
> Please don't scrape dmesg :)
>
> However, detecting AArch32 support is a bit annoying due to the fact
> that there's no hwcap or similar.
>
>> system_supports_32bit_el0() which is used in various places in the arm64
>> architecture code. One of the instances where I can make sense of from
>> user space is through the personality system call. One idea is to call
>> personality(PER_LINUX32). It would then return error code 22 in case
>> 32-bit is not supported in user space. However, if successful this
>> changes the personality of the current process which might have side
>> effects which I do not want...?
>>
>> I started to ask myself what PER_LINUX32 actually changes. From what I
>> can tell it only changes the behavior of /proc/cpuinfo? The personality
>> seems not to be applied automatically to 32-bit processes, so this is a
>> opt-in backward compatibility feature?
>
> Basically yes. Nonetheless, this is probably a reasonable way to test
> for AArch32 userspace support.
>
>> To be on the safe side, I was thinking about executing the system call
>> in a separate process. However, at that point I could also just execute
>> a statically linked AArch32 binary and see whether I get a "exec format
>> error". I guess this could then be either due to missing AArch32 CPU
>> support or the kernel not being compiled with 32-bit compatibility.
>
> personality() returns the old personality, so you providing you don't
> have multiple threads you can probably try to set it to PER_LINUX32
> and then restore it.
Yeah that is what Marc also suggested. Probably will go down this road.
>
> Otherwise, you would need to fork and try personality() from the child.
>
> Or as you suggest, try to exec a 32-bit binary.
>
>> At last I was considering reading directly from the CPU. But from what I
>> understand the register used in the kernel to determine 32-bit
>> compatibility (ID_AA64PFR0_EL1) is not accessible by user space (due to
>> the suffix _EL1).
>>
>> Any advice/thoughts on this topic?
>
> This register is emulated for userspace, so you can read it. However,
> the relevant field gets masked out, so this is probably not much use to
> you.
Argh, I see.
>
> We could expose the field, but a test that relies on it wouldn't be
> backwards compatible.
>
> If you just want to do this test from a script for diagnostic purposes
> and the filesystem has util-linux, then something like
>
> linux32 /bin/true
>
> might also work (this is effectively a scripted version of the
> personality(PER_LINUX32) test).
Wasn't aware of that one. Thanks!
Thanks for all the answers. Google really did not offer a lot about this
topic, and I am happy we have some options now publicly documented :-)
--
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 3/3] gpio: mpc8xxx: add ls1088a platform special function
From: Hui Song @ 2019-08-08 10:16 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
In-Reply-To: <20190808101628.36782-1-hui.song_1@nxp.com>
From: Song Hui <hui.song_1@nxp.com>
ls1028a and ls1088a platform share common special function.
The gpio hardware what they use is the same version.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
drivers/gpio/gpio-mpc8xxx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 1a680aa..16a47de 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -319,6 +319,7 @@ static const struct of_device_id mpc8xxx_gpio_ids[] = {
{ .compatible = "fsl,mpc5125-gpio", .data = &mpc5125_gpio_devtype, },
{ .compatible = "fsl,pq3-gpio", },
{ .compatible = "fsl,ls1028a-gpio", .data = &ls1028a_gpio_devtype, },
+ { .compatible = "fsl,ls1088a-gpio", .data = &ls1028a_gpio_devtype, },
{ .compatible = "fsl,qoriq-gpio", },
{}
};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 1/3] gpio: mpc8xxx: add ls1088a platform gpio node DT binding description
From: Hui Song @ 2019-08-08 10:16 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
ls1088a and ls1028a platform share common gpio node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index baf95d9..cd28e93 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a, ls1028a.
+ ls1021a, ls1043a, ls2080a, ls1028a, ls1088a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -39,10 +39,10 @@ gpio0: gpio@2300000 {
};
-Example of gpio-controller node for a ls1028a SoC:
+Example of gpio-controller node for a ls1028a/ls1088a SoC:
gpio1: gpio@2300000 {
- compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ compatible = "fsl,ls1028a-gpio", "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: fix gpio node
From: Hui Song @ 2019-08-08 10:16 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
In-Reply-To: <20190808101628.36782-1-hui.song_1@nxp.com>
From: Song Hui <hui.song_1@nxp.com>
Update the nodes to include little-endian
property to be consistent with the hardware
and add ls1088a gpio specify compatible.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 20f5ebd..d58d203 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -269,43 +269,47 @@
};
gpio0: gpio@2300000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio1: gpio@2310000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2310000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio2: gpio@2320000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2320000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio3: gpio@2330000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2330000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
ifc: ifc@2240000 {
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Mark Rutland @ 2019-08-08 10:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Allison Randal
In-Reply-To: <20190808102053.GA46901@lakrids.cambridge.arm.com>
On Thu, Aug 08, 2019 at 11:20:53AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > > For arm64, we can tear down portions of the linear map, but that has to
> > > be done explicitly, and this is only possible when using rodata_full. If
> > > not using rodata_full, it is not possible to dynamically tear down the
> > > cacheable alias.
> >
> > Interesting. For this or next merge window I plan to add support to the
> > generic DMA code to remap pages as uncachable in place based on the
> > openrisc code. Aѕ far as I can tell the requirement for that is
> > basically just that the kernel direct mapping doesn't use PMD or bigger
> > mapping so that it supports changing protection bits on a per-PTE basis.
> > Is that the case with arm64 + rodata_full?
>
> Yes, with the added case that on arm64 we can also have contiguous
> entries at the PTE level, which we also have to disable.
>
> Our kernel page table creation code does that for rodata_full or
> DEBUG_PAGEALLOC. See arch/arm64/mmu.c, in map_mem(), where we pass
> NO_{BLOCK,CONT}_MAPPINGS down to our pagetable creation code.
Whoops, that should be: arch/arm64/mm/mmu.c.
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Stefan Agner @ 2019-08-08 10:22 UTC (permalink / raw)
To: Will Deacon; +Cc: Marc Zyngier, ynorov, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190808091530.GA24506@fuggles.cambridge.arm.com>
On 2019-08-08 11:15, Will Deacon wrote:
> On Thu, Aug 08, 2019 at 10:04:27AM +0100, Marc Zyngier wrote:
>> On 08/08/2019 08:36, Stefan Agner wrote:
>> > I started to ask myself what PER_LINUX32 actually changes. From what I
>> > can tell it only changes the behavior of /proc/cpuinfo? The personality
>> > seems not to be applied automatically to 32-bit processes, so this is a
>> > opt-in backward compatibility feature?
>>
>> It's all about giving the illusion that the process runs in a "real"
>> 32bit environment, with all its warts. It doesn't change the CPU mode
>> you're running in (that'd be a bit harsh). It's only once you exec
>> something that requires AArch32 that we engage the COMPAT mode.
>>
>> Provided that your kernel contains 00377277166b or a backport of it (or
>> that it predates 4378a7d4be30), the following program should do the
>> right thing:
>>
>> #include <sys/personality.h>
>> #include <stdio.h>
>>
>> int main(int argc, char *argv[])
>> {
>> int old, new;
>>
>> old = personality(PER_LINUX32);
>> if (old < 0) {
>> perror("No 32bit for you");
>> return 1;
>> }
>>
>> new = personality(0xffffffff);
>> printf("Running with personality %d\n", new);
>>
>> personality(old);
>> new = personality(0xffffffff);
>>
>> printf("Running with personality %d\n", new);
>>
>> return 0;
>> }
>
> Or you can use the setarch/linux32 utility.
Wasn't aware of this utility. I guess something like this should work:
$ setarch linux32 true
Thanks for the pointer.
--
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Mark Rutland @ 2019-08-08 10:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Allison Randal
In-Reply-To: <20190808075827.GD30308@lst.de>
On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > For arm64, we can tear down portions of the linear map, but that has to
> > be done explicitly, and this is only possible when using rodata_full. If
> > not using rodata_full, it is not possible to dynamically tear down the
> > cacheable alias.
>
> Interesting. For this or next merge window I plan to add support to the
> generic DMA code to remap pages as uncachable in place based on the
> openrisc code. Aѕ far as I can tell the requirement for that is
> basically just that the kernel direct mapping doesn't use PMD or bigger
> mapping so that it supports changing protection bits on a per-PTE basis.
> Is that the case with arm64 + rodata_full?
Yes, with the added case that on arm64 we can also have contiguous
entries at the PTE level, which we also have to disable.
Our kernel page table creation code does that for rodata_full or
DEBUG_PAGEALLOC. See arch/arm64/mmu.c, in map_mem(), where we pass
NO_{BLOCK,CONT}_MAPPINGS down to our pagetable creation code.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Stefan Agner @ 2019-08-08 10:17 UTC (permalink / raw)
To: Marc Zyngier; +Cc: ynorov, will.deacon, linux-arm-kernel, suzuki.poulose
In-Reply-To: <7bfc8611-0b2c-9d6d-0348-afd580e2a403@arm.com>
On 2019-08-08 11:04, Marc Zyngier wrote:
> Hi Stefan,
>
> On 08/08/2019 08:36, Stefan Agner wrote:
>> [resend this time with the correct mailing list address]
>>
>> Hello,
>>
>> I am trying to detect whether an ARMv8 system running in AArch64 state
>> supports AArch32 state from a user space process. The arm64_features[]
>> in
>> arch/arm64/kernel/cpufeature.c lists a CPU feature "32-bit EL0 Support".
>> However, afaik this CPU feature is not directly exposed to user-space.
>> The features do get printed in the kernel log, but that requires
>> privileges and only works directly after boot. There is
>> system_supports_32bit_el0() which is used in various places in the arm64
>> architecture code. One of the instances where I can make sense of from
>> user space is through the personality system call. One idea is to call
>> personality(PER_LINUX32). It would then return error code 22 in case
>> 32-bit is not supported in user space. However, if successful this
>> changes the personality of the current process which might have side
>> effects which I do not want...?
>
> You should be able to revert the effects of PER_LINUX_32 by feeding back
> the return value of the initial call to personality() to a second
> personality() call.
>
Oh, of course, that makes sense.
>> I started to ask myself what PER_LINUX32 actually changes. From what I
>> can tell it only changes the behavior of /proc/cpuinfo? The personality
>> seems not to be applied automatically to 32-bit processes, so this is a
>> opt-in backward compatibility feature?
>
> It's all about giving the illusion that the process runs in a "real"
> 32bit environment, with all its warts. It doesn't change the CPU mode
> you're running in (that'd be a bit harsh). It's only once you exec
> something that requires AArch32 that we engage the COMPAT mode.
>
> Provided that your kernel contains 00377277166b or a backport of it (or
> that it predates 4378a7d4be30), the following program should do the
> right thing:
>
> #include <sys/personality.h>
> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
> int old, new;
>
> old = personality(PER_LINUX32);
> if (old < 0) {
> perror("No 32bit for you");
> return 1;
> }
>
> new = personality(0xffffffff);
> printf("Running with personality %d\n", new);
>
> personality(old);
> new = personality(0xffffffff);
>
> printf("Running with personality %d\n", new);
>
> return 0;
> }
>
Thanks for the example. I had something similar already, just not with
the revert part.
>> To be on the safe side, I was thinking about executing the system call
>> in a separate process. However, at that point I could also just execute
>> a statically linked AArch32 binary and see whether I get a "exec format
>> error". I guess this could then be either due to missing AArch32 CPU
>> support or the kernel not being compiled with 32-bit compatibility.
>
> Overkill ;-). The above should be enough.
>
>> At last I was considering reading directly from the CPU. But from what I
>> understand the register used in the kernel to determine 32-bit
>> compatibility (ID_AA64PFR0_EL1) is not accessible by user space (due to
>> the suffix _EL1).
>
> Hey, you could create a VM, a vcpu and dump the ID registers by issuing
> a set of KVM_GET_ONE_REG ioctls. Not necessarily recommended... ;-)
I see, no no, I think I leave that exercise for somebody else to try :)
--
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Oliver Neukum @ 2019-08-08 10:02 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Greg KH
Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <20190808095951.GD5193@shell.armlinux.org.uk>
Am Donnerstag, den 08.08.2019, 10:59 +0100 schrieb Russell King - ARM
Linux admin:
> On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote:
> > But the main issue here is what exactly is this "fixing"? What is wrong
> > with the existing code that non-x86 systems have such a problem with?
> > Shouldn't all of these dma issues be handled by the platform with the
> > remap_pfn_range() call itself?
>
> remap_pfn_range() takes a PFN. virt_to_phys() converts a kernel *direct
> mapped* virtual address to a physical address. That much is fine.
>
> The question is - what is usbm->mem? If that is anything other than an
> address returned by kmalloc() or from the normal page allocator, then
> virt_to_phys() will return garbage.
>
> In other words, if it comes from dma_alloc_coherent(), vmalloc() or
> ioremap(), using virt_to_phys() on it results in garbage.
It comes from usb_alloc_coherent() -> hcd_buffer_alloc() ->
hcd_buffer_alloc()
That function is a bit complicated. so I rather quote than explain:
if (hcd->localmem_pool)
return gen_pool_dma_alloc(hcd->localmem_pool, size, dma)
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
!is_device_dma_capable(bus->sysdev)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
if (size <= pool_max[i])
return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
}
return dma_alloc_coherent(hcd->self.sysdev, size, dma, mem_flags);
Regards
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Greg KH @ 2019-08-08 10:07 UTC (permalink / raw)
To: Robin Murphy; +Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <10bcb28b-e87b-7b16-97e3-88e727e76d25@arm.com>
On Thu, Aug 08, 2019 at 10:46:24AM +0100, Robin Murphy wrote:
> On 2019-08-08 9:58 am, Greg KH wrote:
> > On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
> > > Hello linux-usb and linux-arm.
> > >
> > > Ccing security@ because "the kernel dma code is mapping randomish
> > > kernel/user mem to a user process" seems to have security implications
> > > even though i didnt research that aspect past "its a 100% reliable way
> > > to crash a raspi from userspace".
> > >
> > > tried submitting this through linux-arm-kernel ~2 weeks ago but
> > > the only "response" i got was phishing-spam.
> > > tried to follow up through raspi-internals chat, they suggested
> > > i try linux-usb instead, but otoh the original reporter was
> > > deflected from -usb to "try some other mls, they might care".
> > > https://www.spinics.net/lists/linux-usb/msg173277.html
> > >
> > > if i am not following some arcane ritual or indenting convention required
> > > by regular users of these lists i apologize in advance, but i am not a
> > > kernel developer, i am just here as a user with a bug and a patch.
> > > (and the vger FAQ link 404s...)
> >
> > The "arcane ritual" should be really well documented by now, it's in
> > Documentation/SubmittingPatches in your kernel tree, and you can read it
> > online at:
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >
> >
> > > i rediffed against HEAD even though the two weeks old patch still applied
> > > cleanly with +2 offset.
> > >
> > > # stepping off soap box # actual technical content starts here #
> > >
> > > this is a followup to that thread from 2018-11:
> > > https://www.spinics.net/lists/arm-kernel/msg685598.html
> > >
> > > the issue was discussed in more detail than i can claim
> > > to fully understand back then, but no fix ever merged.
> > > but i would really like to use rtl_433 on a raspi without
> > > having to build a custom-patched kernel first.
> > >
> > > the attached patch is my stripdown/cleanup of a devel-diff
> > > provided to me by the original reporter Steve Markgraf.
> > > credits to him for the good parts, blame to me for the bad parts.
> > >
> > > this does not cover the additional case of "PIO-based usb controllers"
> > > mainly because i dont understand what that means (or how to handle it)
> > > and if its broken right now (as the thread indicates) it might
> > > as well stay broken until someone who understands cares enough.
> > >
> > > could you please get this on track for merging?
> >
> >
> > >
> > > regards,
> > > x23
> > >
> > >
> > >
> >
> > > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> > > index b265ab5405f9..69594c2169ea 100644
> > > --- a/drivers/usb/core/devio.c
> > > +++ b/drivers/usb/core/devio.c
> > > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
> > > usbm->vma_use_count = 1;
> > > INIT_LIST_HEAD(&usbm->memlist);
> > > +#ifdef CONFIG_X86
> > > if (remap_pfn_range(vma, vma->vm_start,
> > > virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> > > size, vma->vm_page_prot) < 0) {
> > > +#else /* !CONFIG_X86 */
> > > + if (dma_mmap_coherent(ps->dev->bus->sysdev,
> > > + vma, mem, dma_handle, size) < 0) {
> > > +#endif /* !CONFIG_X86 */
> > > dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
> > > return -EAGAIN;
> > > }
> >
> > First off, we need this in a format we could apply it in (hint, read the
> > above links).
> >
> > But the main issue here is what exactly is this "fixing"? What is wrong
> > with the existing code that non-x86 systems have such a problem with?
> > Shouldn't all of these dma issues be handled by the platform with the
> > remap_pfn_range() call itself?
>
> If usbm->mem is (or ever can be) a CPU address returned by
> dma_alloc_coherent(), then doing virt_to_phys() on it is bogus and may yield
> a nonsense 'PFN' to begin with. However, it it can can ever come from a
> regular page allocation/kmalloc/vmalloc then unconditionally passing it to
> dma_mmap_coherent wouldn't be right either.
usbm->mem comes from a call to usb_alloc_coherent() which calls
hcd_buffer_alloc() which tries to allocate memory in the best possible
way for that specific host controller. If the host controller has a
pool of memory, it uses that, if the host controller has PIO it uses
kmalloc(), if there are some "pools" of host controller memory it uses
dma_pool_alloc() and as a total last resort, calls dma_alloc_coherent().
So yes, this could happen.
So how to fix this properly? What host controller driver is being used
here that ends up defaulting to dma_alloc_coherent()? Shouldn't that be
fixed up no matter what?
And then, if what you say is correct then a real fix for devio.c could
be made, but that is NOT going to just depend on the arch the system is
running on, as all of this depends on the host controller being accessed
at that moment for that device.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Russell King - ARM Linux admin @ 2019-08-08 9:59 UTC (permalink / raw)
To: Greg KH; +Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <20190808085811.GA1265@kroah.com>
On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote:
> But the main issue here is what exactly is this "fixing"? What is wrong
> with the existing code that non-x86 systems have such a problem with?
> Shouldn't all of these dma issues be handled by the platform with the
> remap_pfn_range() call itself?
remap_pfn_range() takes a PFN. virt_to_phys() converts a kernel *direct
mapped* virtual address to a physical address. That much is fine.
The question is - what is usbm->mem? If that is anything other than an
address returned by kmalloc() or from the normal page allocator, then
virt_to_phys() will return garbage.
In other words, if it comes from dma_alloc_coherent(), vmalloc() or
ioremap(), using virt_to_phys() on it results in garbage.
This aspect of virt_to_phys() has been well known about for ages; it's
one of the fundamentals of kernel programming.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-08 10:00 UTC (permalink / raw)
To: Rob Clark
Cc: Sean Paul, Maxime Ripard, Catalin Marinas, Maarten Lankhorst,
LKML, dri-devel, David Airlie, Rob Clark, linux-arm-kernel,
Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner, Will Deacon,
Christoph Hellwig, Allison Randal
In-Reply-To: <CAJs_Fx7tqbr_gqRdqJEwOcRFReP0DqZzOu11Dxhxkp8+PygUQw@mail.gmail.com>
On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote:
> > > (Eventually I'd like to support pages passed in from userspace.. but
> > > that is down the road.)
> >
> > Eww. Please talk to the iommu list before starting on that.
>
> This is more of a long term goal, we can't do it until we have
> per-context/process pagetables, ofc.
>
> Getting a bit off topic, but I'm curious about what problems you are
> concerned about. Userspace can shoot it's own foot, but if it is not
> sharing GPU pagetables with other processes, it can't shoot other's
> feet. (I'm guessing you are concerned about non-page-aligned
> mappings?)
Maybe I misunderstood what you mean above, I though you mean messing
with page cachability attributes for userspace pages. If what you are
looking into is just "standard" SVM I only hope that our APIs for that
which currently are a mess are in shape by then, as all users currently
have their own crufty and at least slightly buggy versions of that. But
at least it is an issue that is being worked on.
> > So back to the question, I'd like to understand your use case (and
> > maybe hear from the other drm folks if that is common):
> >
> > - you allocate pages from shmem (why shmem, btw? if this is done by
> > other drm drivers how do they guarantee addressability without an
> > iommu?)
>
> shmem for swappable pages. I don't unpin and let things get swapped
> out yet, but I'm told it starts to become important when you have 50
> browser tabs open ;-)
Yes, but at that point the swapping can use the kernel linear mapping
and we are going into aliasing problems that can disturb the cache. So
as-is this is going to problematic without new hooks into shmemfs.
> > - then the memory is either mapped to userspace or vmapped (or even
> > both, althrough the lack of aliasing you mentioned would speak
> > against it) as writecombine (aka arm v6+ normal uncached). Does
> > the mapping live on until the memory is freed?
>
> (side note, *most* of the drm/msm supported devices are armv8, the
> exceptions are 8060 and 8064 which are armv7.. I don't think drm/msm
> will ever have to deal w/ armv6)
Well, the point was that starting from v6 the kernels dma uncached
really is write combine. So that applied to v7 and v8 as well.
_______________________________________________
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] ARM: dts: socfpga: Fix up button mapping on VINING FPGA
From: Marek Vasut @ 2019-08-08 9:39 UTC (permalink / raw)
To: Dinh Nguyen, linux-arm-kernel
In-Reply-To: <82f7df8c-fe96-9b62-598b-028c2ef2d0df@kernel.org>
On 8/7/19 4:10 PM, Dinh Nguyen wrote:
> Hi Marek,
>
> On 8/7/19 6:13 AM, Marek Vasut wrote:
>> On 6/28/19 2:19 AM, Marek Vasut wrote:
>>> Add missing buttons and signals to the VINING FPGA device tree,
>>> so they are presented to the userspace via gpio-keys evdev.
>>>
>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>> Cc: Dinh Nguyen <dinguyen@kernel.org>
>>
>> Bump ?
>>
>
> Sorry for being late on this. I've applied it and it was queued for
> v5.3, but I missed the merged window. It's queued for v5.4.
Cool, thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-08 9:55 UTC (permalink / raw)
To: Daniel Vetter
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
Linux ARM, Greg Kroah-Hartman, Thomas Gleixner, Will Deacon,
Christoph Hellwig, Allison Randal
In-Reply-To: <CAKMK7uH1O3q8VUftikipGH6ACPoT-8tbV1Zwo-8WL=wUHiqsoQ@mail.gmail.com>
On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> > other drm drivers how do they guarantee addressability without an
> > iommu?)
>
> We use shmem to get at swappable pages. We generally just assume that
> the gpu can get at those pages, but things fall apart in fun ways:
> - some setups somehow inject bounce buffers. Some drivers just give
> up, others try to allocate a pool of pages with dma_alloc_coherent.
> - some devices are misdesigned and can't access as much as the cpu. We
> allocate using GFP_DMA32 to fix that.
Well, for shmem you can't really call allocators directly, right?
One thing I have in my pipeline is a dma_alloc_pages API that allocates
pages that are guaranteed to be addressably by the device or otherwise
fail. But that doesn't really help with the shmem fs.
> Also modern gpu apis pretty much assume you can malloc() and then use
> that directly with the gpu.
Which is fine as long as the GPU itself supports full 64-bit addressing
(or always sits behind an iommu), and the platform doesn't impose
addressing limit, which unfortunately some that are shipped right now
still do :(
But userspace malloc really means dma_map_* anyway, so not really
relevant for memory allocations.
_______________________________________________
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 v2] firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
From: Philipp Zabel @ 2019-08-08 9:47 UTC (permalink / raw)
To: Sudeep Holla, linux-arm-kernel; +Cc: linux-kernel
In-Reply-To: <20190807173739.5939-1-sudeep.holla@arm.com>
On Wed, 2019-08-07 at 18:37 +0100, Sudeep Holla wrote:
> Instead of type-casting the {tx,rx}.buf all over the place while
> accessing them to read/write __le{32,64} from/to the firmware, let's
> use the existing {get,put}_unaligned_le{32,64} accessors to hide all
> the type cast ugliness.
>
> Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox