On 03/25/2014 08:30 PM, Mark Brown wrote:
> On Tue, Mar 25, 2014 at 06:49:22PM +0800, Alex Shi wrote:
>> From: Eduardo Valentin <eduardo.valentin(a)ti.com>
>
> Dropping a bunch of irrelevant people/lists.
>
>> This patch changes a dtsi file to contain the thermal data
>> for MPU domain on OMAP4 and later SoCs. This data will
>> enable the passive cooling with CPUfreq cooling device
>> at 100C and the system will do a thermal shutdown at 125C.
>>
>> This thermal data can be reused across TI SoC devices.
>
> We probably shouldn't in general have DTS patches backported to LSK
> unless we're using them for testing - they aren't needed by people using
> the feature and may interfere with downstream users working on these
> boards who have their own modifications. Of course this is OMAP4 which
> is used on Panda so it might make sense since that's already part of our
> test coverage...
>
Yes, the testing show it is ok now. But you are right. it's better not
have this change when think of downstream users. I will remove all dts
patches.
--
Thanks
Alex
From: Mark Brown <broonie(a)linaro.org>
There is no real reason why we require transfers to have a completion and
the only user of the completion now checks to see if one has been provided
before using it so stop enforcing this. This makes it more convenient for
drivers to chain multiple asynchronous transfers together.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/spi/spi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 26b331d27c35..121c43b5a8e8 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1812,8 +1812,6 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message)
if (list_empty(&message->transfers))
return -EINVAL;
- if (!message->complete)
- return -EINVAL;
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
--
1.9.1
This small series fixes issues found with the kprobes tests during
testing of Dave Long's latest ARM uprobe patches [1]. Whilst these fixes
are based on top of that series all the bugs are already present in the
kernel tree.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238862.html
Contents:
Jon Medhurst (3):
ARM: kprobes: Prevent known test failures stopping other tests running
ARM: kprobes: Disallow instructions with PC and register specified shift
ARM: kprobes: Fix test code compilation errors for ARMv4 targets
arch/arm/kernel/kprobes-test-arm.c | 33 +++++++++++++++++++++------------
arch/arm/kernel/kprobes-test.c | 10 ++++++++++
arch/arm/kernel/probes-arm.c | 6 +++---
One of the comments in tick_handle_periodic() had 'when' instead of 'which' (My
guess :)). Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..791a3a2 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -118,7 +118,7 @@ void tick_handle_periodic(struct clock_event_device *dev)
* to be sure we're using a real hardware clocksource.
* Otherwise we could get trapped in an infinite
* loop, as the tick_periodic() increments jiffies,
- * when then will increment time, posibly causing
+ * which then will increment time, posibly causing
* the loop to trigger again and again.
*/
if (timekeeping_valid_for_hres())
--
1.7.12.rc2.18.g61b472e
One of the comments in tick_handle_periodic() had 'when' instead of 'which' (My
guess :)). Fix it.
Also fix spelling mistake in 'Possible'.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V1->V2: Fix spelling mistake of possible as well.
kernel/time/tick-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..0fec634 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -118,7 +118,7 @@ void tick_handle_periodic(struct clock_event_device *dev)
* to be sure we're using a real hardware clocksource.
* Otherwise we could get trapped in an infinite
* loop, as the tick_periodic() increments jiffies,
- * when then will increment time, posibly causing
+ * which then will increment time, possibly causing
* the loop to trigger again and again.
*/
if (timekeeping_valid_for_hres())
--
1.7.12.rc2.18.g61b472e
tick_handle_periodic() is calling ktime_add() at two places, first before the
infinite loop and then at the end of infinite loop. We can rearrange code a bit
to fix code duplication here.
It looks quite simple and shouldn't break anything, I guess :)
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-common.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..d610ae3 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -98,18 +98,19 @@ static void tick_periodic(int cpu)
void tick_handle_periodic(struct clock_event_device *dev)
{
int cpu = smp_processor_id();
- ktime_t next;
+ ktime_t next = dev->next_event;
tick_periodic(cpu);
if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
return;
- /*
- * Setup the next period for devices, which do not have
- * periodic mode:
- */
- next = ktime_add(dev->next_event, tick_period);
for (;;) {
+ /*
+ * Setup the next period for devices, which do not have
+ * periodic mode:
+ */
+ next = ktime_add(next, tick_period);
+
if (!clockevents_program_event(dev, next, false))
return;
/*
@@ -123,7 +124,6 @@ void tick_handle_periodic(struct clock_event_device *dev)
*/
if (timekeeping_valid_for_hres())
tick_periodic(cpu);
- next = ktime_add(next, tick_period);
}
}
--
1.7.12.rc2.18.g61b472e
