Hi Peter,
On Tue, Apr 29, 2014 at 10:31:42PM +0100, Peter Feuerer wrote:
> Peter Feuerer writes:
>
> > Javi Merino writes:
> [...]
>
> >>> diff --git a/drivers/thermal/gov_bang_bang.c
> >>> b/drivers/thermal/gov_bang_bang.c
> >>> new file mode 100644
> >>> index 000..328dde0
> >>> --- /dev/
From: Kamil Debski
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHC
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.
Signed-off-by: Kamil Debski
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: a
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cfa3755..16b860a 10
Thanks for the patch.
Acked-by: Anil Gurumurthy
-Original Message-
From: Alexey Khoroshilov [mailto:khoroshi...@ispras.ru]
Sent: 18 April 2014 13:29
To: Anil Gurumurthy; Sudarsana Kalluru
Cc: Alexey Khoroshilov; James E.J. Bottomley; linux-scsi; linux-kernel;
ldv-proj...@linuxtesting.org
Add required device node for ehci and ohci controllers to
enable USB 2.0 support.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch
Next version for earlier patch-series:
[PATCH v7 0/2] dts: Add usb2phy to Exynos 5250
Based on 'for-next' branch of Kgene's linux-samsung tree.
Tested with driver side patches:
[PATCH v2 1/4] usb: ohci-exynos: Use struct device instead of platform_device
[PATCH v2 2/4] usb: ehci-exynos: Use struc
On Wed, Apr 30, 2014 at 06:40:38PM -0400, Wang, Xiaoming wrote:
> loops_per_jiffy*Hz is not always 1 second exactly
> it depends on the realization of _delay() .
> delay_tsc is used as _delay() in arch/x86/lib/delay.c
This just states delay() is broken. The primary response should be to
try and f
Hi Maxime,
Am Donnerstag, den 17.04.2014, 13:58 +0200 schrieb Maxime Ripard:
> I still feel like we should really treat gpios like just another reset
> controller, ie. using the resets property.
I now feel like we really shouldn't. If we do anything but use the
generic gpio bindings for reset gpi
On 4 April 2014 12:05, Viresh Kumar wrote:
> I know you are not going to look at these before end of this merge window and
> you wanted to have a look at V1 before me posting these. But I am reposting
> them
> now due to these reasons:
> - Need to resend my cpu isolation (cpuset.quiesce) patches
On 21 April 2014 15:24, Viresh Kumar wrote:
> As suggested by you (https://lkml.org/lkml/2014/4/14/797), this is the second
> lot of changes I have. I have divided the earlier patchset into three parts:
> - Bugfixes, already merged
> - Code cleanups which shouldn't have any functional change
> - C
On Wed, Apr 30, 2014 at 06:40:38PM -0400, Wang, Xiaoming wrote:
> loops_per_jiffy*Hz is not always 1 second exactly
> it depends on the realization of _delay() .
> delay_tsc is used as _delay() in arch/x86/lib/delay.c
> It makes loop loops_per_jiffy larger than exception
> and causes one thread ca
From: Jan Moskyto Matejka
> Fixed different size cast warning:
>
> drivers/net/ethernet/via/via-rhine.c: In function
> rhine_init_one_platform:
> drivers/net/ethernet/via/via-rhine.c:1132:13: warning: cast from
> pointer to integer of different
> size [-Wpointer-to-int-cast]
>
On SMP system, if cpuX is idle and it starts an hrtimer, the timer
will be started on cpuY. But it can not reprogram the event source
on cpuY. The timer is inserted into rb tree of cpuY, if it is the
leftmost timer on cpuY and it is a very short timer, following hrtimers
started on cpuY will also n
On 2014-04-30 08:57, Chase Southwood wrote:
This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1
(dev->iobase), don't bother reading the unused PCI bars.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
2: Bad PCI bar numbers corrected.
3: Fixed silly
Sure (5250, 5420). I will wait for the same to update DT patches, if any.
Regards,
Rahul Sharma.
On 30 April 2014 14:02, Tomasz Stanislawski wrote:
> Hi Rahul,
> I will prepare we v3 version.
> Do you want me to add your patches for exynos5?50 to the patchset?
> Regards,
> Tomasz Stanislawski
>
Hi Pankaj,
On 30 April 2014 10:47, Pankaj Dubey wrote:
> Many files under "arm/mach-exynos" are having file path in file
> comment section which is invalid now.
> So for better code maintainability let's remove them.
>
> Signed-off-by: Pankaj Dubey
> Reviewed-by: Tomasz Figa
> ---
The change i
GPIO 0 is a valid GPIO so allow using it as external control for
S2MPS14 regulators.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/s2mps11.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2m
Hi,
El 30/04/14 05:25, Александр Берсенев escribió:
This patch enables to use devm_clk_get function to get gate clocks by name.
Signed-off-by: Alexander Bersenev
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 31584ee..3617681 100644
--- a/drivers/clk/sunxi/clk
GPIO 0 is a valid GPIO so allow using it as external control for
regulator.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/s5m8767.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index
On 15/04/14 14:24, Paul Bolle wrote:
> From: Richard Weinberger
>
> References to the Kconfig symbol CPU_MMP3 were added to the tree since
> v3.6. But that Kconfig symbol has never been part of the tree. So get
> rid of these references.
>
> Signed-off-by: Richard Weinberger
> Signed-off-by: Pa
On Tue 29-04-14 23:59:09, Jidong Xiao wrote:
> On Tue, Apr 29, 2014 at 11:31 PM, Jidong Xiao wrote:
> > Hi,
> >
> > I noticed this variable, defined in mm/nommu.c,
> >
> > mm/nommu.c:int heap_stack_gap = 0;
> >
> > This variable only shows up once, and never shows up in elsewhere.
> >
> > Can some
On 04/30/2014 12:12 PM, Michal Hocko wrote:
On Wed 30-04-14 12:04:04, Maxim Patlasov wrote:
Hi Rik!
On 04/29/2014 11:19 PM, Rik van Riel wrote:
It is possible for "limit - setpoint + 1" to equal zero, leading to a
divide by zero error. Blindly adding 1 to "limit - setpoint" is not
working, so
Hi Rahul,
I will prepare we v3 version.
Do you want me to add your patches for exynos5?50 to the patchset?
Regards,
Tomasz Stanislawski
On 04/30/2014 08:37 AM, Rahul Sharma wrote:
> Hi Tomasz,
>
> I have tested your patches for exynos5250 and 5420. Works fine. Are
> you planning to post v3? If yo
loops_per_jiffy*Hz is not always 1 second exactly
it depends on the realization of _delay() .
delay_tsc is used as _delay() in arch/x86/lib/delay.c
It makes loop loops_per_jiffy larger than exception
and causes one thread can not obtain the spin lock for
a long time which may trigger HARD LOCKUP i
Hello Kgene,
Can you please pick this patch to your tree ?
Best Wishes,
Leela Krishna.
On Wed, Apr 30, 2014 at 1:32 PM, Chanwoo Choi wrote:
> Hi,
>
> On 04/23/2014 02:52 PM, Leela Krishna Amudala wrote:
>> A common macro v7_exit_coherency_flush available which does the below tasks
>> in
>> the
On Mon, Apr 28, 2014 at 03:09:01PM -0700, Davidlohr Bueso wrote:
> +/*
> + * Try to acquire write lock before the writer has been put on wait queue.
> + */
> +static inline bool rwsem_try_write_lock_unqueued(struct rw_semaphore *sem)
> +{
> + long count = ACCESS_ONCE(sem->count);
> +retry:
> +
On 29/04/14 15:21, Masanari Iida wrote:
> Fix format string mismatch in contrast_show().
>
> Signed-off-by: Masanari Iida
> ---
> 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
Am Dienstag, den 29.04.2014, 15:44 -0500 schrieb Rob Herring:
> On Tue, Apr 29, 2014 at 11:37 AM, Philipp Zabel
> wrote:
> > Add Linear Technology Corporation to the list of device tree vendor
> > prefixes.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > Documentation/devicetree/bindings/vend
Hi,
This isn't a very big patchset and this patch is very much required to
understand other patches and so please cc all people from other
list here as well..
On Wed, Apr 30, 2014 at 11:58 AM, Jonghwan Choi wrote:
> In the frequency table dts file, the frequencies are arranged in
Improve your l
On Tue, 29 Apr 2014, Davidlohr Bueso wrote:
> On Tue, 2014-04-29 at 20:14 -0400, Dave Jones wrote:
> >
> > futex(uaddr=0x7f55ff8c4000, op=0x6, val=0x20006223800b,
> > utime=0x7f55ff8c4000, uaddr2=0x7f55ff8c4000, val3=-123)
>
> Perhaps because of chance. Even for pi futexes, if the lock is
>
On 30/04/14 07:42, Alexey Charkov wrote:
Current code only touches the direction register when setting direction
to output, which breaks logic like
echo high > /sys/class/gpio/gpio0/direction
which is expected to also set the value. This patch also adds a call
to update the value register when
Hi Alessandro,
you did not reply to my patch submission.
Why not?
Tony Olech
Dialog Semiconductor
> -Original Message-
> From: Opensource [Anthony Olech]
> [mailto:anthony.olech.opensou...@diasemi.com]
> Sent: 02 April 2014 12:46
> To: Alessandro Zummo; Support Opensource
> Cc: linux-kerne
Hi,
On 04/29/2014 04:21 PM, Patrik Jakobsson wrote:
> This driver takes control over the LP8550 backlight driver chip found
> in the mid 2013 and newer MacBook Air (6,1 and 6,2). The i915 GPU driver
> cannot properly restore the backlight after resume, but with this driver
> we can hijack the LP85
On 30 April 2014 05:34, Roger wrote:
>
> On 04/29/2014 08:46 PM, Arnd Bergmann wrote:
>>
>> On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote:
>>>
>>> On 29 April 2014 11:45, Arnd Bergmann wrote:
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
:(.text+0x806480): unde
On 04/30/2014 05:59 AM, Michael Neuling wrote:
> Anshuman Khandual wrote:
>
>> On 04/29/2014 01:52 PM, Michael Neuling wrote:
>>> That's not what that patch does. It shouldn't make any user visible changes
>>> to DSCR or PPR.
>>
>> It may not when it runs uninterrupted but after the tracee proces
On Wednesday 30 April 2014 12:34 PM, Rusty Russell wrote:
> Ingo Molnar writes:
>> * Madhavan Srinivasan wrote:
>>
>>> Performance data for different FAULT_AROUND_ORDER values from 4 socket
>>> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
>>> is used to get the stddev
On Tue, 2014-04-29 at 23:07 +0200, Jan Kara wrote:
> On Tue 29-04-14 11:38:04, Andy Shevchenko wrote:
> > On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
> > > On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
> > > > On Mon, 28 Apr 2014 19:51:39 +0200
> > > > Jan Kara wrote:
> > > >
> > > > > O
On Wed 30-04-14 12:04:04, Maxim Patlasov wrote:
> Hi Rik!
>
> On 04/29/2014 11:19 PM, Rik van Riel wrote:
> >It is possible for "limit - setpoint + 1" to equal zero, leading to a
> >divide by zero error. Blindly adding 1 to "limit - setpoint" is not
> >working, so we need to actually test the divi
add "device_prep_dma_memcpy" and "device_prep_dma_sg" for memory copy by sdma.
Signed-off-by: Robin Gong
---
change:
--v3:
1. remove redundant check for bus width
--v2:
1. correct some printk format, such as %pad for dma_addr_t
2. split duplicated code in prep_dma_memcpy and prep_dma_sg t
Hi Rik!
On 04/29/2014 11:19 PM, Rik van Riel wrote:
It is possible for "limit - setpoint + 1" to equal zero, leading to a
divide by zero error. Blindly adding 1 to "limit - setpoint" is not
working, so we need to actually test the divisor before calling div64.
The patch looks correct, but I'm
On Tue, Apr 29, 2014 at 11:21:48PM -0400, Oleg Drokin wrote:
> I can rediff this patch with this particular part dropped if there are
> any concerns and it's possible to reintegrate it in a changed form.
No no. I knew that Greg had already merged this stuff by the time I got
around to reviewing i
These patches allow the pca953x family of chips to use a
shared interrupt.
Toby Smith (2):
gpio: pca953x: return IRQ_NONE when appropriate
gpio: pca953x: request a shared interrupt
drivers/gpio/gpio-pca953x.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
1.8.3.2
--
To
Hi,
On 04/23/2014 02:52 PM, Leela Krishna Amudala wrote:
> A common macro v7_exit_coherency_flush available which does the below tasks in
> the seqeunce.
> -clearing C bit
> -clearing L1 cache
> -exit SMP
> -instruction and data synchronization
>
> So removing the local functions which does the s
The irq handler should return IRQ_NONE or IRQ_HANDLED to report
if we have handled the interrupt.
Signed-off-by: Toby Smith
---
drivers/gpio/gpio-pca953x.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index d5
On Mon, Apr 28, 2014 at 03:09:01PM -0700, Davidlohr Bueso wrote:
> @@ -26,6 +27,10 @@ struct rw_semaphore {
> longcount;
> raw_spinlock_t wait_lock;
> struct list_headwait_list;
> +#ifdef CONFIG_SMP
> + struct task_struct *owner;
Request a shared interrupt when requesting a pca953x GPIO interrupt
Signed-off-by: Toby Smith
---
drivers/gpio/gpio-pca953x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 83cc2c8..6398f8a 100644
--- a/driver
Hi Tomasz,
On 04/26/2014 09:25 AM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 25.04.2014 03:16, Chanwoo Choi wrote:
>> This patch decide proper lowpower mode of either a15 or a9 according to own
>> ID
>> from Main ID register.
>>
>> Cc: Arnd Bergmann
>> Cc: Marc Zynigier
>> Signed-off-by: Chanwoo
On 04/28/2014 06:10 PM, Lee Jones wrote:
From: Roger Tseng
Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.
Signed-off-by: Roger Tseng
---
drivers/memstick/host/Kconfig | 10 +
drivers/memstick/host/Makefile | 1
This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1
(dev->iobase), don't bother reading the unused PCI bars.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
2: Bad PCI bar numbers corrected.
3: Fixed silly typos in the changelog
drivers/staging/come
According commit d640113fe(ACPI: processor: fix acpi_get_cpuid for UP
processor), Bios may not provide _MAT or MADT tables and acpi_get_apicid()
always returns -1. For these cases, original code will pass apic_id with
vaule of -1 to acpi_map_cpuid() and it will check the acpi_id. If acpi_id
is equ
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 30 Apr 2014 09:31:54 +0200 Peter Zijlstra
wrote:
> On Wed, Apr 30, 2014 at 12:29:26PM +1000, NeilBrown wrote:
> > If you think it is a good cleanup I'll post a proper patch with all the
> > right
> > Cc:s.
>
> Yeah, its a good cleanup. Thanks!
>
> > +static inline int
> > +wait_on_bit(
Ian and Hartley,
Thanks so much, I greatly appreciate the review. I'll fix the
changelog for patch 4 and send once more (as I assume that's easier
for Greg). Also, I should know better about the cover letter as
well...I was once told not to send them for strictly cleanup patchsets
(as Greg can't
On 04/30/2014 02:00 AM, Robert Richter wrote:
On 29.04.14 15:40:28, Myron Stowe wrote:
On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote:
So sounds to me like we want to get rid of the whole IO ECS deal
altogether then.
Now, I'm wondering whether we should kill it completely since I do
Theodore Ts'o writes:
> On Wed, Apr 30, 2014 at 12:16:41AM +, Serge Hallyn wrote:
>> I forget the details, but there was another case where I wanted to
>> have the userns which 'owns' the whole fs available. I guess we'd
>> have to check against that instead of using inode_capable.
>
> Yes,
Hi James,
Perhaps Michael and Sam would be interested in sharing the role, for atari
and sun3 NCR5380 drivers (?)
If you insist ...
(kidding - I"m OK with it if James thinks it's worth it)
As long as you understand how it works and how to fix it, the more the
merrier. It gives me more people
On Wed, Apr 30, 2014 at 06:17:48AM +, Wang, Xiaoming wrote:
> Dear Peter
> If we wait the end of loop as loops_per_jiffy.
> It may last more than 130s and local IRQ disabled at interval
> which may cause Hard LOCKUP. We break out in 1 second and
> dump the stack for debug.
Yeah, so? Th
On Tue, 2014-04-29 at 20:13 -0400, Steven Rostedt wrote:
> On Tue, 29 Apr 2014 07:21:09 +0200
> Mike Galbraith wrote:
>
> > On Mon, 2014-04-28 at 16:37 +0200, Mike Galbraith wrote:
> >
> > > > Seems that migrate_disable() must be called before taking the lock as
> > > > it is done in every oth
On Wed, Apr 30, 2014 at 09:31:54AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 30, 2014 at 12:29:26PM +1000, NeilBrown wrote:
> > If you think it is a good cleanup I'll post a proper patch with all the
> > right
> > Cc:s.
>
> Yeah, its a good cleanup. Thanks!
Also, please add Oleg to the Cc, he w
On Wed, Apr 30, 2014 at 12:29:26PM +1000, NeilBrown wrote:
> If you think it is a good cleanup I'll post a proper patch with all the right
> Cc:s.
Yeah, its a good cleanup. Thanks!
> +static inline int
> +wait_on_bit(void *word, int bit, unsigned mode)
> +{
> + if (!test_bit(bit, word))
> +
Hi Sachin,
On 04/30/2014 03:00 PM, Sachin Kamat wrote:
Hi Pankaj,
On 30 April 2014 10:47, Pankaj Dubey wrote:
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertio
On Thu, Apr 24, 2014 at 04:22:44PM +0200, Maxime Ripard wrote:
> The Allwinner A31 has a 16 channels DMA controller that it shares with the
> newer A23. Although sharing some similarities with the DMA controller of the
> older Allwinner SoCs, it's significantly different, I don't expect it to be
>
> Subject: Re: [PATCHv3 0/2] add DT endianness binding support
>
> Shouldn't this go to the arm list and rmk for review, too?
>
Well, yes, I forgot it.
Should I resend them ?
Thanks,
> Thanks,
> Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Ingo Molnar writes:
> * Madhavan Srinivasan wrote:
>
>> Performance data for different FAULT_AROUND_ORDER values from 4 socket
>> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
>> is used to get the stddev values. Test ran in v3.14 kernel (Baseline) and
>> v3.15-rc1 for
"Zhangjie (HZ)" writes:
> This is a small supplement for commit e7428e95a06fb516fac1308bd0e176e27c0b9287
> ("virtio-net: put virtio-net header inline with data"). TCP packages have
> enough room to put virtio-net header in, but UDP packages do not. By
> setting dev->needed_headroom for virtio-net
Shouldn't this go to the arm list and rmk for review, too?
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at htt
> > + * of_regmap_endian_by_type() - Parse and lookup the endian referenced
> > + * by a device node
> > + * @np: pointer to clock consumer node
>
> This is not the clock consumer, right?
>
Yes, you are right.
I will fix it.
> > + * @type: type of consumer's endian input
> > + *
> > + * This
On Wednesday 30 April 2014 11:34:33 Roger wrote:
> I think Ulf's idea is to fix the bug by modifying the .c files.
> I really found the problem of my ifdef hackery and it should do
> something similar in sdhci.c as:
>
> From: Roger Tseng
> Date: Wed, 30 Apr 2014 11:11:25 +0800
> Subject: [PATCH]
On 29.04.14 15:40:28, Myron Stowe wrote:
> On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote:
> > So sounds to me like we want to get rid of the whole IO ECS deal
> > altogether then.
> >
> > Now, I'm wondering whether we should kill it completely since I don't
> > think anyone cares about nu
701 - 770 of 770 matches
Mail list logo
