According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split RB in:
msgtype <- (RB) 32:36
payload <- (RB) 37:63
t <- (RB) 57:63
The current way of getting 'msgtype', and 't' is missing their LSB:
msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32
t: (arg &= 0x3f)
Introduce a targetWWPN field to several MADs. Its possible that a scsi
ID of a target can change due to some fabric changes. The WWPN of the
scsi target provides a better way to identify the target. Also, add
flags for receiving MAD versioning information and advertising client
support for targetWW
The virtual FC frame command exchaned with the VIOS is used for device
reset and command abort TMF as well as normally queued commands. When
initializing the ibmvfc_cmd there several elements of the command that
are set the same way regardless of the command type.
Deduplicate code by moving these
The previous patch added support for the targetWWPN field in version 2
MADs and vfcFrame structures.
Set the IBMVFC_CAN_SEND_VF_WWPN bit in our capabailites flag during NPIV
Login to inform the VIOS that this client supports this feature.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/
Both ibmvfc_show_host_(capabilities|npiv_version) functions retrieve
values from vhost->login_buf.resp buffer. This is the MAD response
buffer from the VIOS and as such any multi-byte non-string values are in
big endian format.
Byte swap these values to host cpu endian format for better human
read
The FC iu and response payloads are located at different offsets
depending on the ibmvfc_cmd version. This is a result of the version 2
vfcFrame definition adding an extra 64bytes of reserved space to the
structure prior to the payloads.
Add helper routines to determine the current vfcFrame versio
Several version 2 MADs and the version 2 vfcFrame structures introduced
a new targetWWPN field for better identification of the target then
simply the scsi_id.
Set this field and MAD versioning fields when the VIOS advertises the
IBMVFC_HANDLE_VF_WWPN capability.
Signed-off-by: Tyrel Datwyler
--
From: "Steven Rostedt (VMware)"
This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file
"recursed_functions" all the functions that caused recursion while a
callback to the function tracer was running.
Link: https://lkml.kernel.org/r/20201106023548.102375...@goodmis.org
Cc: Masami H
From: "Steven Rostedt (VMware)"
If a ftrace callback does not supply its own recursion protection and
does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will
make a helper trampoline to do so before calling the callback instead of
just calling the callback directly.
The default
CC Rashmica Gupta
On Wed, 2020-11-11 at 16:55 +1100, Jordan Niethe wrote:
> The hardware trace macros which use the memory provided by memtrace are
> able to use trace sizes as small as 16MB. Only memblock aligned values
> can be removed from each NUMA node by writing that value to
> memtrace/ena
On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available lega
On Wed, Nov 11, 2020 at 01:16:40PM -0600, Rob Herring wrote:
> On Wed, 11 Nov 2020 12:08:36 +0300, Serge Semin wrote:
> > There can be three distinctive types of the USB controllers: USB hosts,
> > USB peripherals/gadgets and USB OTG, which can switch from one role to
> > another. In order to have
On Wed, 11 Nov 2020 12:08:36 +0300, Serge Semin wrote:
> There can be three distinctive types of the USB controllers: USB hosts,
> USB peripherals/gadgets and USB OTG, which can switch from one role to
> another. In order to have that hierarchy handled in the DT binding files,
> we need to collect
Hi Nicholas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on asm-generic/master linus/master v5.10-rc3
next-2020]
[cannot apply to scottwood/next]
[If your patch is applied to the wrong git tree, kindly drop us a note
Let's use alloc_contig_pages() for allocating memory and remove the
linear mapping manually via arch_remove_linear_mapping(). Mark all pages
PG_offline, such that they will definitely not get touched - e.g.,
when hibernating. When freeing memory, try to revert what we did.
The original idea was di
Let's revert what we did in case seomthing goes wrong and we return an
error - as already done on arm64 and s390x.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Rashmica Gupta
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Wei Yang
Sig
The single caller (arch_remove_linear_mapping()) prints a proper warning
when this function fails. No need to eventually crash the kernel - let's
drop this WARN_ON.
Suggested-by: Oscar Salvador
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Rashmica Gupta
Cc: Andrew Mo
Let's print a warning similar to in arch_add_linear_mapping() instead of
WARN_ON_ONCE() and eventually crashing the kernel.
Reviewed-by: Oscar Salvador
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Rashmica Gupta
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Michal Hocko
This code currently relies on mem_hotplug_begin()/mem_hotplug_done() -
create_section_mapping()/remove_section_mapping() implementations
cannot tollerate getting called concurrently.
Let's prepare for callers (memtrace) not holding any such locks (and
don't force them to mess with memory hotplug l
We want to stop abusing memory hotplug infrastructure in memtrace code
to perform allocations and remove the linear mapping. Instead we will use
alloc_contig_pages() and remove the linear mapping manually.
Let's factor out creating/removing the linear mapping into
arch_create_linear_mapping() / ar
It's very easy to crash the kernel right now by simply trying to enable
memtrace concurrently, hammering on the "enable" interface
loop.sh:
#!/bin/bash
dmesg --console-off
while true; do
echo 0x4000 > /sys/kernel/debug/powerpc/memtrace/enable
done
[root@localhost ~]# loop.
We currently leak kernel memory to user space, because memory offlining
doesn't do any implicit clearing of memory and we are missing explicit
clearing of memory.
Let's keep it simple and clear pages before removing the linear mapping.
Reproduced in QEMU/TCG with 10 GiB of main memory:
[root@lo
Based on latest linux/master
powernv/memtrace is the only in-kernel user that rips out random memory
it never added (doesn't own) in order to allocate memory without a
linear mapping. Let's stop abusing memory hot(un)plug infrastructure for
that - use alloc_contig_pages() for allocating memory and
On Wed, Nov 11, 2020 at 02:39:01PM +0100, Christophe Leroy wrote:
> Hello,
>
> Le 11/11/2020 à 12:07, Nicholas Piggin a écrit :
> > This passes atomic64 selftest on ppc32 on qemu (uniprocessor only)
> > both before and after powerpc is converted to use ARCH_ATOMIC.
>
> Can you explain what this c
Hello,
Le 11/11/2020 à 12:07, Nicholas Piggin a écrit :
This passes atomic64 selftest on ppc32 on qemu (uniprocessor only)
both before and after powerpc is converted to use ARCH_ATOMIC.
Can you explain what this change does and why it is needed ?
Christophe
Signed-off-by: Nicholas Piggin
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls.
This will create
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for xtensa.
Signed-off-by: YiFei Zhu
---
arch/xtensa/include/asm/Kbuild| 1 -
arch/xtensa/include/asm/seccomp.h | 11 +++
2 f
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for sh.
Signed-off-by: YiFei Zhu
---
arch/sh/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/sh
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for riscv.
Signed-off-by: YiFei Zhu
---
arch/riscv/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/a
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for s390.
Signed-off-by: YiFei Zhu
---
arch/s390/include/asm/seccomp.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/s
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.
__LITTLE_ENDIAN__ is used here instead of CONFIG_CPU_LITTLE_ENDIAN
to keep it consistent with asm/syscall.h.
Signed-off-by: Yi
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.
Signed-off-by: YiFei Zhu
---
arch/parisc/include/asm/Kbuild| 1 -
arch/parisc/include/asm/seccomp.h | 22
From: YiFei Zhu
This patch series enables bitmap cache for the remaining arches with
SECCOMP_FILTER, other than MIPS.
I was unable to find any of the arches having subarch-specific NR_syscalls
macros, so generic NR_syscalls is used. SH's syscall_get_arch seems to
only have the 32-bit subarch imp
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.
Signed-off-by: YiFei Zhu
---
arch/csky/include/asm/Kbuild| 1 -
arch/csky/include/asm/seccomp.h | 11 +++
2 files c
On 04.11.20 10:42, osalvador wrote:
On Thu, Oct 29, 2020 at 05:27:16PM +0100, David Hildenbrand wrote:
Let's print a warning similar to in arch_add_linear_mapping() instead of
WARN_ON_ONCE() and eventually crashing the kernel.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
On 04.11.20 13:11, Oscar Salvador wrote:
On Wed, Nov 04, 2020 at 02:06:51PM +0200, Mike Rapoport wrote:
On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
Let's revert what we did in case seomthing goes wrong and we ret
read_user_stack_slow that walks user address translation by hand is
only required on hash, because a hash fault can not be serviced from
"NMI" context (to avoid re-entering the hash code) so the user stack
can be mapped into Linux page tables but not accessible by the CPU.
Radix MMU mode does not
All the cool kids are doing it.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/atomic.h | 681 ++---
arch/powerpc/include/asm/cmpxchg.h | 62 +--
2 files changed, 248 insertions(+), 495 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/po
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index 563faa10bb66..685d7bb3d26f 100644
--- a/arch/powerpc/mm/book3s64/iommu_api
This passes atomic64 selftest on ppc32 on qemu (uniprocessor only)
both before and after powerpc is converted to use ARCH_ATOMIC.
Signed-off-by: Nicholas Piggin
---
include/asm-generic/atomic64.h | 70 +++---
lib/atomic64.c | 36 -
2 fi
This conversion seems to require generic atomic64 changes, looks
like nothing else uses ARCH_ATOMIC and GENERIC_ATOMIC64 yet.
Thanks,
Nick
Nicholas Piggin (3):
asm-generic/atomic64: Add support for ARCH_ATOMIC
powerpc/64s/iommu: don't use atomic_ function on atomic64_t type
powerpc: rewrite
There is no need for this to be in asm, use the new intrrupt entry wrapper.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 15 +
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/include/asm/thread_info.h | 6
arch/powerpc/kernel/exceptions-64
There is no need for this to be in asm, use the new intrrupt entry wrapper.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 7 +++
arch/powerpc/kernel/exceptions-64s.S | 18 --
2 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/pow
Saving and restoring soft-mask state can now be done in C using the
interrupt handler wrapper functions.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 26
arch/powerpc/kernel/exceptions-64s.S | 60
2 files changed, 26 insertio
This moves the common NMI entry and exit code into the interrupt handler
wrappers.
This changes the behaviour of soft-NMI (watchdog) and HMI interrupts, and
also MCE interrupts on 64e, by adding missing parts of the NMI entry to
them. It fixes a bug with sreset on pseries HPT guests which shouldn'
There is no need for this to be in asm, use the new intrrupt entry wrapper.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 7 +++
arch/powerpc/include/asm/ppc_asm.h | 24
arch/powerpc/kernel/exceptions-64e.S | 1 -
arch/powerpc/kernel/e
There is no need for this to be in asm, use the new intrrupt entry wrapper.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 15 +++
arch/powerpc/kernel/exceptions-64s.S | 26 --
2 files changed, 11 insertions(+), 30 deletions(-)
diff
This will be used by interrupt entry as well.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/cputime.h | 15 +++
arch/powerpc/kernel/syscall_64.c | 10 +-
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch
The interrupt handler wrapper functions are not the ideal place to
maintain context tracking because after they return, the low level exit
code must then determine if there are interrupts to replay, or if the
task should be preempted, etc. Those paths (e.g., schedule_user) include
their own excepti
Move irq_enter/irq_exit into asynchronous interrupt handler wrappers.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 2 ++
arch/powerpc/kernel/dbell.c | 3 +--
arch/powerpc/kernel/irq.c| 4
arch/powerpc/kernel/tau_6xx.c| 3 ---
arch/po
Previously context tracking was not done for asynchronous interrupts,
(those that run in interrupt context), and if those would cause a
reschedule when they exit, then scheduling functions (schedule_user,
preempt_schedule_irq) call exception_enter/exit to fix this up and
exit user context.
This is
This moves exception_enter/exit calls to wrapper functions for
synchronous interrupts. More interrupt handlers are covered by
this than previously.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 9
arch/powerpc/kernel/traps.c | 74 ++---
Add context tracking to the system call handler explicitly, and remove
_TIF_NOHZ.
This saves 35 cycles on gettid system call cost on POWER9 with a
CONFIG_NOHZ_FULL kernel.
Signed-off-by: Nicholas Piggin
---
arch/Kconfig | 6 --
arch/powerpc/Kconfig
Simple helper for synchronous interrupt handlers to use to enable
interrupts if they were taken in interrupt-enabled context.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 7 +++
arch/powerpc/kernel/traps.c | 24 +++-
arch/powerpc/mm/
Add wrapper functions (derived from x86 macros) for interrupt handler
functions. This allows interrupt entry code to be written in C.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/asm-prototypes.h | 29 ---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 -
arch/powerpc/in
These will be used by subsequent patches.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/interrupt.h | 66
1 file changed, 66 insertions(+)
diff --git a/arch/powerpc/include/asm/interrupt.h
b/arch/powerpc/include/asm/interrupt.h
index 04b7bdf97a44..3a9
This is required in order to allow more significant differences between
NMI type interrupt handlers and regular asynchronous handlers.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/traps.c | 31 +++-
arch/powerpc/perf/core-book3s.c | 35 ++--
This also moves the 32s DABR match to C.
Similar to the previous patch this makes interrupt handler function
types more regular so they can be wrapped with the next patch.
bad_page_fault and do_break are not performance critical.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/bug.
Make mm fault handlers all just take the pt_regs * argument and load
DAR/DSISR from that. Make those that return a value return long.
This is done to make the function signatures match other handlers, which
will help with a future patch to add wrappers. Explicit arguments could
be added for perfor
The page fault handling still has some complex logic particularly around
hash table handling, in asm. Implement this in C instead.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 +
arch/powerpc/include/asm/bug.h| 1 +
arch/powerpc/kernel/
This adds interrupt handler wrapper functions, similar to the
generic / x86 code, and moves several common operations into them
from either asm or open coded in the individual handlers.
Since v1:
- Fixed a couple of compile issues
- Fixed perf weirdness (sometimes NMI, sometimes not)
- Also move i
On Wed, Nov 11, 2020 at 10:34:10AM +0100, Krzysztof Kozlowski wrote:
> On Wed, 11 Nov 2020 at 10:32, Serge Semin
> wrote:
> >
> > On Wed, Nov 11, 2020 at 10:16:28AM +0100, Krzysztof Kozlowski wrote:
> > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > > > DWC USB3 DT node is supp
On Wed, 11 Nov 2020 at 10:32, Serge Semin
wrote:
>
> On Wed, Nov 11, 2020 at 10:16:28AM +0100, Krzysztof Kozlowski wrote:
> > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> > > Controller schema, but with addi
On Wed, Nov 11, 2020 at 10:16:28AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> > Controller schema, but with additional vendor-specific properties, the
> > controller-specif
On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available lega
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctl
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible st
Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate the
Qualcomm DWC3 sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be n
TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3
compatible sub-node to describe a fully functioning USB interface.
Since DWC USB3 has now got a DT schema describing its DT node, let's make
sure the TI Keystone DWC3 sub-node passes validation against it.
Signed-off-by: Serge Semi
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the
generic DWC USB2 and USB3 devices. Since now we've got DT schemas for
both of the later IP cores let's make sure that the Amlogic G12A USB
DT nodes are fully evaluated including the DWC sub-nodes.
Signed-off-by: Serge Semin
Revi
An empty snps,quirk-frame-length-adjustment won't cause any change
performed by the driver. Moreover the DT schema validation will fail,
since it expects the property being assigned with some value. So set
fix the example by setting a valid FL-adj value in accordance with
Neil Armstrong comment.
L
The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc
expects the DWC USB3 DT node to have the compatible string with the
"synopsys" vendor prefix. Let's add the corresponding compatible string to
the controller DT schema, but mark it as deprecated seeing the Synopsys,
Inc. is
In accordance with the driver comments the PIPE3 de-emphasis can be tuned
to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis
property constraints so the DT schema would make sure the controller DT
node is equipped with correct value.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herri
DWC USB3 DT node is supposed to be compliant with the Generic xHCI
Controller schema, but with additional vendor-specific properties, the
controller-specific reference clocks and PHYs. So let's convert the
currently available legacy text-based DWC USB3 bindings to the DT schema
and make sure the DW
In accordance with the IP core databook the
snps,quirk-frame-length-adjustment property can be set within [0, 0x3F].
Let's make sure the DT schema applies a correct constraints on the
property.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/usb/snps,dw
With minor peculiarities (like uploading some vendor-specific firmware)
these are just Generic xHCI controllers fully compatible with its
properties. Make sure the Renesas USB xHCI DT nodes are also validated
against the Generic xHCI DT schema.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
Currently the DT bindings of Generic xHCI Controllers are described by
means of the legacy text file. Since such format is deprecated in favor of
the DT schema, let's convert the Generic xHCI Controllers bindings file to
the corresponding yaml files. There will be two of them: a DT schema for
the x
For some reason the "brcm,xhci-brcm-v2" compatible string has been missing
in the original bindings file. Add it to the Generic xHCI Controllers DT
schema since the controller driver expects it to be supported.
Signed-off-by: Serge Semin
Acked-by: Florian Fainelli
Reviewed-by: Rob Herring
---
The controller driver supports two types of DWC USB3 devices: with a
common interrupt lane and with individual interrupts for each mode. Add
support for both these cases to the DWC USB3 DT schema.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Grammar fix: "s/both of t
The generic USB properties have been described in the legacy bindings
text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
convert its content into the generic USB, USB HCD and USB DRD DT
schemas. So the Generic USB schema will be applicable to all USB
controllers, USB HCD - for the
Even though the Generic PHY framework is the more preferable way of
setting the USB PHY up, there are still many dts-files and DT bindings
which rely on having the legacy "usb-phy" specified to attach particular
USB PHYs to USB cores. Let's have the "usb-phy" property described in
the generic USB H
There are only four OTG revisions are currently supported by the kernel:
0x0100, 0x0120, 0x0130, 0x0200. Any another value is considered as
invalid.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v4:
- Move the constraints to the usb-drd.yaml schema where the otg-rev
prope
The host controller device might be designed to work for the particular
products or applications. In that case its DT node is supposed to be
equipped with the tpl-support property.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Grammar fix: "s/it'/its"
- Discard '|' fr
There can be three distinctive types of the USB controllers: USB hosts,
USB peripherals/gadgets and USB OTG, which can switch from one role to
another. In order to have that hierarchy handled in the DT binding files,
we need to collect common properties in a common DT schema and specific
properties
We've performed some work on the Generic USB HCD, xHCI and DWC USB3 DT
bindings in the framework of the Baikal-T1 SoC support integration into
the kernel. This patchset is a result of that work.
First of all we moved the generic USB properties from the legacy text
bindings to the USB DT schema. Th
Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types
that can be specified in the phy_type HCD property. Add them to the
enumeration of the acceptable values.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Grammar fix: "s/PHY types can be/PHY types that
86 matches
Mail list logo
