* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Marc Gonzalez @ 2017-01-11 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a61eb838-4167-3032-bde8-3a8845b780f8@roeck-us.net>
On 11/01/2017 15:25, Guenter Roeck wrote:
> On 01/11/2017 04:31 AM, Marc Gonzalez wrote:
>> On 11/01/2017 11:52, Guenter Roeck wrote:
>>
>>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>>
>>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>>> err = clk_prepare_enable(dev->clk);
>>>>> if (err)
>>>>> return err;
>>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>>> + (void(*)(void *))clk_disable_unprepare,
>>>>> + dev->clk);
>>>>> + if (err)
>>>>> + return err;
>>>>
>>>> Hello Guenter,
>>>>
>>>> I would rather avoid the function pointer cast.
>>>> How about defining an auxiliary function for the cleanup action?
>>>>
>>>> clk_disable_unprepare() is static inline, so gcc will have to
>>>> define an auxiliary function either way. What do you think?
>>>
>>> Not really. It would just make it more complicated to replace the
>>> call with devm_clk_prepare_enable(), should it ever find its way
>>> into the light of day.
>>
>> More complicated, because the cleanup function will have to be deleted later?
>> The compiler will warn if someone forgets to do that.
>>
>> In my opinion, it's not a good idea to rely on the fact that casting
>> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
>> on most platforms. (It has undefined behavior, strictly speaking.)
>
> I do hear that you object to this code.
>
> However, I must admit that you completely lost me here. It is a cast from
> one function pointer to another,
Perhaps you are used to work at the assembly level, where pointers are
just addresses, and all pointers are interchangeable.
At a slightly higher level (C abstract machine), it is not so.
> passed as argument to another function,
> with a secondary cast of its argument from a typed pointer to a void pointer.
> I don't think C permits for "undefined behavior, strictly speaking".
The C standard leaves quite a lot of behavior undefined, e.g.
char *foo = "hello";
foo[1] = 'a'; // UB
char buf[4];
*(int *)&buf = 0xdeadbeef; // UB
1 << 64; // UB
> Besides, that same mechanism is already used elsewhere, which is how I
> got the idea. Are you claiming that there are situations where it won't
> work ?
If this technique is already used elsewhere in the kernel, then I'll
crawl back under my rock (and weep).
I can see two issues with the code you propose.
First is the same for all casts: silencing potential warnings,
e.g. if the prototype of clk_disable_unprepare ever changed.
(Though casts are required for vararg function arguments.)
Second is just theory and not a real-world concern.
>> Do you really dislike the portable solution I suggested? :-(
>
> It is not more portable than the above. It is more expensive and adds more
> code.
Maybe I am mistaken. Can you tell me why adding an auxiliary function
is more expensive? (In CPU cycles?)
clk_disable_unprepare() is static inline, so an auxiliary function
exists either way (implicit or explicit).
Regards.
^ permalink raw reply
* [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]
From: David Howells @ 2017-01-11 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111145138.GB29649@codeblueprint.co.uk>
Matt Fleming <matt@codeblueprint.co.uk> wrote:
> Before we add more efi.flags bits I'd like this series to include the
> patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this
> last patch to a new series.
Are you willing to take the kernel lock-down patches also?
David
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Ard Biesheuvel @ 2017-01-11 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9DxMzSTVRPdeSaJQNqe5RGjS_qzVzBU1SpGs5EZvCE1Q@mail.gmail.com>
On 11 January 2017 at 15:25, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 11 January 2017 at 15:18, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi Ard,
>>
>> On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
>>> When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
>>> modules and the core kernel may exceed 4 GB, putting symbols exported
>>> by the core kernel out of the reach of the ordinary adrp/add instruction
>>> pairs used to generate relative symbol references. So make the adr_l
>>> macro emit a movz/movk sequence instead when executing in module context.
>>
>> AFAICT, we only use adr_l in a few assembly files that shouldn't matter
>> to modules:
>>
>> * arch/arm64/kernel/head.S
>> * arch/arm64/kernel/sleep.S
>> * arch/arm64/kvm/hyp-init.S
>> * arch/arm64/kvm/hyp/hyp-entry.S
>>
>> ... so I don't follow why we need this.
>>
>> Have I missed something? Or do you intend to use this in module code in
>> future?
>>
>
> Yes. E.g., the scalar AES cipher that I am proposing for v4.11 reuses
> the lookup tables from crypto/aes_generic.c, which may be built into
> the core kernel, while the code itself may be built as a module.
>
> But in general, if the macro is available to modules, I would like to
> make sure that it does not result in code that builds fine but may
> fail in some cases only at runtime, especially given the fact that
> there is also a Cortex-A53 erratum regarding adrp instructions, for
> which reason we build modules with -mcmodel=large (which amounts to
> the same thing as the patch above)
>
Actually, we could test for
defined(MODULE) && defined(CONFIG_ARM64_MODULE_CMODEL_LARGE)
instead, so we revert to adrp/add pairs for modules if the erratum and
KASLR are both disabled
>> It seems somewhat surprising to me to have adr_l expand to something
>> that doesn't use adr/adrp, but that's not necessarily a problem.
>>
>
> I did realise that, but I don't think it is a problem tbh.
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Dave Martin @ 2017-01-11 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144902.GA20288@e104818-lin.cambridge.arm.com>
On Wed, Jan 11, 2017 at 02:49:03PM +0000, Catalin Marinas wrote:
> On Tue, Jan 10, 2017 at 12:14:23PM +0000, Catalin Marinas wrote:
> > On Mon, Jan 09, 2017 at 07:06:19PM +0100, Bas van Tiel wrote:
> > > > I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
> > > > fine, though I'll leave it longer/overnight (on a Juno board). With the
> > > > 4K signal stack it was crashing shortly after start.
> > >
> > > I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board
> > > and still see the same behaviour of crashing. Sometimes the process
> > > is also blocked for a long time before it crashes.
> > >
> > > Setting the interval to 200 usec [5 Khz] will help to crash it faster.
> > >
> > > To further isolate the issue I will create a kernel module (based on a
> > > hrtimer) that will sent a periodic signal to the registered process
> > > and execute the same sighandler logic to check if the problem is still
> > > there.
> >
> > I lowered the interval to 100us (it was 100ms in the original file) and
> > I can indeed trigger segfault easily on Juno. But it doesn't fail in the
> > same way every time, I sometimes get permission fault, other times bad
> > frame.
>
> With 100us interval, it segfaults on x86 fairly quickly as well, so I
> don't think it's a kernel issue.
To be able to take a signal at all, stacks need to be at least SIGSTKSZ
bytes in practice:
diff --git a/context_demo.c b/context_demo.c
index 2cc63f7..b1f3bbc 100644
--- a/context_demo.c
+++ b/context_demo.c
@@ -22,7 +22,7 @@
#define NUMCONTEXTS 10 /* how many contexts to make */
-#define STACKSIZE 4096 /* stack size */
+#define STACKSIZE SIGSTKSZ /* stack size */
#define INTERVAL 100 /* timer interval in nanoseconds */
sigset_t set; /* process wide signal mask */
The other issue looks a bit subtler, to do with signal masking.
SIGALRM will be masked on entry to timer_interrupt() and restored on
return, due to and absence of SA_NODEFER from sa_flags when calling
sigaction. (Setting SIGALRM in sa_mask also has this effect, but this
is redundant without SA_NODEFER.)
However, by explicitly clearing this signal from
signal_context.uc_sigmask, we'll enter scheduler() with SIGALRM
unmasked. If a new SIGALRM is taken before scheduler() has called
setcontext(), we'll pile up another signal on signal_stack and call
schedule() again, still on signal_stack ... and this can repeat
indefinitely.
There's no need to clear SIGALRM from the signal mask: it will be
cleared when timer_interrupt() returns after resuming an interrupted
task (as part of the signal frame restore work done by rt_sigreturn).
So:
@@ -61,7 +61,6 @@ timer_interrupt(int j, siginfo_t *si, void *old_context)
signal_context.uc_stack.ss_sp = signal_stack;
signal_context.uc_stack.ss_size = STACKSIZE;
signal_context.uc_stack.ss_flags = 0;
- sigemptyset(&signal_context.uc_sigmask);
makecontext(&signal_context, scheduler, 1);
/* save running thread, jump to scheduler */
For me, this seems to fix the problem.
It also makes sense of what we've seen: we need either short timer
intervals, slow machines, or high system load (or some combination) in
order to take enough extra signals in scheduler() to cause a stack
overflow.
I can't see the purpose of running scheduler() in its own context here,
except so that it doesn't contribute stack overhead to the thread
stacks (which hardly seems worthwhile, since its overhead is probably a
lot smaller than the signal overhead anyway -- maybe I'm missing
something).
makeconext() and swapcontext() are obsoleted by POSIX.1-2008 and
considered non-portable (see makecontext(3), swapcontext(3)). Really,
the ucontext API should not be used for anything except cooperative
switching now (certainly this covered the vast majority or real-world
usage the last time I looked into it). For anything else, pthreads
almost certainly do it better.
Cheers
---Dave
^ permalink raw reply related
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Mark Rutland @ 2017-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9DxMzSTVRPdeSaJQNqe5RGjS_qzVzBU1SpGs5EZvCE1Q@mail.gmail.com>
On Wed, Jan 11, 2017 at 03:25:09PM +0000, Ard Biesheuvel wrote:
> On 11 January 2017 at 15:18, Mark Rutland <mark.rutland@arm.com> wrote:
> > Hi Ard,
> >
> > On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
> >> When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> >> modules and the core kernel may exceed 4 GB, putting symbols exported
> >> by the core kernel out of the reach of the ordinary adrp/add instruction
> >> pairs used to generate relative symbol references. So make the adr_l
> >> macro emit a movz/movk sequence instead when executing in module context.
> >
> > AFAICT, we only use adr_l in a few assembly files that shouldn't matter
> > to modules:
> >
> > * arch/arm64/kernel/head.S
> > * arch/arm64/kernel/sleep.S
> > * arch/arm64/kvm/hyp-init.S
> > * arch/arm64/kvm/hyp/hyp-entry.S
> >
> > ... so I don't follow why we need this.
> >
> > Have I missed something? Or do you intend to use this in module code in
> > future?
>
> Yes. E.g., the scalar AES cipher that I am proposing for v4.11 reuses
> the lookup tables from crypto/aes_generic.c, which may be built into
> the core kernel, while the code itself may be built as a module.
Ah, ok.
> But in general, if the macro is available to modules, I would like to
> make sure that it does not result in code that builds fine but may
> fail in some cases only at runtime, especially given the fact that
> there is also a Cortex-A53 erratum regarding adrp instructions, for
> which reason we build modules with -mcmodel=large (which amounts to
> the same thing as the patch above)
>
> > It seems somewhat surprising to me to have adr_l expand to something
> > that doesn't use adr/adrp, but that's not necessarily a problem.
>
> I did realise that, but I don't think it is a problem tbh.
In this case it should be fine, certainly.
There are cases like the early boot code and hyp code where it's
critical that we use adr. It's also possible that we might build
(modular) drivers which want some idmapped code, where we want adr, so
it seems unfortunate that this depends on howthe code is built.
So, maybe it's better to have a mov_sym helper for this case, to be
explicit about what we want? That can use either adr* or mov*, or the
latter consistently.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-11 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2eOy2sn1VkE979ne23Sj9L6+kaQDNpL1EUKb2m=6sGXw@mail.gmail.com>
On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
> Hi Uwe,
>
> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > Hello Cedric,
> >
> > On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote:
> >> +/*
> >> + * In standard mode:
> >> + * SCL period = SCL high period = SCL low period = CCR * I2C parent clk period
> >> + *
> >> + * In fast mode:
> >> + * If Duty = 0; SCL high period = 1 * CCR * I2C parent clk period
^^
> >> + * SCL low period = 2 * CCR * I2C parent clk period
^^
> >> + * If Duty = 1; SCL high period = 9 * CCR * I2C parent clk period
^^
> >> + * SCL low period = 16 * CCR * I2C parent clk period
> > s/ \*/ */ several times
>
> Sorry but I don't see where is the issue as the style for multi-line
> comments seems ok.
> Could you please clarify that point if possible ? Thanks in advance
There are several places with double spaces before * marked above.
> >> + * In order to reach 400 kHz with lower I2C parent clk frequencies we always set
> >> + * Duty = 1
> >> + *
> >> + * For both modes, we have CCR = SCL period * I2C parent clk frequency
> >> + * with scl_period = 5 microseconds in Standard mode and scl_period = 1
> > s/mode/Mode/
>
> ok thanks
>
> >
> >> + * microsecond in Fast Mode in order to satisfy scl_high and scl_low periods
> >> + * constraints defined by i2c bus specification
> >
> > I don't understand scl_period = 1 ?s for Fast Mode. For a bus freqency
> > of 400 kHz we need low + high = 2.5 ?s. Is there a factor 10 missing
> > somewhere?
>
> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
> 2Mhz and SCL_period = 1 we have:
> CCR = 1 * 2Mhz = 2.
> But to compute, scl_low and scl_high in Fast mode, we have to do the
> following thing as Duty=1:
> scl_high = 9 * CCR * I2C parent clk period
> scl_low = 16 * CCR * I2C parent clk period
> In our example:
> scl_high = 9 * 2 * 0,0000005 = 0,000009 sec = 9 ?s
> scl_low = 16 * 2 * 0.0000005 = 0,000016 sec = 16 ?s
> So low + high = 27 ?s > 2,5 ?s
For me 9 ?s + 16 ?s is 25 ?s, resulting in 40 kHz. That's why I wondered
if there is a factor 10 missing somewhere.
> >> + */
> >> +static struct stm32f4_i2c_timings i2c_timings[] = {
> >> [...]
> >> +
> >> +/**
> >> + * stm32f4_i2c_hw_config() - Prepare I2C block
> >> + * @i2c_dev: Controller's private data
> >> + */
> >> +static int stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + int ret = 0;
> >> +
> >> + /* Disable I2C */
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
> >> +
> >> + ret = stm32f4_i2c_set_periph_clk_freq(i2c_dev);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + stm32f4_i2c_set_rise_time(i2c_dev);
> >> +
> >> + stm32f4_i2c_set_speed_mode(i2c_dev);
> >> +
> >> + stm32f4_i2c_set_filter(i2c_dev);
> >> +
> >> + /* Enable I2C */
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
> >
> > This function is called after a hw reset, so there should be no need to
> > use clr_bits and set_bits because the value read from hw should be
> > known.
>
> ok thanks
>
> >
> >> + return ret;
> >
> > return 0;
>
> ok thanks
>
> >
> >> +}
> >> +
> >> +static int stm32f4_i2c_wait_free_bus(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + u32 status;
> >> + int ret;
> >> +
> >> + ret = readl_relaxed_poll_timeout(i2c_dev->base + STM32F4_I2C_SR2,
> >> + status,
> >> + !(status & STM32F4_I2C_SR2_BUSY),
> >> + 10, 1000);
> >> + if (ret) {
> >> + dev_dbg(i2c_dev->dev, "bus not free\n");
> >> + ret = -EBUSY;
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_write_ byte() - Write a byte in the data register
> >> + * @i2c_dev: Controller's private data
> >> + * @byte: Data to write in the register
> >> + */
> >> +static void stm32f4_i2c_write_byte(struct stm32f4_i2c_dev *i2c_dev, u8 byte)
> >> +{
> >> + writel_relaxed(byte, i2c_dev->base + STM32F4_I2C_DR);
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_write_msg() - Fill the data register in write mode
> >> + * @i2c_dev: Controller's private data
> >> + *
> >> + * This function fills the data register with I2C transfer buffer
> >> + */
> >> +static void stm32f4_i2c_write_msg(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> +
> >> + stm32f4_i2c_write_byte(i2c_dev, *msg->buf++);
> >> + msg->count--;
> >> +}
> >> +
> >> +static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + u32 rbuf;
> >> +
> >> + rbuf = readl_relaxed(i2c_dev->base + STM32F4_I2C_DR);
> >> + *msg->buf++ = rbuf & 0xff;
> >
> > This is unnecessary. buf has an 8 bit wide type so
> >
> > *msg->buf++ = rbuf;
> >
> > has the same effect. (ISTR this is something I already pointed out
> > earlier?)
>
> Yes you are right.
>
> >
> >> + msg->count--;
> >> +}
> >> +
> >> +static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> >> +
> >> + stm32f4_i2c_disable_irq(i2c_dev);
> >> +
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + if (msg->stop)
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> >> + else
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> >> +
> >> + complete(&i2c_dev->complete);
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_handle_write() - Handle FIFO empty interrupt in case of write
> >> + * @i2c_dev: Controller's private data
> >> + */
> >> +static void stm32f4_i2c_handle_write(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> >> +
> >> + if (msg->count) {
> >> + stm32f4_i2c_write_msg(i2c_dev);
> >> + if (!msg->count) {
> >> + /* Disable buffer interrupts for RXNE/TXE events */
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
> >> + }
> >> + } else {
> >> + stm32f4_i2c_terminate_xfer(i2c_dev);
> >
> > Is stm32f4_i2c_terminate_xfer also called when arbitration is lost? If
> > yes, is it then right to set STM32F4_I2C_CR1_STOP or
> > STM32F4_I2C_CR1_START?
>
> If arbitration is lost, stm32f4_i2c_terminate_xfer() is not called.
> In that case, we return -EAGAIN and i2c-core will retry by calling
> stm32f4_i2c_xfer()
>
> >
> >> + }
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_handle_read() - Handle FIFO empty interrupt in case of read
> >> + * @i2c_dev: Controller's private data
> >> + */
> >> +static void stm32f4_i2c_handle_read(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> >> +
> >> + switch (msg->count) {
> >> + case 1:
> >> + stm32f4_i2c_disable_irq(i2c_dev);
> >> + stm32f4_i2c_read_msg(i2c_dev);
> >> + complete(&i2c_dev->complete);
> >> + break;
> >> + /*
> >> + * For 2 or 3-byte reception, we do not have to read the data register
> >> + * when RXNE occurs as we have to wait for byte transferred finished
> >
> > it's hard to understand because if you don't know the hardware the
> > meaning of RXNE is unknown.
>
> Ok I will replace RXNE by RX not empty in that comment
>
> >
> >> + * event before reading data. So, here we just disable buffer
> >> + * interrupt in order to avoid another system preemption due to RXNE
> >> + * event
> >> + */
> >> + case 2:
> >> + case 3:
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
> >> + break;
> >> + /* For N byte reception with N > 3 we directly read data register */
> >> + default:
> >> + stm32f4_i2c_read_msg(i2c_dev);
> >> + }
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_handle_rx_btf() - Handle byte transfer finished interrupt
> >> + * in case of read
> >> + * @i2c_dev: Controller's private data
> >> + */
> >> +static void stm32f4_i2c_handle_rx_btf(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >
> > btf is a hw-related name. Maybe better use _done which is easier to
> > understand?
>
> OK
>
> >
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + void __iomem *reg;
> >> + u32 mask;
> >> + int i;
> >> +
> >> + switch (msg->count) {
> >> + case 2:
> >> + /*
> >> + * In order to correctly send the Stop or Repeated Start
> >> + * condition on the I2C bus, the STOP/START bit has to be set
> >> + * before reading the last two bytes.
> >> + * After that, we could read the last two bytes, disable
> >> + * remaining interrupts and notify the end of xfer to the
> >> + * client
> >
> > 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).
> > How does this work, when I only want to read a single
> > byte? Same problem for ACK below.
>
> For a single reception, we enable NACK and STOP or Repeatead START
> bits during address match.
> The NACK and STOP/START pulses are sent as soon as the data is
> received in the shift register.
> Please note that in that case, we don't have to wait BTF event to read the data.
> Data is read as soon as RXNE event occurs.
>
> >
> >> + */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + if (msg->stop)
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> >> + else
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> >> +
> >> + for (i = 2; i > 0; i--)
> >> + stm32f4_i2c_read_msg(i2c_dev);
> >> +
> >> + reg = i2c_dev->base + STM32F4_I2C_CR2;
> >> + mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
> >> + stm32f4_i2c_clr_bits(reg, mask);
> >> +
> >> + complete(&i2c_dev->complete);
> >> + break;
> >> + case 3:
> >> + /*
> >> + * In order to correctly send the ACK on the I2C bus for the
> >> + * last two bytes, we have to set ACK bit before reading the
> >> + * third last data byte
> >> + */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> >> + stm32f4_i2c_read_msg(i2c_dev);
> >> + break;
> >> + default:
> >> + stm32f4_i2c_read_msg(i2c_dev);
> >> + }
> >> +}
> >> +
> >> +/**
> >> + * stm32f4_i2c_handle_rx_addr() - Handle address matched interrupt in case of
> >> + * master receiver
> >> + * @i2c_dev: Controller's private data
> >> + */
> >> +static void stm32f4_i2c_handle_rx_addr(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> >> + void __iomem *reg;
> >> +
> >> + switch (msg->count) {
> >> + case 0:
> >> + stm32f4_i2c_terminate_xfer(i2c_dev);
> >> + /* Clear ADDR flag */
> >> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> >> + break;
> >> + case 1:
> >> + /*
> >> + * Single byte reception:
> >
> > This also happens for the last byte of a 5 byte transfer, right?
>
> For a 5 byte transfer the behavior is different:
> We have to read data from DR (data register) as soon as the RXNE (RX
> not empty) event occurs for data1, data2 and data3 (until N-2 data for
> a more generic case)
> The ACK is automatically sent as soon as the data is received in the
> shift register as the I2C controller was configured to do that during
> adress match phase.
>
> For data3 (N-2 data), we wait for BTF (Byte Transfer finished) event
> in order to set NACK before reading DR.
> This event occurs when a new data has been received in shift register
> (in our case data4 or N-1 data) but the prevoius data in DR (in our
> case data3 or N-2 data) has not been read yet.
> In that way, the NACK pulse will be correctly generated after the last
> received data byte.
>
> For data4 and data5, we wait for BTF event (data4 or N-1 data in DR
> and data5 or N data in shift register), set STOP or repeated Start in
> order to correctly sent the right pulse after the last received data
> byte and run 2 consecutives read of DR.
So "Single byte reception" above is wrong, as this case is also used for
longer transfers and should be updated accordingly.
> >> + * Enable NACK, clear ADDR flag and generate STOP or RepSTART
> >> + */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> >> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> >> + if (msg->stop)
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> >> + else
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> >> + break;
> >> + case 2:
> >> + /*
> >> + * 2-byte reception:
> >> + * Enable NACK and set POS
> >
> > What is POS?
> POS is used to define the position of the (N)ACK pulse
> 0: ACK is generated when the current is being received in the shift register
> 1: ACK is generated when the next byte which will be received in the
> shift register (used for 2-byte reception)
Can you please put this into the comment. "POS" isn't much helpful
there.
>
> >
> >> + */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_POS);
> >
> > You could get rid of this, when caching the value of CR1. Would save two
> > register reads here. This doesn't work for all registers, but it should
> > be possible to apply for most of them, maybe enough to get rid of the
> > clr_bits and set_bits function.
> >
> >> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> >> + break;
> >> +
> >> + default:
> >> + /* N-byte reception: Enable ACK */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_ACK);
> >
> > Do you need to set ACK for each byte transferred?
> I need to do that in order to be SMBus compatible and the ACK/NACK
> seems to be used by default in Documentation/i2c/i2c-protocol file.
Yeah, protocol wise you need to ack each byte. I just wondered if you
need to set the hardware bit for each byte or if it is retained in
hardware until unset by a register write.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-11 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2cDzPgqvWZf7ASvtST+aDeaAebf=1aMWA9Zd8CDg4pmA@mail.gmail.com>
Hello Cedric,
On Wed, Jan 11, 2017 at 03:20:41PM +0100, M'boumba Cedric Madianga wrote:
> >
> >> + */
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_POS);
> >
> > You could get rid of this, when caching the value of CR1. Would save two
> > register reads here. This doesn't work for all registers, but it should
> > be possible to apply for most of them, maybe enough to get rid of the
> > clr_bits and set_bits function.
>
> I agree at many places I could save registers read by not using
> clr_bits and set_bits function when the registers in question has been
> already read.
> But it is not enough to get rid of the clr_bits and set_bits function.
> For example when calling stm32f4_i2c_terminate_xfer(), the CR1
> register is never read before so set_bits function is useful.
I didn't double check the manual, but I would expect that CR1 isn't
modified by hardware. So you can cache the result in the driver data
structure and do the necessary modifications with that one.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] gpio: mvebu: fix warning when building on 64-bit
From: Linus Walleij @ 2017-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cR5IG-0008Gw-HV@rmk-PC.armlinux.org.uk>
On Tue, Jan 10, 2017 at 11:53 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Casting a pointer to an int is not portable, and provokes a compiler
> warning. Cast to unsigned long instead to avoid the warning.
>
> drivers/gpio/gpio-mvebu.c: In function 'mvebu_gpio_probe':
> drivers/gpio/gpio-mvebu.c:662:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> soc_variant = (int) match->data;
> ^
>
> This will be needed when building gpio-mvebu for Armada 7k/8k ARM64
> SoCs.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Linus,
>
> I don't think this is necessary to push into -rc, as its not yet used
> on ARM64 - GPIO support is not yet present in the DTS files, and the
> Kconfig doesn't allow the driver to be built on ARM64. Hence, please
> queue for the next merge window as a low priority fix.
Fair enough, queued for next. Thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/62] watchdog: coh901327_wdt: Convert to use device managed functions
From: Linus Walleij @ 2017-01-11 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484091325-9199-11-git-send-email-linux@roeck-us.net>
On Wed, Jan 11, 2017 at 12:34 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Use devm_clk_get() if the device parameter is not NULL
> - Replace 'goto l; ... l: return e;' with 'return e;'
> - Replace 'val = e; return val;' with 'return e;'
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Replace request_irq, request_threaded_irq, and request_any_context_irq
> with their device managed equivalent
> - Replace &pdev->dev with dev if 'struct device *dev' is a declared
> variable
> - Use devm_watchdog_register_driver() to register watchdog device
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] ARM: dts: qcom: Add apq8064 CoreSight components
From: Georgi Djakov @ 2017-01-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm apq8064 based
platforms, including the IFC6410 board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v2 (https://lkml.org/lkml/2016/11/21/522)
* Rebase to linux-next
Changes since v1 (https://lkml.org/lkml/2016/11/17/474)
* Moved everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
arch/arm/boot/dts/qcom-apq8064.dtsi | 189 +++++++++++++++++++++++++++++++++++-
1 file changed, 185 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 407a4610f4a7..4b77075ef731 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -28,7 +28,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu at 0 {
+ CPU0: cpu at 0 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -39,7 +39,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 1 {
+ CPU1: cpu at 1 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -50,7 +50,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 2 {
+ CPU2: cpu at 2 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -61,7 +61,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 3 {
+ CPU3: cpu at 3 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -1420,6 +1420,187 @@
};
};
};
+
+ etb at 1a01000 {
+ compatible = "coresight-etb10", "arm,primecell";
+ reg = <0x1a01000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ tpiu at 1a03000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x1a03000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel_out>;
+ };
+ };
+ };
+ };
+
+ funnel at 1a04000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x1a04000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 2 - connected to STM component
+ * 3 - not-connected
+ * 6 - not-connected
+ * 7 - not-connected
+ */
+ port at 0 {
+ reg = <0>;
+ funnel_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 4 {
+ reg = <4>;
+ funnel_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 5 {
+ reg = <5>;
+ funnel_in5: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel_out: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etm at 1a1c000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel_in0>;
+ };
+ };
+ };
+
+ etm at 1a1d000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel_in1>;
+ };
+ };
+ };
+
+ etm at 1a1e000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel_in4>;
+ };
+ };
+ };
+
+ etm at 1a1f000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel_in5>;
+ };
+ };
+ };
};
};
#include "qcom-apq8064-pins.dtsi"
^ permalink raw reply related
* [RESEND PATCH v5] arm64: dts: qcom: Add msm8916 CoreSight components
From: Georgi Djakov @ 2017-01-11 15:59 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm msm8916 and
apq8016 based platforms, including the DragonBoard 410c board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v4: (https://lkml.org/lkml/2016/11/17/533)
* Move everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
Changes since v3: (https://lkml.org/lkml/2015/5/11/134)
* Include msm8916-coresight.dtsi into msm8916.dtsi
Changes since v2: (https://lkml.org/lkml/2015/4/29/242)
* Added "1x" to "qcom,coresight-replicator" compatible string, to match what
devicetree bindings documentations says.
arch/arm64/boot/dts/qcom/msm8916.dtsi | 241 ++++++++++++++++++++++++++++++++++
1 file changed, 241 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index f8ff327667c5..014d76e7dddf 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -14,6 +14,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
#include <dt-bindings/reset/qcom,gcc-msm8916.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
/ {
model = "Qualcomm Technologies, Inc. MSM8916";
@@ -856,6 +857,246 @@
memory-region = <&mpss_mem>;
};
};
+
+ tpiu at 820000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x820000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ funnel at 821000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x821000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 0 - connected to Resource and Power Manger CPU ETM
+ * 1 - not-connected
+ * 2 - connected to Modem CPU ETM
+ * 3 - not-connected
+ * 5 - not-connected
+ * 6 - connected trought funnel to Wireless CPU ETM
+ * 7 - connected to STM component
+ */
+
+ port at 4 {
+ reg = <4>;
+ funnel0_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel1_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel0_out: endpoint {
+ remote-endpoint = <&etf_in>;
+ };
+ };
+ };
+ };
+
+ replicator at 824000 {
+ compatible = "qcom,coresight-replicator1x", "arm,primecell";
+ reg = <0x824000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etr_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf_out>;
+ };
+ };
+ };
+ };
+
+ etf at 825000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x825000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ etf_out: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel0_out>;
+ };
+ };
+ port at 1 {
+ reg = <0>;
+ etf_in: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etr at 826000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x826000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ etr_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ funnel at 841000 { /* APSS funnel only 4 inputs are used */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x841000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ funnel1_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel1_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 2 {
+ reg = <2>;
+ funnel1_in2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 3 {
+ reg = <3>;
+ funnel1_in3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 4 {
+ reg = <0>;
+ funnel1_out: endpoint {
+ remote-endpoint = <&funnel0_in4>;
+ };
+ };
+ };
+ };
+
+ etm at 85c000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel1_in0>;
+ };
+ };
+ };
+
+ etm at 85d000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel1_in1>;
+ };
+ };
+ };
+
+ etm at 85e000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel1_in2>;
+ };
+ };
+ };
+
+ etm at 85f000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel1_in3>;
+ };
+ };
+ };
};
smd {
^ permalink raw reply related
* [PATCH] arm64: avoid increasing DMA masks above what hardware supports
From: Nikita Yushchenko @ 2017-01-11 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c5bada32-fbaf-3631-268b-db49dffe3eb9@arm.com>
11.01.2017 17:50, Robin Murphy ?????:
> On 11/01/17 13:41, Nikita Yushchenko wrote:
>>> Yes, I think that ought to work, although the __iommu_setup_dma_ops()
>>> call will still want a real size reflecting the default mask
>>
>> I see iommu_dma_ops do not define set_dma_mask.
>>
>> So what if setup was done for size reflecting one mask and then driver
>> changes mask? Will things still operate correctly?
>
> We've overridden dma_set_mask() at the function level, so it should
> always apply regardless. Besides, none of the arm64 ops implement
> .set_dma_mask anyway, so we could possibly drop the references to it
> altogether.
>
> Conversely, I suppose we could just implement said callback for
> swiotlb_dma_ops and iommu_dma_ops with the parent_dma_mask-checking
> function and drop the HAVE_ARCH_DMA_SET_MASK override instead. I'm not
> sure which approach is preferable - the latter seems arguably cleaner in
> isolation, but would also be less consistent with how the coherent mask
> has to be handled. Ho hum.
I mean, before patch is applied.
In the current mainline codebase, arm64 iommu does setup dependent on
[default] dma_mask, but does not anyhow react on dma mask change.
I don't know much details about arm64 iommu, but from distant view this
combination looks incorrect:
- if behavior of this hardware should depend on dma_mask of device, then
it should handle mask change,
- if behavior of this hardware should not depend on dma_mask of device,
then what for to pass size to it's setup?
^ permalink raw reply
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices
From: Andy Gross @ 2017-01-11 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cd4197f-0055-bd8b-5d8f-dc16e008c46d@baylibre.com>
On Wed, Jan 11, 2017 at 03:11:01PM +0100, Neil Armstrong wrote:
> On 01/11/2017 03:08 PM, Arnd Bergmann wrote:
> > On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote:
> >> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote:
> >>> On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote:
> >>>> This default-enables the devices found on the APQ8060 DragonBoard
> >>>> in the qcom_defconfig:
> >>>>
> >>>> - EBI2 bus
> >>>> - SMSC911x ethernet
> >>>> - LEDs class and PM8058 LEDs driver, trigger and heartbeat
> >>>> trigger (so we get heartbeat on the board by default)
> >>>> - IIO framework, including the HRTimer trigger, KXSD9
> >>>> accelerometer, MPU3050 gyroscope, AK8975 magnetometer and
> >>>> BMP085 pressure sensor
> >>>>
> >>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>>
> >>> This brings up a point of discussion. Do we even need the qcom_defconfig any
> >>> more? Is everyone comfortable with using the multi_v7_defconfig?
> >
> > I think having one specialized defconfig for the platform is helpful for
> > the build/boot testing, e.g. it can show whether a boot failure with
> > multi_v7_defconfig is the result of a qcom-specific change, or a side-effect
> > of something that was done on another platform.
> >
> >>> Aside from size of the image, i can't think of any other reason to keep around
> >>> the separate qcom file.
> >>
> >> Actually a bit of Arnd/Olof question.
> >>
> >> Bystander opinion below:
> >>
> >> That is pretty much up to the maintainer (you) I guess.
> >> Reasons would be:
> >>
> >> - Lower footprint (because you may not need all stuff selected
> >> as 'y' compiled-in in multi_v7) on some platforms this is even
> >> necessary to get a bootable image or one that will load in
> >> reasonable time.
> >>
> >> - Enable a few things by default (both compiled-in and modules)
> >> that multi_v7 would consider to be littering
> >>
> >> - For "my" systems I usually like them because these defconfigs
> >> have vastly shorter compile time (because so much stuff that
> >> idon't concern me is left out).
> >>
> >> On the other hand: some ARMv7 system maintainers have x86
> >> ambitions: compile once, run everywhere, and certainly that is
> >> the ambition with multi_v7, and if that overshadows all the above,
> >> just kill off qcom_defconfig and be happy :)
> >
> > We recently killed of the Broadcom defconfig file that actually
> > contained some very different platforms that had not much in common
> > besides the company name.
> >
> > I think my preference is to keep it, but if Andy wants it removed
> > and nobody complains, that's fine too.
> >
> > Arnd
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
> Hi all,
>
> In fact, as far as I remember the multi_v7 did not fit on the MDM9615
> due to it's limited memory available to Linux.
This was mainly a user poll. We'll keep it in as there is at least one user who
cannot use the multiv7 due to size. That alone is enough to keep it around.
Linus, I'll add this to my pull list.
Andy
^ permalink raw reply
* [PATCH 04/15] video: fbdev: use permission-specific DEVICE_ATTR variants
From: Bartlomiej Zolnierkiewicz @ 2017-01-11 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477769829-22230-5-git-send-email-Julia.Lawall@lip6.fr>
Hi,
On Saturday, October 29, 2016 09:36:58 PM Julia Lawall wrote:
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @rw@
> declarer name DEVICE_ATTR;
> identifier x,x_show,x_store;
> @@
>
> DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
>
> @script:ocaml@
> x << rw.x;
> x_show << rw.x_show;
> x_store << rw.x_store;
> @@
>
> if not (x^"_show" = x_show && x^"_store" = x_store)
> then Coccilib.include_match false
>
> @@
> declarer name DEVICE_ATTR_RW;
> identifier rw.x,rw.x_show,rw.x_store;
> @@
>
> - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> + DEVICE_ATTR_RW(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, patch queued for 4.11.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/wm8505fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
> index e925619..253ffe9 100644
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -182,7 +182,7 @@ static ssize_t contrast_store(struct device *dev,
> return count;
> }
>
> -static DEVICE_ATTR(contrast, 0644, contrast_show, contrast_store);
> +static DEVICE_ATTR_RW(contrast);
>
> static inline u_int chan_to_field(u_int chan, struct fb_bitfield *bf)
> {
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Ard Biesheuvel @ 2017-01-11 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111153447.GD26344@leverpostej>
On 11 January 2017 at 15:34, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Jan 11, 2017 at 03:25:09PM +0000, Ard Biesheuvel wrote:
>> On 11 January 2017 at 15:18, Mark Rutland <mark.rutland@arm.com> wrote:
>> > Hi Ard,
>> >
>> > On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
>> >> When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
>> >> modules and the core kernel may exceed 4 GB, putting symbols exported
>> >> by the core kernel out of the reach of the ordinary adrp/add instruction
>> >> pairs used to generate relative symbol references. So make the adr_l
>> >> macro emit a movz/movk sequence instead when executing in module context.
>> >
>> > AFAICT, we only use adr_l in a few assembly files that shouldn't matter
>> > to modules:
>> >
>> > * arch/arm64/kernel/head.S
>> > * arch/arm64/kernel/sleep.S
>> > * arch/arm64/kvm/hyp-init.S
>> > * arch/arm64/kvm/hyp/hyp-entry.S
>> >
>> > ... so I don't follow why we need this.
>> >
>> > Have I missed something? Or do you intend to use this in module code in
>> > future?
>>
>> Yes. E.g., the scalar AES cipher that I am proposing for v4.11 reuses
>> the lookup tables from crypto/aes_generic.c, which may be built into
>> the core kernel, while the code itself may be built as a module.
>
> Ah, ok.
>
>> But in general, if the macro is available to modules, I would like to
>> make sure that it does not result in code that builds fine but may
>> fail in some cases only at runtime, especially given the fact that
>> there is also a Cortex-A53 erratum regarding adrp instructions, for
>> which reason we build modules with -mcmodel=large (which amounts to
>> the same thing as the patch above)
>>
>> > It seems somewhat surprising to me to have adr_l expand to something
>> > that doesn't use adr/adrp, but that's not necessarily a problem.
>>
>> I did realise that, but I don't think it is a problem tbh.
>
> In this case it should be fine, certainly.
>
> There are cases like the early boot code and hyp code where it's
> critical that we use adr. It's also possible that we might build
> (modular) drivers which want some idmapped code, where we want adr, so
> it seems unfortunate that this depends on howthe code is built.
>
How would /that/ work? Modules are vmalloc'ed, and not covered by the
ID map to begin with, so it is impossible to execute those adr
instructions in a way that would make them return anything other than
the virtual address of the symbol they refer to.
> So, maybe it's better to have a mov_sym helper for this case, to be
> explicit about what we want? That can use either adr* or mov*, or the
> latter consistently.
>
Well, the point is that adr_l should not be used for modules so adding
something that may be used is fine, but that still leaves the risk
that someone may end up using it in a module.
^ permalink raw reply
* [PATCH] clk: stm32f4: avoid uninitialized variable access
From: Gabriel Fernandez @ 2017-01-11 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111134107.3821564-1-arnd@arndb.de>
On 01/11/2017 02:40 PM, Arnd Bergmann wrote:
> The failure path in the newly added function tries to free an
> uninitialized pointer:
>
> drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
> drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> I'm adding an initialization to NULL here to make the kfree()
> succeed, and I'm also rearranging the cleanup so that the
> same kfree() is used for any error path, making the function
> slightly more robust against newly introduced bugs in the
> error handling.
>
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/clk/clk-stm32f4.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
>
Acked-by: Gabriel Fernandez <gabriel.fernandez@st.com>
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Arnd Bergmann @ 2017-01-11 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c6a1523-e41b-ad83-501a-27c260b9f9ee@cogentembedded.com>
On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote:
> > I actually have a third variation of this problem involving a PCI root
> > complex which *could* drive full-width (40-bit) addresses, but won't,
> > due to the way its PCI<->AXI interface is programmed. That would require
> > even more complicated dma-ranges handling to describe the windows of
> > valid physical addresses which it *will* pass, so I'm not pressing the
> > issue - let's just get the basic DMA mask case fixed first.
>
> R-Car + NVMe is actually not "basic case".
>
> It has PCI<->AXI interface involved.
> PCI addresses are 64-bit and controller does handle 64-bit addresses
> there. Mapping between PCI addresses and AXI addresses is defined. But
> AXI is 32-bit.
>
> SoC has iommu that probably could be used between PCIe module and RAM.
> Although AFAIK nobody made that working yet.
>
> Board I work with has 4G of RAM, in 4 banks, located at different parts
> of wide address space, and only one of them is below 4G. But if iommu is
> capable of translating addresses such that 4 gigabyte banks map to first
> 4 gigabytes of address space, then all memory will become available for
> DMA from PCIe device.
You can in theory handle this by defining your own platform specific
dma_map_ops, as we used to do in the old days. Unfortunately, the modern
way of using the generic IOVA allocation can't handle really it, so it's
unclear if the work that would be necessary to support it (and the long
term maintenance cost) outweigh the benefits.
The more likely option here is to try harder to get the IOMMU working
(or show that it's impossible but make sure the next chip gets it right).
Arnd
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-11 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e8136b8a-b8f7-7b1b-693a-955dc17f1de9@ti.com>
On 01/11/2017 04:42 AM, Sekhar Nori wrote:
> On Friday 06 January 2017 10:03 AM, David Lechner wrote:
>
>> + beeper {
>> + compatible = "pwm-beeper";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&ehrpwm0b_pins>, <&_pins>;
>> + pwms = <&ehrpwm0 1 0 0>;
>> + enable-gpios = <&gpio 111 GPIO_ACTIVE_HIGH>;
>
> Since the enable-gpios binding for pwm beeper is still not accepted, can
> you drop the property or the node itself (if that makes more sense)?
No sound will come out of the speaker without enabling this gpio. So, I
guess I will just drop this node for now.
>
>> +&spi0 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>> +
>> + flash at 0 {
>> + compatible = "n25q128a13", "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <50000000>;
>> + ti,spi-wdelay = <8>;
>> +
>> + /* Partitions are based on the official firmware from LEGO */
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + partition at 0 {
>> + label = "U-Boot";
>> + reg = <0 0x40000>;
>> + };
>> +
>> + partition at 40000 {
>> + label = "U-Boot Env";
>> + reg = <0x40000 0x10000>;
>> + };
>> +
>> + partition at 50000 {
>> + label = "Kernel";
>> + reg = <0x50000 0x200000>;
>> + };
>> +
>> + partition at 250000 {
>> + label = "Filesystem";
>> + reg = <0x250000 0xa50000>;
>> + };
>> +
>> + partition at cb0000 {
>> + label = "Storage";
>> + reg = <0xcb0000 0x2f0000>;
>> + };
>> + };
>> + };
>> +
>> + adc at 3 {
>> + compatible = "ti-ads7957";
>
> So looks like this works because of_register_spi_device() sets up
> modalias of spi device from compatible string. I am fine with it, just
> highlighting it here to make sure this is acceptable practice. I did not
> really find any precedence for using SPI device name as compatible
> property in existing DTS files.
Indeed. It looks like this sort of "trivial" device binding is just used
for i2c devices. I will submit some patches to add proper device tree
bindings and change this to "ti,ads7957".
>
>> + reg = <3>;
>> + spi-max-frequency = <10000000>;
>> + refin-supply = <&adc_ref>;
>> + };
>
> Rest of the patch looks good to me.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-11 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484096148-17120-1-git-send-email-cw00.choi@samsung.com>
On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
> This patch replaces the small letter of base address, offset and hex value
> with the capital letter to keep the consistency on Exynos5433.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index abaf6b4d599d..d7ed1a68b6fd 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -231,7 +231,7 @@
> compatible = "arm,psci";
> method = "smc";
> cpu_off = <0x84000002>;
> - cpu_on = <0xC4000003>;
> + cpu_on = <0xc4000003>;
There is no point of such "improvements". This is just unnecessary
churn.
Sometimes such things are accepted as part of some bigger work (vide
recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
Best regards,
Krzysztof
^ permalink raw reply
* [kvm-unit-tests PATCH 0/6] Documentation misc fixes
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I broke these out of my earlier MTTCG test series as they are not
strictly related. The libcflat/pci fixes are a result of trying to
cross-compile arm32 binaries on my arm64 box with a arm-none-abi
compiler. I've also tidied up some documentation (along with a
controversial move to Markdown ;-). And finally the run_script now
follows the convention of passing arguments after -- to the child
process.
Alex Benn?e (6):
libcflat: add PRI(dux)32 format types
lib/pci: fix BAR format strings
docs: move README to README.md and symlink
docs: mention checkpatch in the README
docs: mention modifying env vars in README
run_tests: allow passing of options to QEMU
Makefile | 1 +
README | 69 +-----------------------------------
README.md | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++
configure | 13 +++++++
lib/libcflat.h | 9 +++++
lib/pci.c | 4 +--
run_tests.sh | 13 +++++--
scripts/functions.bash | 7 ++--
8 files changed, 137 insertions(+), 75 deletions(-)
mode change 100644 => 120000 README
create mode 100644 README.md
--
2.11.0
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-1-alex.bennee@linaro.org>
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.
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"
--
2.11.0
^ permalink raw reply related
* [kvm-unit-tests PATCH 2/6] lib/pci: fix BAR format strings
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-1-alex.bennee@linaro.org>
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);
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);
}
--
2.11.0
^ permalink raw reply related
* [kvm-unit-tests PATCH 3/6] docs: move README to README.md and symlink
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-1-alex.bennee@linaro.org>
This allows a slightly nicer formatting of the text when displayed on
some repository hosts. We keep a symlink from README for the
old-school purists.
Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
---
README | 69 +----------------------------------------------------
README.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 68 deletions(-)
mode change 100644 => 120000 README
create mode 100644 README.md
diff --git a/README b/README
deleted file mode 100644
index f8f196d..0000000
--- a/README
+++ /dev/null
@@ -1,68 +0,0 @@
-Welcome to kvm-unit-tests
-
-See http://www.linux-kvm.org/page/KVM-unit-tests for a high-level
-description of this project, as well as running tests and adding
-tests HOWTOs.
-
-This directory contains sources for a kvm test suite.
-
-To create the test images do
- ./configure
- make
-in this directory. Test images are created in ./<ARCH>/*.flat
-
-Then use the runner script to detect the correct invocation and
-invoke the test, e.g.
- ./x86-run ./x86/msr.flat
-or
- ./run_tests.sh
-to run them all.
-
-To select a specific qemu binary, specify the QEMU=<path>
-environment variable, e.g.
- QEMU=/tmp/qemu/x86_64-softmmu/qemu-system-x86_64 ./x86-run ./x86/msr.flat
-
-To create and use standalone tests do
- ./configure
- make standalone
- (send tests/some-test somewhere)
- (go to somewhere)
- ./some-test
-
-'make install' will install all tests in PREFIX/share/kvm-unit-tests/tests,
-each as a standalone test.
-
-Directory structure:
-.: configure script, top-level Makefile, and run_tests.sh
-./scripts: helper scripts for building and running tests
-./lib: general architecture neutral services for the tests
-./lib/<ARCH>: architecture dependent services for the tests
-./<ARCH>: the sources of the tests and the created objects/images
-
-See <ARCH>/README for architecture specific documentation.
-
-CONTRIBUTING:
-=============
-
-Style
------
-
-Currently there is a mix of indentation styles so any changes to
-existing files should be consistent with the existing style. For new
-files:
-
- - C: please use standard linux-with-tabs
- - Shell: use TABs for indentation
-
-Patches
--------
-
-Patches are welcome at the KVM mailing list <kvm@vger.kernel.org>.
-
-Please prefix messages with: [kvm-unit-tests PATCH]
-
-You can add the following to .git/config to do this automatically for you:
-
-[format]
- subjectprefix = kvm-unit-tests PATCH
-
diff --git a/README b/README
new file mode 120000
index 0000000..42061c0
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+README.md
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..5027b62
--- /dev/null
+++ b/README.md
@@ -0,0 +1,81 @@
+# Welcome to kvm-unit-tests
+
+See http://www.linux-kvm.org/page/KVM-unit-tests for a high-level
+description of this project, as well as running tests and adding
+tests HOWTOs.
+
+# Building the tests
+
+This directory contains sources for a kvm test suite.
+
+To create the test images do:
+
+ ./configure
+ make
+
+in this directory. Test images are created in ./<ARCH>/*.flat
+
+## Standalone tests
+
+The tests can be built as standalone
+To create and use standalone tests do:
+
+ ./configure
+ make standalone
+ (send tests/some-test somewhere)
+ (go to somewhere)
+ ./some-test
+
+'make install' will install all tests in PREFIX/share/kvm-unit-tests/tests,
+each as a standalone test.
+
+
+# Running the tests
+
+Then use the runner script to detect the correct invocation and
+invoke the test:
+
+ ./x86-run ./x86/msr.flat
+or:
+
+ ./run_tests.sh
+
+to run them all.
+
+To select a specific qemu binary, specify the QEMU=<path>
+environment variable:
+
+ QEMU=/tmp/qemu/x86_64-softmmu/qemu-system-x86_64 ./x86-run ./x86/msr.flat
+
+# Contributing
+
+## Directory structure
+
+ .: configure script, top-level Makefile, and run_tests.sh
+ ./scripts: helper scripts for building and running tests
+ ./lib: general architecture neutral services for the tests
+ ./lib/<ARCH>: architecture dependent services for the tests
+ ./<ARCH>: the sources of the tests and the created objects/images
+
+See <ARCH>/README for architecture specific documentation.
+
+## Style
+
+Currently there is a mix of indentation styles so any changes to
+existing files should be consistent with the existing style. For new
+files:
+
+ - C: please use standard linux-with-tabs
+ - Shell: use TABs for indentation
+
+## Patches
+
+Patches are welcome at the KVM mailing list <kvm@vger.kernel.org>.
+
+Please prefix messages with: [kvm-unit-tests PATCH]
+
+You can add the following to .git/config to do this automatically for you:
+
+ [format]
+ subjectprefix = kvm-unit-tests PATCH
+
--
2.11.0
^ permalink raw reply related
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-1-alex.bennee@linaro.org>
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
--
2.11.0
^ permalink raw reply related
* [kvm-unit-tests PATCH 5/6] docs: mention modifying env vars in README
From: Alex Bennée @ 2017-01-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-1-alex.bennee@linaro.org>
I had started adding a series of flags to control the run-time
behaviour of the tests but it was pointed out env vars can already do
that. Mention them in the README so others can find out to.
Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
---
README.md | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/README.md b/README.md
index 9462824..fa3a445 100644
--- a/README.md
+++ b/README.md
@@ -47,6 +47,14 @@ environment variable:
QEMU=/tmp/qemu/x86_64-softmmu/qemu-system-x86_64 ./x86-run ./x86/msr.flat
+To force the acceleration mode:
+
+ ACCEL=tcg ./run_tests.sh
+
+To extend or disable the timeouts:
+
+ TIMEOUT=0 ./run_tests.sh
+
# Contributing
## Directory structure
--
2.11.0
^ 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