* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-12 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <80676b35-121b-0462-23fc-ed5608e1e671@grimberg.me>
On Thursday, January 12, 2017 12:09:11 PM CET Sagi Grimberg wrote:
> >> Another workaround me might need is to limit amount of concurrent DMA
> >> in the NVMe driver based on some platform quirk. The way that NVMe works,
> >> it can have very large amounts of data that is concurrently mapped into
> >> the device.
> >
> > That's not really just NVMe - other storage and network controllers also
> > can DMA map giant amounts of memory. There are a couple aspects to it:
> >
> > - dma coherent memoery - right now NVMe doesn't use too much of it,
> > but upcoming low-end NVMe controllers will soon start to require
> > fairl large amounts of it for the host memory buffer feature that
> > allows for DRAM-less controller designs. As an interesting quirk
> > that is memory only used by the PCIe devices, and never accessed
> > by the Linux host at all.
>
> Would it make sense to convert the nvme driver to use normal allocations
> and use the DMA streaming APIs (dma_sync_single_for_[cpu|device]) for
> both queues and future HMB?
That is an interesting question: We actually have the
"DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements
it in the coherent interface, so that might be a good fit.
Implementing it in the streaming API makes no sense since we
already have a kernel mapping here, but using a normal allocation
(possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC,
need to check) might help on other architectures that have
limited amounts of coherent memory and no CMA.
Another benefit of the coherent API for this kind of buffer is
that we can use CMA where available to get a large consecutive
chunk of RAM on architectures without an IOMMU when normal
memory is no longer available because of fragmentation.
Arnd
^ permalink raw reply
* [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
From: Will Deacon @ 2017-01-12 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112042143.GF20972@linaro.org>
On Thu, Jan 12, 2017 at 01:21:44PM +0900, AKASHI Takahiro wrote:
> On Wed, Jan 11, 2017 at 10:54:05AM +0000, Will Deacon wrote:
> > On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Jan 10, 2017 at 11:32:48AM +0000, Will Deacon wrote:
> > > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> > > > > @@ -22,6 +25,7 @@
> > > > > extern const unsigned char arm64_relocate_new_kernel[];
> > > > > extern const unsigned long arm64_relocate_new_kernel_size;
> > > > >
> > > > > +static bool in_crash_kexec;
> > > >
> > > > Do you actually need this bool? Why not call kexec_crash_loaded() instead?
> > >
> > > The two have different meanings:
> > > "in_crash_kexec" indicates that kdump is taking place, while
> > > kexec_crash_loaded() tells us only whether crash dump kernel has been
> > > loaded or not.
> > >
> > > It is crucial to distinguish them especially for machine_kexec()
> > > which can be called on normal kexec even if kdump has been set up.
> >
> > Ah, I see. So how about just doing:
> >
> > if (kimage == kexec_crash_image)
> >
> > in machine_kexec?
>
> Yeah, it should work.
> Do you want to merge the following hunk,
> or expect that I will re-send the whole patch series
> (with other changes if any)?
Thanks, I'll fold it in and shout if I run into any problems. My plan is
to queue this for 4.11.
Will
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-12 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2pW20VPP_yGtvJ_ufvj6Xj1poBiiA2WqkALiaLyyONug@mail.gmail.com>
Hello Cedric,
On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> > This is surprising. I didn't recheck the manual, but that looks very
> >> > uncomfortable.
> >>
> >> I agree but this exactly the hardware way of working described in the
> >> reference manual.
> >
> > IMHO that's a hw bug. This makes it for example impossible to implement
> > SMBus block transfers (I think).
>
> This is not correct.
> Setting STOP/START bit does not mean the the pulse will be sent right now.
> Here we have just to prepare the hardware for the 2 next pulse but the
> STOP/START/ACK pulse will be generated at the right time as required
> by I2C specification.
> So SMBus block transfer will be possible.
A block transfer consists of a byte that specifies the count of bytes
yet to come. So the device sends for example:
0x01 0xab
So when you read the 1 in the first byte it's already too late to set
STOP to get it after the 2nd byte.
Not sure I got all the required details right, though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: juno: Adds missing CoreSight STM component.
From: Sudeep Holla @ 2017-01-12 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0802MB2198449A31AD8624B48045428C790@DB6PR0802MB2198.eurprd08.prod.outlook.com>
On 12/01/17 11:24, Mike Leach wrote:
> Hi Sudeep,
>
> I'm fine with that - less duplication the better.
>
> I've not played with .dts files much to I hadn't realised that type
> of construction was possible.
>
OK I spent some time and I think we can do the same for other coresight
components too. I will modify post the series but I need your help to
validate the change running core-sight tests.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Marc Gonzalez @ 2017-01-12 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xlgugldws.fsf@unicorn.mansr.com>
On 12/01/2017 12:24, M?ns Rullg?rd wrote:
> Marc Gonzalez writes:
>
>>> So far we have a claim that a cast to a void * may somehow be different
>>> to a cast to a different pointer, if used as function argument, and that
>>> the behavior with such a cast may be undefined. In other words, you claim
>>> that a function implemented as, say,
>>>
>>> void func(int *var) {}
>>>
>>> might result in undefined behavior if some header file declares it as
>>>
>>> void func(void *);
>>>
>>> and it is called as
>>>
>>> int var;
>>>
>>> func(&var);
>>>
>>> That seems really far fetched to me.
>>
>> Thanks for giving me an opportunity to play the language lawyer :-)
>>
>> C99 6.3.2.3 sub-clause 8 states:
>>
>> "A pointer to a function of one type may be converted to a pointer to
>> a function of another type and back again; the result shall compare
>> equal to the original pointer. If a converted pointer is used to call
>> a function whose type is not compatible with the pointed-to type, the
>> behavior is undefined."
>>
>> So, the behavior is undefined, not when you cast clk_disable_unprepare,
>> but when clk_disable_unprepare is later called through the devres->action
>> function pointer.
>
> Only if the function types are incompatible. C99 6.7.5.3 subclause 15:
>
> For two function types to be compatible, both shall specify compatible
> return types. Moreover, the parameter type lists, if both are
> present, shall agree in the number of parameters and in use of the
> ellipsis terminator; corresponding parameters shall have compatible
> types.
>
> The question then is whether pointer to void and pointer to struct clk
> are compatible types.
6.2.7 Compatible type and composite type
sub-clause 1
"Two types have compatible type if their types are the same. Additional rules for
determining whether two types are compatible are described in 6.7.2 for type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for declarators."
6.7.5.1 Pointer declarators
sub-clause 2
"For two pointer types to be compatible, both shall be identically qualified and both shall
be pointers to compatible types."
I don't think void and struct clk are compatible types.
AFAIU, conversion and compatibility are two separate subjects.
Regards.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Will Deacon @ 2017-01-12 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com>
On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> index 5ac373c..480b644 100644
> >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> >>
> >> /* Objects are coherent, unless 'no shareability' flag set. */
> >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> >>
> >> /*
> >> * The device-specific probe callback will get invoked by device_add()
> >
> > Why are these actually calling arch_setup_dma_ops() here in the first
> > place? Are these all devices that are DMA masters without an OF node?
>
> I don't know, but that's a different topic. This patch just adds
> argument and sets it to false everywhere but in the location when range
> should be definitely enforced.
I also wouldn't lose any sleep over a staging driver.
Will
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-2-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> So we can have portable formatting of uint32_t types. However there is
> a catch. Different compilers can use legally subtly different types
> though so we need to probe the compiler defined intdef.h first.
Interesting, what platform has long uint32_t? I thought the issue was
whether 64-bit is long or "long long".
Paolo
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> Makefile | 1 +
> configure | 13 +++++++++++++
> lib/libcflat.h | 9 +++++++++
> 3 files changed, 23 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index a32333b..9822d9a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> CFLAGS += $(fno_stack_protector)
> CFLAGS += $(fno_stack_protector_all)
> CFLAGS += $(wno_frame_address)
> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>
> CXXFLAGS += $(CFLAGS)
>
> diff --git a/configure b/configure
> index 995c8fa..127868c 100755
> --- a/configure
> +++ b/configure
> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> ln -fs $testdir/run $testdir-run
> fi
>
> +# check if uint32_t needs a long format modifier
> +cat << EOF > lib_test.c
> +#include <inttypes.h>
> +EOF
> +
> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
> +exit=$?
> +if [ $exit -eq 0 ]; then
> + u32_long=true
> +fi
> +rm -f lib_test.c
> +
> # check for dependent 32 bit libraries
> if [ "$arch" != "arm" ]; then
> cat << EOF > lib_test.c
> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> FIRMWARE=$firmware
> ENDIAN=$endian
> PRETTY_PRINT_STACKS=$pretty_print_stacks
> +U32_LONG_FMT=$u32_long
> EOF
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index 380395f..e80fc50 100644
> --- a/lib/libcflat.h
> +++ b/lib/libcflat.h
> @@ -58,12 +58,21 @@ typedef _Bool bool;
> #define true 1
>
> #if __SIZEOF_LONG__ == 8
> +# define __PRI32_PREFIX
> # define __PRI64_PREFIX "l"
> # define __PRIPTR_PREFIX "l"
> #else
> +#if defined(__U32_LONG_FMT__)
> +# define __PRI32_PREFIX "l"
> +#else
> +# define __PRI32_PREFIX
> +#endif
> # define __PRI64_PREFIX "ll"
> # define __PRIPTR_PREFIX
> #endif
> +#define PRId32 __PRI32_PREFIX "d"
> +#define PRIu32 __PRI32_PREFIX "u"
> +#define PRIx32 __PRI32_PREFIX "x"
> #define PRId64 __PRI64_PREFIX "d"
> #define PRIu64 __PRI64_PREFIX "u"
> #define PRIx64 __PRI64_PREFIX "x"
>
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-5-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> README.md | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/README.md b/README.md
> index 5027b62..9462824 100644
> --- a/README.md
> +++ b/README.md
> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
> [format]
> subjectprefix = kvm-unit-tests PATCH
>
> +Please run the kernel's ./scripts/checkpatch.pl on new patches
Does it really work well on kvm-unit-tests?
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 6/6] run_tests: allow passing of options to QEMU
From: Paolo Bonzini @ 2017-01-12 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-7-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> This allows additional options to be passed to QEMU. It follows the
> convention of passing parameters after a -- to the child process. In
> my case I'm using it to toggle MTTCG on an off:
>
> ./run_tests.sh -- --accel tcg,thread=multi
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
> v1
> - changes from -o to --
> - fixed whitespace damage
> ---
> README.md | 6 ++++++
> run_tests.sh | 13 +++++++++++--
> scripts/functions.bash | 7 ++++---
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/README.md b/README.md
> index fa3a445..1bd6dcb 100644
> --- a/README.md
> +++ b/README.md
> @@ -55,6 +55,12 @@ To extend or disable the timeouts:
>
> TIMEOUT=0 ./run_tests.sh
>
> +Any arguments past the end-of-arguments marker (--) is passed on down
> +to the QEMU invocation. This can of course be combined with the other
> +modifiers:
> +
> + ACCEL=tcg ./run_tests.sh -v -- --accel tcg,thread=multi
> +
> # Contributing
>
> ## Directory structure
> diff --git a/run_tests.sh b/run_tests.sh
> index 254129d..3270fba 100755
> --- a/run_tests.sh
> +++ b/run_tests.sh
> @@ -13,7 +13,7 @@ function usage()
> {
> cat <<EOF
>
> -Usage: $0 [-g group] [-h] [-v]
> +Usage: $0 [-g group] [-h] [-v] [-- QEMU options]
>
> -g: Only execute tests in the given group
> -h: Output this help text
> @@ -22,6 +22,8 @@ Usage: $0 [-g group] [-h] [-v]
> Set the environment variable QEMU=/path/to/qemu-system-ARCH to
> specify the appropriate qemu binary for ARCH-run.
>
> +All options specified after -- are passed on to QEMU.
> +
> EOF
> }
>
> @@ -29,6 +31,7 @@ RUNTIME_arch_run="./$TEST_DIR/run"
> source scripts/runtime.bash
>
> while getopts "g:hv" opt; do
> +
> case $opt in
> g)
> only_group=$OPTARG
> @@ -46,6 +49,12 @@ while getopts "g:hv" opt; do
> esac
> done
>
> +# Any options left for QEMU?
> +shift $((OPTIND-1))
> +if [ "$#" -gt 0 ]; then
> + extra_opts="$@"
> +fi
> +
> RUNTIME_log_stderr () { cat >> test.log; }
> RUNTIME_log_stdout () {
> if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
> @@ -59,4 +68,4 @@ RUNTIME_log_stdout () {
> config=$TEST_DIR/unittests.cfg
> rm -f test.log
> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
> -for_each_unittest $config run
> +for_each_unittest $config run "$extra_opts"
> diff --git a/scripts/functions.bash b/scripts/functions.bash
> index ee9143c..60fbc6a 100644
> --- a/scripts/functions.bash
> +++ b/scripts/functions.bash
> @@ -3,10 +3,11 @@ function for_each_unittest()
> {
> local unittests="$1"
> local cmd="$2"
> + local extra_opts=$3
> local testname
> local smp
> local kernel
> - local opts
> + local opts=$extra_opts
> local groups
> local arch
> local check
> @@ -21,7 +22,7 @@ function for_each_unittest()
> testname=${BASH_REMATCH[1]}
> smp=1
> kernel=""
> - opts=""
> + opts=$extra_opts
> groups=""
> arch=""
> check=""
> @@ -32,7 +33,7 @@ function for_each_unittest()
> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
> smp=${BASH_REMATCH[1]}
> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
> - opts=${BASH_REMATCH[1]}
> + opts="$opts ${BASH_REMATCH[1]}"
> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
> groups=${BASH_REMATCH[1]}
> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
>
Great idea!
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Alex Bennée @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <322298cd-aefa-e945-d3f4-1237767a06ef@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> README.md | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/README.md b/README.md
>> index 5027b62..9462824 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
>> [format]
>> subjectprefix = kvm-unit-tests PATCH
>>
>> +Please run the kernel's ./scripts/checkpatch.pl on new patches
>
> Does it really work well on kvm-unit-tests?
Well I keep getting pulled up on kernel coding style on my reviews so if
we mean it we should enforce it.
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH 2/6] lib/pci: fix BAR format strings
From: Paolo Bonzini @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-3-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Using %x as a format string is not portable across 32/64 bit builds.
> Use explicit PRIx32 format strings like the 64 bit version above.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> lib/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/pci.c b/lib/pci.c
> index 6416191..597d8f2 100644
> --- a/lib/pci.c
> +++ b/lib/pci.c
> @@ -67,7 +67,7 @@ bool pci_setup_msi(struct pci_dev *dev, uint64_t msi_addr, uint32_t msi_data)
> pci_config_writel(addr, offset + PCI_MSI_DATA_32, msi_data);
> printf("MSI: dev 0x%x init 32bit address: ", addr);
> }
> - printf("addr=0x%lx, data=0x%x\n", msi_addr, msi_data);
> + printf("addr=0x%" PRIx64 ", data=0x%" PRIx32 "\n", msi_addr, msi_data);
Applying only the %lx -> %"PRIx64" change for now (though it's also in
Andrew's 32-bit compilation fixes patch).
Paolo
>
> msi_control |= PCI_MSI_FLAGS_ENABLE;
> pci_config_writew(addr, offset + PCI_MSI_FLAGS, msi_control);
> @@ -237,7 +237,7 @@ void pci_bar_print(struct pci_dev *dev, int bar_num)
> printf("BAR#%d,%d [%" PRIx64 "-%" PRIx64 " ",
> bar_num, bar_num + 1, start, end);
> } else {
> - printf("BAR#%d [%02x-%02x ",
> + printf("BAR#%d [%" PRIx32 "-%" PRIx32 " ",
> bar_num, (uint32_t)start, (uint32_t)end);
> }
>
>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-12 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4286b719-ff75-d2cd-68b5-cb9d9bb89553@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> So we can have portable formatting of uint32_t types. However there is
>> a catch. Different compilers can use legally subtly different types
>> though so we need to probe the compiler defined intdef.h first.
>
> Interesting, what platform has long uint32_t? I thought the issue was
> whether 64-bit is long or "long long".
I haven't run into that one. This came up with the arm-none-eabi-gcc on
my overdrive01 box. According to the toolchain guys there is no particular
reason a 32bit compiler can't use long for its natural word length.
The native compiler on Debian armhf doesn't do this but the
arm-none-eabi-gcc compilers on both 64bit and 32bit Debian need this.
>
> Paolo
>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> Makefile | 1 +
>> configure | 13 +++++++++++++
>> lib/libcflat.h | 9 +++++++++
>> 3 files changed, 23 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index a32333b..9822d9a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
>> CFLAGS += $(fno_stack_protector)
>> CFLAGS += $(fno_stack_protector_all)
>> CFLAGS += $(wno_frame_address)
>> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>>
>> CXXFLAGS += $(CFLAGS)
>>
>> diff --git a/configure b/configure
>> index 995c8fa..127868c 100755
>> --- a/configure
>> +++ b/configure
>> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
>> ln -fs $testdir/run $testdir-run
>> fi
>>
>> +# check if uint32_t needs a long format modifier
>> +cat << EOF > lib_test.c
>> +#include <inttypes.h>
>> +EOF
>> +
>> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>> +exit=$?
>> +if [ $exit -eq 0 ]; then
>> + u32_long=true
>> +fi
>> +rm -f lib_test.c
>> +
>> # check for dependent 32 bit libraries
>> if [ "$arch" != "arm" ]; then
>> cat << EOF > lib_test.c
>> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
>> FIRMWARE=$firmware
>> ENDIAN=$endian
>> PRETTY_PRINT_STACKS=$pretty_print_stacks
>> +U32_LONG_FMT=$u32_long
>> EOF
>> diff --git a/lib/libcflat.h b/lib/libcflat.h
>> index 380395f..e80fc50 100644
>> --- a/lib/libcflat.h
>> +++ b/lib/libcflat.h
>> @@ -58,12 +58,21 @@ typedef _Bool bool;
>> #define true 1
>>
>> #if __SIZEOF_LONG__ == 8
>> +# define __PRI32_PREFIX
>> # define __PRI64_PREFIX "l"
>> # define __PRIPTR_PREFIX "l"
>> #else
>> +#if defined(__U32_LONG_FMT__)
>> +# define __PRI32_PREFIX "l"
>> +#else
>> +# define __PRI32_PREFIX
>> +#endif
>> # define __PRI64_PREFIX "ll"
>> # define __PRIPTR_PREFIX
>> #endif
>> +#define PRId32 __PRI32_PREFIX "d"
>> +#define PRIu32 __PRI32_PREFIX "u"
>> +#define PRIx32 __PRI32_PREFIX "x"
>> #define PRId64 __PRI64_PREFIX "d"
>> #define PRIu64 __PRI64_PREFIX "u"
>> #define PRIx64 __PRI64_PREFIX "x"
>>
--
Alex Benn?e
^ permalink raw reply
* [GIT PULL] Ux500 PM fix from Arnd
From: Linus Walleij @ 2017-01-12 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
this was forgotten on my fixes branch, sorry. Please pull it
in for fixes in the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-fix-for-armsoc
for you to fetch changes up to f0e8faa7a5e894b0fc99d24be1b18685a92ea466:
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation (2017-01-12 13:25:39 +0100)
----------------------------------------------------------------
A single PM fix from Arnd
----------------------------------------------------------------
Arnd Bergmann (1):
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
arch/arm/mach-ux500/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL] Ux500 development for v4.11
From: Linus Walleij @ 2017-01-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
here is a set of two patches ready to be queued for v4.11 already.
Please pull them to a suitable branch on the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-dev-for-armsoc
for you to fetch changes up to f3c05596344fa09074220513583bc5d6ff2d5c43:
ARM: ux500: remove duplicated include from cpu-db8500.c (2017-01-12
14:02:34 +0100)
----------------------------------------------------------------
Some two collected patches simplifying some Ux500
stuff.
----------------------------------------------------------------
Linus Walleij (1):
ARM: ux500: simplify secondary boot
Wei Yongjun (1):
ARM: ux500: remove duplicated include from cpu-db8500.c
arch/arm/mach-ux500/cpu-db8500.c | 1 -
arch/arm/mach-ux500/platsmp.c | 45 +++++++++++++++++-----------------------
2 files changed, 19 insertions(+), 27 deletions(-)
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Christoph Hellwig @ 2017-01-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3306663.hKmLLq1hhl@wuerfel>
On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote:
> That is an interesting question: We actually have the
> "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements
> it in the coherent interface, so that might be a good fit.
Yes. my WIP HMB patch uses DMA_ATTR_NO_KERNEL_MAPPING, although I'm
workin on x86 at the moment where it's a no-op.
> Implementing it in the streaming API makes no sense since we
> already have a kernel mapping here, but using a normal allocation
> (possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC,
> need to check) might help on other architectures that have
> limited amounts of coherent memory and no CMA.
Though about that - but in the end DMA_ATTR_NO_KERNEL_MAPPING implies
those, so instead of using lots of flags in driver I'd rather fix
up more dma_ops implementations to take advantage of
DMA_ATTR_NO_KERNEL_MAPPING.
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-12 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111220235.GP14532@bhelgaas-glaptop.roam.corp.google.com>
On 01/11/2017 11:02 PM, Bjorn Helgaas wrote:
> Hi Uwe,
>
> On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
>> ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
>> is enabled:
>>
>> [...]
> We have several open issues related to ASPM:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=102311 ASPM: ASMEDA asm1062 not working
> https://bugzilla.kernel.org/show_bug.cgi?id=187731 Null pointer dereference in ASPM
> https://bugzilla.kernel.org/show_bug.cgi?id=189951 Enabling ASPM causes NIC performance issue
> https://bugzilla.kernel.org/show_bug.cgi?id=60111 NULL pointer deref in ASPM alloc_pcie_link_state()
>
> I don't recognize yours as being one of these. Can you open a new
> issue and attach the complete dmesg log and "lspci -vv" output?
Done: https://bugzilla.kernel.org/show_bug.cgi?id=192441
> Is this a regression?
As written in the bug report this also happens on 4.7.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/d9f681f1/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff9c81c2-90ef-a5c2-6f0b-c6cf5d0d11a9@arm.com>
On 2017/1/12 17:11, Marc Zyngier wrote:
> On 12/01/17 04:23, Ding Tianhong wrote:
>> Hi Marc:
>>
>> How about this v7, if any suggestions very grateful.
>
> It's been less than 5 days since you posted this. I'll get to it once I
> finish reviewing all the other patches that are sitting in the queue
> right before yours.
>
Ok and sorry for the noisy.
Thanks
Ding
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH 1/2][UPDATE] of: base: add support to get the number of cache levels
From: Rob Herring @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049616-22388-1-git-send-email-sudeep.holla@arm.com>
On Tue, Jan 10, 2017 at 6:00 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. This patch adds the support for the
> same.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 23 +++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..80e557eca858 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -25,6 +25,7 @@
> #include <linux/cpu.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> @@ -2268,6 +2269,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
> }
>
> /**
> + * of_count_cache_levels - Find the total number of cache levels for the
> + * given logical cpu
> + *
> + * @cpu: cpu number(logical index) for which cache levels is being counted
> + *
> + * Returns the total number of cache levels for the given logical cpu
> + */
> +int of_count_cache_levels(unsigned int cpu)
> +{
> + int level = 0;
> + struct device_node *np = of_cpu_device_node_get(cpu);
> +
> + while (np) {
> + level++;
This will return 1 if you have a cpu node and no cache nodes. Are you
assuming the cpu has a cache?
Perhaps you should just find the last level cache node and then just
read "cache-level".
Rob
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-12 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112121623.GH1771@arm.com>
On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote:
> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> index 5ac373c..480b644 100644
> > >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> > >>
> > >> /* Objects are coherent, unless 'no shareability' flag set. */
> > >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> > >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> > >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> > >>
> > >> /*
> > >> * The device-specific probe callback will get invoked by device_add()
> > >
> > > Why are these actually calling arch_setup_dma_ops() here in the first
> > > place? Are these all devices that are DMA masters without an OF node?
> >
> > I don't know, but that's a different topic. This patch just adds
> > argument and sets it to false everywhere but in the location when range
> > should be definitely enforced.
>
> I also wouldn't lose any sleep over a staging driver.
I think this is in the process of being moved out of staging, and
my question was about the other two as well:
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/iommu/rockchip-iommu.c
Arnd
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-12 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com>
On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote:
> >> Hmm, I think when the dma-ranges are missing, we should either enforce
> >> a 32-bit mask, or disallow DMA completely. It's probably too late for
> >> the latter, I wish we had done this earlier in order to force everyone
> >> on ARM64 to have a valid dma-ranges property for any DMA master.
> >
> > This can be done over time.
> >
> > However the very idea of this version of patch is - keep working pieces
> > as-is, thus for now setting enforce_range to false in case of no defined
> > dma-ranges is intentional.
>
> What we can do is - check bus width (as it is defined in DT) and set
> enforce_range to true if bus is 32-bit
>
> > What I should re-check is - does rcar dtsi set dma-ranges, and add it if
> > it does not.
>
> It does not, will have to add.
>
> In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
> Maybe DT needs fixing.
I think we always assumed that the lack of a dma-ranges property
implied a 32-bit width, as that is the safe fallback as well as the
most common case.
AFAICT, this means you are actually fine on rcar, and all other
platforms will keep working as we enforce it, but might get slowed
down if they relied on the unintended behavior of allowing 64-bit
DMA.
Arnd
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3013606.q8hexDUEqF@wuerfel>
>>>> Hmm, I think when the dma-ranges are missing, we should either enforce
>>>> a 32-bit mask, or disallow DMA completely. It's probably too late for
>>>> the latter, I wish we had done this earlier in order to force everyone
>>>> on ARM64 to have a valid dma-ranges property for any DMA master.
>>>
>>> This can be done over time.
>>>
>>> However the very idea of this version of patch is - keep working pieces
>>> as-is, thus for now setting enforce_range to false in case of no defined
>>> dma-ranges is intentional.
>>
>> What we can do is - check bus width (as it is defined in DT) and set
>> enforce_range to true if bus is 32-bit
>>
>>> What I should re-check is - does rcar dtsi set dma-ranges, and add it if
>>> it does not.
>>
>> It does not, will have to add.
>>
>> In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
>> Maybe DT needs fixing.
>
> I think we always assumed that the lack of a dma-ranges property
> implied a 32-bit width, as that is the safe fallback as well as the
> most common case.
Yes we assumed that, but that was combined with blindly accepting wider
dma_mask per driver's request. Later is being changed.
> AFAICT, this means you are actually fine on rcar, and all other
> platforms will keep working as we enforce it, but might get slowed
> down if they relied on the unintended behavior of allowing 64-bit
> DMA.
Yesterday Robin raised issue that a change starting to enforce default
dma_mask will break existing setups - i.e. those that depend in 64bit
DMA being implicitly supported without manually declaring such support.
In reply to that, I suggested this version of patchset that should keep
existing behavior by default.
I'm fine with both approaches regarding behavior on hw that I don't have
- but I'm not in position to make any decisions on that.
^ permalink raw reply
* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Christoph Hellwig @ 2017-01-12 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111181853.GA14532@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Jan 11, 2017 at 12:18:53PM -0600, Bjorn Helgaas wrote:
> Unless Christoph objects, I'll apply this, but I don't understand the
> situation with 17a51f12cfbd. That commit doesn't check for EINVAL or
> ENOSPC so I don't know what the connection with this patch is.
I don't think that commit is the culprit.
> I know Christoph said he changed something in ahci to treat all errors
> the same, but I don't know where that is, either.
"ahci: always fall back to single-MSI mode"
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Robin Murphy @ 2017-01-12 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3273119.LjYLKcrNcz@wuerfel>
On 12/01/17 13:25, Arnd Bergmann wrote:
> On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote:
>> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
>>>>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> index 5ac373c..480b644 100644
>>>>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>>>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>>>>
>>>>> /* Objects are coherent, unless 'no shareability' flag set. */
>>>>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>>>>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>>>>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>>>>
>>>>> /*
>>>>> * The device-specific probe callback will get invoked by device_add()
>>>>
>>>> Why are these actually calling arch_setup_dma_ops() here in the first
>>>> place? Are these all devices that are DMA masters without an OF node?
>>>
>>> I don't know, but that's a different topic. This patch just adds
>>> argument and sets it to false everywhere but in the location when range
>>> should be definitely enforced.
>>
>> I also wouldn't lose any sleep over a staging driver.
>
> I think this is in the process of being moved out of staging, and
> my question was about the other two as well:
The fsl-mc is actually a sort-of-bus-controller probing and configuring
its (directly DMA-capable) child devices, so is in fact legitimate here.
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
That one is completely bogus, and should just go away.
> drivers/iommu/rockchip-iommu.c
That one is part of some ugly trickery involving creating a fake device
to represent multiple separate IOMMU devices. The driver could probably
be reworked to not need it (the Exynos IOMMU handles a similar situation
without such tricks), but it's non-trivial.
Robin.
>
> Arnd
>
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112120309.fmrt2lwz3vklqmti@pengutronix.de>
2017-01-12 13:03 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> > uncomfortable.
>> >>
>> >> I agree but this exactly the hardware way of working described in the
>> >> reference manual.
>> >
>> > IMHO that's a hw bug. This makes it for example impossible to implement
>> > SMBus block transfers (I think).
>>
>> This is not correct.
>> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> Here we have just to prepare the hardware for the 2 next pulse but the
>> STOP/START/ACK pulse will be generated at the right time as required
>> by I2C specification.
>> So SMBus block transfer will be possible.
>
> A block transfer consists of a byte that specifies the count of bytes
> yet to come. So the device sends for example:
>
> 0x01 0xab
>
> So when you read the 1 in the first byte it's already too late to set
> STOP to get it after the 2nd byte.
>
> Not sure I got all the required details right, though.
Ok I understand your use case but I always think that the harware manages it.
If I take the above example, the I2C SMBus block read transaction will
be as below:
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
The first message is a single byte-transmission so there is no problem.
The second message is a N-byte reception with N = 3
When the I2C controller has finished to send the device address (S
Addr Rd), the ADDR flag is set and an interrupt is raised.
In the routine that handles ADDR event, we set ACK bit in order to
generate ACK pulse as soon as a data byte is received in the shift
register and then we clear the ADDR flag.
Please note that the SCL line is stretched low until ADDR flag is cleared.
So, as far I understand, the device could not sent any data as long as
the SCL line is stretched low. Right ?
Then, as soon as the SCL line is high, the device could send the first
data byte (Count).
When this byte is received in the shift register, an ACK is
automatically generated as defined during adress match phase and the
data byte is pushed in DR (data register).
Then, an interrupt is raised as RXNE (RX not empty) flag is set.
In the routine that handles RXNE event, as N=3, we just clear all
buffer interrupts in order to avoid another system preemption due to
RXNE event but we does not read the data in DR.
After receiving the ACK, the device could send the second data byte (Data1).
When this byte is received in the shift register, an ACK is
automatically generated.
As the first data byte has not been read yet in DR, the BTF (Byte
Transfer Finihed) flag is set and an interrupt is raised.
So, in that case, the SCL line is also streched low as long as the
data register has not been read.
In the routine that handle BTF event, we enable NACK in order to
generate this pulse as soon as the last data byte will be received and
then we read DR register ([Count])
At this moment, SCL line is released and the device could send the
last data byte.
After receiving the ACK, the device could send the third and last data
byte (Data2)
When this byte is received in the shift register, a NACK is
automatically generated as we enable it as explained above.
As the second data byte (Data1) has not been read yet in DR, the BTF
flag is set again and an interrupt is raised.
The SCL line is stretched low and in that way we could set the STOP
bit to generate this pulse.
Then we run 2 consecutives read of DR to retrieve [Data1] and [Data2]
and to set SCL high.
So, thanks to SCL stretching, it seems that NA and P will be generated
at the right time.
Please let me know if it is not correct.
Best regards,
Cedric
^ permalink raw reply
* [PATCH] usb: dwc3: exynos: Remove MODULE_ALIAS()
From: Javier Martinez Canillas @ 2017-01-12 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Exynos is DT-only, so there's no need for a platform MODALIAS.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/usb/dwc3/dwc3-exynos.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e27899bb5706..2e555a69c8ab 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -288,7 +288,6 @@ static struct platform_driver dwc3_exynos_driver = {
module_platform_driver(dwc3_exynos_driver);
-MODULE_ALIAS("platform:exynos-dwc3");
MODULE_AUTHOR("Anton Tikhomirov <av.tikhomirov@samsung.com>");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DesignWare USB3 EXYNOS Glue Layer");
--
2.7.4
^ permalink raw reply related
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