On 16/06/2014 10:08, Lee Jones wrote:
>> Hello Mark,
>>
>> Did you have time to take a look at this patch ?
>>
>> I'd like to post a new version of this series addressing Lee's comments,
>> but it would be great to have your feedback on this patch before posting
>> a new version.
> I wouldn't do
The tty_ldisc_flush() after port hardware shutdown is unnecessary;
the ldisc flush was just performed before the hardware shutdown
in tty_port_close_start() and the ldisc will be released when
uart_close() returns (because the last port close implies the
last tty close).
Signed-off-by: Peter
tty_port_close_start() already validates the port counts and issues
a diagnostic if validation fails.
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
ASYNC_CLOSING is no longer used in the tty core; use private flag
info->closing as substitute.
CC: Karsten Keil
CC: net...@vger.kernel.org
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 14 +++---
include/linux/isdn.h| 1 +
2 files changed, 8 insertions(+), 7
The low-level uart driver may modify termios settings to override
settings that are not compatible with the uart, such as CRTSCTS.
Thus, callers of the low-level uart driver's set_termios() method must
hold termios_rwsem write lock to prevent concurrent access to termios,
in case such override
Unwrap if() conditional; no functional change.
Signed-off-by: Peter Hurley
---
drivers/tty/serial/serial_core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index e97653e..f13a769 100644
---
The port->lock does not protect the filp->f_op field; move
the tty_hung_up_p() test outside the port->lock critical section
in tty_port_close_start().
Signed-off-by: Peter Hurley
---
drivers/tty/tty_port.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
ASYNC_CLOSING is no longer used in the tty core; use tty->closing
as substitute.
Signed-off-by: Peter Hurley
---
drivers/tty/mxser.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 4c4a236..573bc00 100644
---
blackfin uart port drivers mistakenly set the struct uart_port
flags bit UPF_BUG_THRE (which only has meaning to the 8250 core)
while trying to set ASYNC_CTS_FLOW.
Uart port drivers can override termios settings based on actual
hardware support in their .set_termios method; the serial core
sets
Since at least before 2.6.30, tty drivers that do not drop the tty lock
while closing cannot observe ASYNC_CLOSING set while holding the
tty lock; this includes the tty driver's open() and hangup() methods,
since the tty core calls these methods holding the tty lock.
For these drivers, waiting
On Thu 12-06-14 12:51:05, Johannes Weiner wrote:
> On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> > On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
> > > On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
> > [...]
> > > > Anyway, the situation now is pretty chaotic. I
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
However, dropping the tty lock is a hold-over from when the tty
lock was system-wide; ie., one lock for all
Hi,
so 3.16-rc1 adds this false positive from gcc, see below (triggers on
4.9 and 4.8.2). Now, it is firing wrong and gcc people tell me there's
no way for the compiler to know that the "from" and "to" values will NOT
be used in the error case, i.e. thus the "maybe" aspect.
So, we've disabled it
Hi Greg,
These patches are the accumulation of fixes resulting from audits
of the tty and serial cores; mostly cleanups of open() and close().
Most of the changes remove condition testing and handling which
cannot occur because the tty lock is held for the tty driver open()
call.
The exceptions
The tty lock is held when the tty driver's open() method is called
(from tty_open()). The call-tree audit [1] of tty_port_block_til_ready()
is a closed graph of the callers of tty_port_block_til_ready();
ie., all callers originate only from tty_open().
Of these callers, none drop the tty lock.
The tty lock is held when the tty driver's open method is called
(from the lone call-site, tty_open()). The call-tree audit [1] of
tty_port_open() is a closed graph of the callers of tty_port_open();
ie., all callers originate from only tty_open().
Of these callers, none drop the tty lock.
Also,
On Mon, 16 Jun 2014, Chanwoo Choi wrote:
> This patch add S2MPU02 regulator device to existing S2MPS11 device driver
> because of little difference between S2MPS1x and S2MPU02. The S2MPU02
> regulator device includes LDO[1-28] and BUCK[1-7].
>
> Signed-off-by: Chanwoo Choi
> [Add missing
The tty lock is held when the tty driver's .close method is called
(from the two lone call-sites of tty_release() and __tty_hangup()).
The call-tree audit[1] of tty_port_close(), tty_port_close_start,
and tty_port_close_end() is a closed graph of the callers of these
3 functions; ie., all callers
tty->closing informs the line discipline that the hardware will
be shutting down imminently, and to disable further input other
than soft flow control (but to still allow additional output).
However, the tty lock is the necessary lock for preventing
concurrent changes to tty->closing. As shown by
The tty core calls the tty driver's open, close and hangup
methods holding the tty lock.
Signed-off-by: Peter Hurley
---
include/linux/tty_driver.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index
The tty lock is held when the tty driver's hangup() method is called
(from the lone call-site, __tty_hangup()). The call-tree audit [1]
of tty_port_hangup() is a closed graph of the callers of
tty_port_hangup(); ie., all callers originate only from __tty_hangup().
Of these callers, none drop the
On 8 June 2014 03:09, Houcheng Lin wrote:
> The Problem
> ---
> The reset signal on a hardware board is send either:
> - during machine initialization
> - during bus master's initialization
>
> In some hardware design, devices on bus need a non-standard and extra reset
> signal
Fix ASYNC_* constant usage that should be the corresponding UPF_*
constant.
CC: Grant Likely
CC: Rob Herring
CC: devicet...@vger.kernel.org
Signed-off-by: Peter Hurley
---
drivers/tty/serial/lantiq.c | 2 +-
drivers/tty/serial/mcf.c| 4 ++--
2 files changed, 3 insertions(+), 3
Since at least before 2.6.30, it has not been possible to observe
a hung up file pointer in a tty driver's open() method unless/until
the driver open() releases the tty_lock() (eg., before blocking).
This is because tty_open() adds the file pointer while holding
the tty_lock() _and_ doesn't
tty->closing cannot be set on ipw_open() because the ipwireless tty
driver does not call any functions that set tty->closing.
CC: Jiri Kosina
CC: David Sterba
Signed-off-by: Peter Hurley
---
drivers/tty/ipwireless/tty.c | 5 -
1 file changed, 5 deletions(-)
diff --git
On Sunday 15 June 2014 11:25 AM, Vince Weaver wrote:
> Transition to using the new generic PERF_PMU_CAP_NO_INTERRUPT method for
> failing a sampling event when no PMU interrupt is available.
>
> Signed-off-by: Vince Weaver
Acked-by: Vineet Gupta
Thx,
-Vineet
>
> diff --git
2014-06-15 (일), 18:34 +0200, Jiri Olsa:
> On Sun, Jun 15, 2014 at 09:46:31PM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> >
> > 2014-06-15 (일), 10:35 +0200, Jiri Olsa:
> > > heya,
> > > not completely sure this is what we want to do, but have no
> > > streght to dive into annotation code ;-)
> >
>
During the last few years, several inline wrappers for DMA operations have
been introduced:
- commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave:
introduce inline wrappers"),
- commit a14acb4ac2a1486f6633c55eb7f7ded07f3ec9fc ("DMAEngine: add
On Sun, Jun 15, 2014 at 20:49, Jonathan Cameron wrote:
> Hi Adam,
>
> Some general comments inline.
>
> It's been a while since I've looked at any particularly similar parts,
> but it seems to me that a lot of indirection gets added here that
> if anything makes the codes slightly harder to
Hi,
the commit in $Subject breaks the purpose of the W= build to see
additional warnings.
With it, currently I get all that stuff disabled with gcc:
$ make V=1 W=1 fs/direct-io.o
...
gcc -Wp,-MD,... -Wno-sign-compare -Wno-missing-field-initializers
-Wno-unused-value -Wno-format
If CONFIG_PM_RUNTIME=n:
drivers/nfc/trf7970a.c:755: warning: ‘trf7970a_init’ defined but not used
Signed-off-by: Geert Uytterhoeven
---
drivers/nfc/trf7970a.c | 80 +-
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git
On Mon, 16 Jun 2014, Chanwoo Choi wrote:
> Add support for Samsung S2MPU02 PMIC device to the MFD sec-core driver.
> The S2MPU02 device includes PMIC/RTC/Clock devices.
>
> Signed-off-by: Chanwoo Choi
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/mfd/sec-core.c | 19 +
>
On 16 June 2014 09:22, Jeff Chua wrote:
> On Fri, Jun 13, 2014 at 8:28 PM, Ulf Hansson wrote:
>> On 13 June 2014 01:51, John Stultz wrote:
>>> On Wed, Jun 11, 2014 at 10:35 PM, John Stultz john.stu...@linaro.org> wrote:
>
>> I have quickly implemented my proposal 1). I am testing them on real
On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> original scan targets introduces extra 40 bytes on the stack. This patch
> is able to avoid this situation and the call to memcpy(). At the same time,
> it does not
+linux-omap.
On 06/15/2014 08:44 PM, Axel Lin wrote:
Might be nice to have a commit message here.
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/twl-regulator.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/regulator/twl-regulator.c
>
On Thu 12-06-14 12:17:33, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> > The primary question would be, whether this is is the best transition
> > strategy. I do not know how many users apart from developers are really
> > using unified
On 16 June 2014 13:06, Peter Griffin wrote:
> Currently the documentation doesn't match the code in mmc_of_parse. This
> patch rectifies this.
>
> Signed-off-by: Peter Griffin
Thanks! Applied to my mmc tree for next.
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 4
Hi,
i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
netconsole is used with vmbr0 (bridge) which is on top of bond0.
If i want to add another bridge to vmbr0 is fails as long as netconsole
is in use.
# brctl addif vmbr0 fwpr2004p0
can't add fwpr2004p0 to bridge vmbr0:
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
> > On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> [...]
> > > Arnd, can you take another look at this binding and see if there's
> > > anything else
On Mon, Jun 16, 2014 at 01:14:22PM +0200, Michal Hocko wrote:
> On Mon 16-06-14 17:24:38, Xishi Qiu wrote:
> > When system(e.g. smart phone) running for a long time, the cache often takes
> > a large memory, maybe the free memory is less than 50M, then OOM will happen
> > if APP allocate a large
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> Add support for the MFD device which will just retrieve HLCDC clocks and
> create a regmap so that
On 16 June 2014 11:09, micky wrote:
> On 06/16/2014 04:42 PM, Ulf Hansson wrote:
>>>
>>> @@ -36,7 +37,10 @@ struct realtek_pci_sdmmc {
>>> > struct rtsx_pcr *pcr;
>>> > struct mmc_host *mmc;
>>> > struct mmc_request *mrq;
>>> >+ struct
y
>
> By the way, I found myself staring at the entries in this file for quite
> some time. Perhaps things would have been easier to understand if
> SMS_USB_DRV and SMS_SDIO_DRV both selected SMS_SIANO_MDTV. But I didn't
> dare to test that idea.
This can still be seen in v3.16-rc1
Nick,
Sorry for the delay in responding.
I'm staring at the manual for the ca91c142 and the relevant bits in the
VSIx_CTL registers definitely need to be set to 0 for A16, likewise with
the LM_CTL register. The pattern (3<<16) would enable one of the
"reserved" address spaces.
Martyn
On
> From: Micky Ching
>
> rtsx driver using a single function for transfer data, dma map/unmap are
> placed in one fix function. We need map/unmap dma in different place(for
> mmc async driver), so add three function for dma map, dma transfer and
> dma unmap.
>
> Signed-off-by: Micky Ching
> ---
On Monday, June 16, 2014 11:17 AM, Daniel Jeong wrote:
>
> This driver a general version for tps611xx backlgiht chips of TI.
> It supports tps61158, tps61161, tps61163 and tps61165 backlight driver
> based on EasyScale protocol.
"EasyScale" protocol is a TI-specific protocol. How about adding
I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are
only needed on the MMP architecture. So add a hardware dependency on
ARCH_MMP, so that other users don't get to build useless drivers.
Signed-off-by: Jean Delvare
Cc: Chris Ball
Cc: Ulf Hansson
Cc: Eric Miao
Cc: Haojian
This series introduces DT support for crossbar device and
changes dra7 peripherals to use crossbar number instead of irq.
This depends on below driver fixes and cleanup series.
https://lkml.org/lkml/2014/6/16/218
[V2] Rebased on 3.15 mainline.
[V3] Added ti,irqs-skip property and
From: R Sricharan
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input
From: R Sricharan
There is a IRQ crossbar device in the soc, which maps the
irq requests from the peripherals to the mpu interrupt
controller's inputs. The gic provides the support for such
IPs in the form of routable-irqs. So adding the property
here to gic node.
Signed-off-by: Sricharan R
If INPCK is not set, input parity detection should be disabled. This means
parity errors should not be received from the tty driver, and the data
received should be treated normally.
SUS v3, 11.2.2, General Terminal Interface - Input Modes, states:
"If INPCK is set, input parity checking shall
If IGNBRK is set without either BRKINT or PARMRK set, some uart
drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
line discipline, when it should send either nothing or the TTYBREAK flag
set. This happens because the read_status_mask masks out the BI
condition, which
On 16/06/14 10:56, Dan Carpenter wrote:
On Mon, Jun 16, 2014 at 10:47:25AM +0100, Martyn Welch wrote:
Nick,
Sorry for the delay in responding.
I'm staring at the manual for the ca91c142 and the relevant bits in
the VSIx_CTL registers definitely need to be set to 0 for A16,
likewise with the
* Nishanth Menon [140606 08:30]:
> On 06/06/2014 04:52 AM, George Cherian wrote:
> > On 6/6/2014 12:23 PM, Nishanth Menon wrote:
> >> On 06/06/2014 01:17 AM, George Cherian wrote:
> >>> AM437x EPOS evm use external clock for RMII interface.
> >>> Enable the same in DT.
> >>>
> >>> Signed-off-by:
On 13/06/14 18:00, Daniel Kiper wrote:
>
> v5 - suggestions/fixes:
Put after a --- marker.
> +static efi_char16_t vendor[100] __initdata;
Why 100?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Fri, 13 Jun 2014, Daniel Kiper wrote:
> This patch enables EFI usage under Xen dom0. Standard EFI Linux
> Kernel infrastructure cannot be used because it requires direct
> access to EFI data and code. However, in dom0 case it is not possible
> because above mentioned EFI stuff is fully owned
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Signed-off-by: Jean Delvare
Cc: Samuel Ortiz
Cc: Lee Jones
---
Patch already sent on: 2014-04-03
drivers/mfd/Kconfig |2 +-
1 file
On Saturday 14 June 2014 10:53:29 Pavel Machek wrote:
> On Wed 2014-06-11 10:02:07, Pali Roh?r wrote:
> > Dell kernel driver dell-smo8800 provides same freefall
> > interface as hp_accel so program hpfall.c works also on
> > Dell laptops. So rename it to freefall.c.
> >
> > Dell driver does not
As far as I know, the CS5535 and CS5536 chipsets are companions of the
Geode series of processors, which are 32-bit only. So the CS5535
drivers are not needed on x86-64, except for build testing purpose.
This aligns the dependencies to what FB_GEODE already uses.
Signed-off-by: Jean Delvare
Cc:
On 06/16/2014 01:43 PM, Stefano Stabellini wrote:
On Fri, 13 Jun 2014, Daniel Kiper wrote:
efi_set_rtc_mmss() is never used to set RTC due to bugs found
on many EFI platforms. It is set directly by mach_set_rtc_mmss().
Signed-off-by: Daniel Kiper
---
arch/x86/platform/efi/efi.c |6
On 6/16/14, 2:09 PM, Paolo Bonzini wrote:
Il 16/06/2014 12:33, Nadav Amit ha scritto:
Do you get this if the input register has bit 31 set?
No. To be frank, the scenario may be considered a bit synthetic: the
guest assigns a value to a general-purpose register in 64-bit mode,
setting the high
gt;
> > config ARCH_SPEAR6XX
> > bool "ST SPEAr6XX"
> > - depends on ARCH_MULTI_V5 || PLAT_SPEAR_SINGLE
> > + depends on ARCH_MULTI_V5
> > depends on !ARCH_SPEAR13XX
> > select ARM_VIC
> > help
> > @@ -85,7 +84,7 @@ c
Evaluating a macro argument only if certain configuration options
have been selected is confusing and error-prone. Hence always
evaluate the second argument of spin_lock_nested() and
spin_lock_nest_lock().
This patch has the intentional side effect that it avoids that the
following warning is
On Fri, 13 Jun 2014, Daniel Kiper wrote:
> efi_set_rtc_mmss() is never used to set RTC due to bugs found
> on many EFI platforms. It is set directly by mach_set_rtc_mmss().
>
> Signed-off-by: Daniel Kiper
> ---
> arch/x86/platform/efi/efi.c |6 ++
> 1 file changed, 6 insertions(+)
>
>
On Thu, 2014-06-12 at 23:17 +0300, Dmitry Kasatkin wrote:
> Instead of allowing public keys, with certificates signed by any
> key on the system trusted keyring, to be added to a trusted keyring,
> this patch further restricts the certificates to those signed by a
> particular key on the system
On Thu, 2014-06-12 at 23:17 +0300, Dmitry Kasatkin wrote:
> Instead of allowing public keys, with certificates signed by any
> key on the system trusted keyring, to be added to a trusted keyring,
> this patch further restricts the certificates to those signed only by
> builtin keys on the system
On Sun, 15 Jun 2014, Jamie Lentin wrote:
> Signed-off-by: Jamie Lentin
> ---
> drivers/hid/Kconfig | 14 +-
> drivers/hid/Makefile | 2 +-
> drivers/hid/hid-core.c | 2 +-
> drivers/hid/{hid-lenovo-tpkbd.c
From: Nishanth Menon
Today '0' is actually reserved, but may not be the same in the future.
So, use a flag to mark the GIC interrupts that are reserved.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c |5 +++--
1 file changed, 3 insertions(+),
From: Nishanth Menon
Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value must be
From: Nishanth Menon
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
[V3]
From: Nishanth Menon
There is absolutely no need for crossbar driver to expose functions and
variables into global namespace. So make them all static
Also fix a couple of checkpatch warnings.
Fixes sparse warnings:
drivers/irqchip/irq-crossbar.c:129:29: warning: symbol
From: Nishanth Menon
Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This makes the below bugs visible sooner.
class 1. address space errors -> example:
reg =
ti,max-irqs = is a wrong parameter
class 2: irq-reserved list - which decides which
From: Nishanth Menon
Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
middle will not result in spurious changes, so rename the error paths
as per the function it does.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c | 23
Hi Peter,
On 06/16/2014 11:23 AM, Peter Griffin wrote:
This patch fixes two problems: -
1) The device tree isn't currently providing sti-ethclk which is
required by the dwmac glue code to correctly configure the ethernet
PHY clock speed.
This means depending on what the bootloader/jtag has
If crossbar_of_init returns with a error, then set the cb pointer
to null.
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 5bd7f3d..9b4c0f1 100644
---
From: Nishanth Menon
Currently we attempt to map any crossbar value to an IRQ, however,
this is not correct from hardware perspective. There is a max crossbar
event number upto which hardware supports. So describe the same in
device tree using 'ti,max-crossbar-sources' property and use it to
Adding kerneldoc for unmap callback function.
Signed-off-by: Sricharan R
---
[V3] Reworded the kerneldoc
drivers/irqchip/irq-crossbar.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 9b4c0f1..df16ef8
From: Nishanth Menon
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in our
On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit
From: Nishanth Menon
This is a basic check to ensure that crossbar register needs to be
written. This ensures that we have a common check which is used in
both map and unmap logic.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c | 14
From: Nishanth Menon
The current crossbar description does not include the description
required for the consumer of the crossbar, a.k.a devices whoes events
pass through the crossbar into the GIC interrupt controller.
So, provide documentation for the same.
Signed-off-by: Nishanth Menon
From: Nishanth Menon
crossbar_of_init always returns -ENOMEM in case of errors.
There can be other causes of failure like invalid data from
DT. So return a appropriate error value for that case.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
[V3] Changed commit log
From: Nishanth Menon
IS_ERR_VALUE makes sense only *if* there could be valid values in
negative error range. But in the cases that we do use it, there is no
such case. Just remove the same.
Signed-off-by: Nishanth Menon
Signed-off-by: Sricharan R
---
drivers/irqchip/irq-crossbar.c |6
From: Nishanth Menon
If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already allocated.
From: Nishanth Menon
Adding missing properties for kerneldoc (@write) and cleanup
of harmless warnings while we are here.
kerneldoc warnings:
Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description
on line:
* struct crossbar_device: crossbar device description
On 06/12/2014 11:38 AM, Jisheng Zhang wrote:
For all BG2Q SoCs, 2 cycles is the best/correct value
Signed-off-by: Jisheng Zhang
Applied to berlin/dt with following fixed patch title:
"ARM: dts: berlin2q: set L2CC tag and data latency to 2 cycles"
Thanks!
---
This series does some cleanups, fixes for handling two interrupts
getting mapped twice to same crossbar and provides support for
hardwired IRQ and crossbar definitions.
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
131, 132, 133 are direct wired to hardware blocks bypassing
2014-06-15 16:48 GMT+02:00 Boris BREZILLON :
>
>
> Hello JJ,
>
> On 15/06/2014 10:53, Jean-Jacques Hiblot wrote:
> > On 06/09/2014 06:04 PM, Boris BREZILLON wrote:
> >> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> >> family or sama5d3 family) exposes 2 subdevices:
> >>
Hi,
Il giorno 04/giu/2014, alle ore 15:04, Tejun Heo ha scritto:
> Hello,
>
>> […]
>> The problem is not the duration of the plugging, but the fact that, if a
>> request merge
>> succeeds for a bio, then there will be no set_request invocation for that
>> bio.
>> Therefore, without early
On 06/03/2014 09:33 AM, Antoine Ténart wrote:
Enable the I2C0 and I2C2 for the Marvell Berlin BG2G DMP. I2C1 and I2C3
are also working on this board, but no devices seemed to be there.
Signed-off-by: Antoine Ténart
Applied to berlin/dt with Andrew's Reviewed-by.
Thanks!
---
On 06/03/2014 09:33 AM, Antoine Ténart wrote:
The Marvell Berlin BG2Q has 4 TWSI compatible with the Synopsys
DesignWare I2C driver. Add the corresponding nodes.
The pin-muxing setup is also done here, since there cannot be another
muxing setup if I2C{0,1,2,3} are enabled.
Signed-off-by:
From: Anil Belur
fixed: ERROR: do not initialise statics to 0 or NULL
Signed-off-by: Anil Belur
---
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > 2) Fixed a bug in patch #2 so that it would work correctly if the rng
> > driver doesn't have an init function (which happens to be the case for
> > the tpm-rng driver, which I used for my testing).
>
> The whole thing stems from
On 06/13/2014 10:33 PM, Doug Anderson wrote:
> Tushar,
>
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera wrote:
>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>
> If you want to be a stickler about it, peach-pi actually has a
> max98091. That requires code changes to
From: Anil Belur
fixed: WARNING: suspect code indent for conditional statements (32, 32)
Signed-off-by: Anil Belur
---
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
From: Anil Belur
fixed: WARNING: line over 80 characters, used a new variable 'check' to
store the offset. Replace "unsigned long" with "u64" type fir
'cur_index'
Signed-off-by: Anil Belur
---
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 5 +++--
1 file changed, 3 insertions(+), 2
On Mon, 16 Jun 2014, Andreas Schwab wrote:
> > Adding "--param allow-store-data-races=0" to the GCC options for the
> > kernel breaks C=1 because Sparse isn't expecting a GCC option with that
> > format.
>
> Please try --param=allow-store-data-races=0 instead.
How reliable is this format across
Resending patches as per changes recommend by "oleg.dro...@intel.com" for 1/8
and 7/8.
PATCH 1/8: Now have removed the '+' to make the code more straight forward.
The patch v3 7/7 is now split into two separate patches as both are related
diff warning or error.
--
To unsubscribe from this list:
From: Anil Belur
Fixed "ERROR: need consistent spacing around '+' (ctx:WxV)"
Signed-off-by: Anil Belur
---
drivers/staging/lustre/lustre/lclient/glimpse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/lclient/glimpse.c
From: Anil Belur
fixed warning:
* WARNING: min() should probably be min_t(__u32, desc.ld_tgt_count,
LOV_MAX_STRIPE_COUNT)
Signed-off-by: Anil Belur
---
drivers/staging/lustre/lustre/lclient/lcommon_misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
601 - 700 of 1732 matches
Mail list logo
