Prevent writing to reserved bits, queue index is 0-127
Change-ID: Ic923e1c92012a265983414acd8f547c4bdac2e34
Signed-off-by: Christopher Pau <christopher.pau@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Driver needs to initialize all members of context descriptor. Stale
data is possible otherwise.
Change-ID: Idc6b53af45583509da42d5ec0824cbaf78aee64f
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
With the auto_disable flags added there was a bug that was causing the
replay logic to not work correctly.
This patch fixes the issue so that we call a replay after a sideband
reset correctly.
Change-ID: I005fe1ac361188ee5b19517a83c922038cba1b00
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I received a report this morning from one of the Novena developers that
the behaviour of the iMX6 ASoC codec driver (using imx-pcm-dma.c) was
sub-optimal under high system load.
While there are issues relating to system load remaining, upon reviewing
the ASoC imx-pcm-dma.c driver, it was noticed that it not using the
residue support, because SDMA doesn't support it. This has the effect
that SDMA has to make multiple calls into the ASoC and ALSA code, one
for each period.
Since ALSA's snd_pcm_elapsed() does not need to be called multiple times
and it is entirely sufficient to call it once to update ALSA with the
current buffer position via the pointer method, we can do better here.
We can also avoid stopping the DMA entirely, just like real cyclic DMA
implementations behave. While this means that we replay some old samples,
this is a nicer behaviour than having audio stop and restart.
The changes to achieve this are relatively minor - imx-sdma.c can track
where the DMA is to the nearest descriptor boundary - it does this
already when deciding how many callbacks to issue. In doing this,
buf_tail always points at the descriptor which will complete next.
The residue is defined by the bytes remaining to the end of the buffer,
when the buffer is viewed as a single block of memory [start...end].
So, when we start out, there's a full buffer worth of residue, and this
counts down as we approach the end of the buffer, eventually becoming
zero at the end, before returning to the full buffer worth when we
wrap back to the start.
Moving the walking of the descriptors into the interrupt handler means
that we can update the BD_DONE flag at interrupt time, thus avoiding
a delayed tasklet stopping the cyclic DMA.
This means that the residue can be calculated from (total descriptors -
buf_tail) * descriptor size. This is what the change below does. We
update imx-pcm-dma.c to remove the NO_RESIDUE flag since we now provide
the residue.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Add new variable defining ASQ command write back timeout to allow for
dynamic modification of this timeout. Initialize it on AQ initialize
routine with default value, vary it on device ID.
Change-ID: I5c9908f9d7c5455634353b694a986d6f146d1b9d
Signed-off-by: Kamil Krawczyk <kamil.krawczyk@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
In some circumstances, the firmware could beat us to the punch, and the
reply from the PF would come back before we were able to properly modify
the aq_pending and aq_required flags. This would mess up the flags and
put the driver in an indeterminate state, much like Schrödinger's cat.
However, unlike the cat, the driver is definitely dead.
To fix this, simply set the flags before sending the request to the AQ.
This way, it won't matter if the interrupt comes back too soon.
Change-ID: I9784655e475675ebcb3140cc7f36f4a96aaadce5
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
When a 0-length packet is received on the bus, desc->pd0 yields 1,
which confuses the driver's users. This information is clearly wrong
and not in accordance to the datasheet, but it's been observed on an
AM335x board, very reproducible.
Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore the value in PD0 and report a total length of 0 instead.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Make mask value of all 1s. Value of -1 can't be used for u32 type.
Change-ID: I49d58b77639939fe7447a229dbf1f4a1bf7419ce
Signed-off-by: Kevin Scott <kevin.c.scott@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Per a recent HW designer comment, this code is for ripping through the
queues and interrupts to fully disable them on driver init, specifically
to help clean up after a PXE or other early boot activity.
Change-ID: I32ed452021a1c2b06dace1969976f882a37b9741
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Clear the AQ BAH and BAL registers on a clean shutdown to help make sure
all is tidy when the driver is done.
Change-ID: I393e92680247daa52a8e00bab183213672d73578
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Add the Base Address High and Low to the admin queue struct to simplify
another bit of "which context" logic in the config routines.
Change-ID: Iae195a7da3baffc1a9d522119e1e2b427068ad07
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
We have two different ways to handle changes to sk->sk_dst
First way (used by TCP) assumes socket lock is owned by caller, and use
no extra lock : __sk_dst_set() & __sk_dst_reset()
Another way (used by UDP) uses sk_dst_lock because socket lock is not
always taken. Note that sk_dst_lock is not softirq safe.
These ways are not inter changeable for a given socket type.
ipv4_sk_update_pmtu(), added in linux-3.8, added a race, as it used
the socket lock as synchronization, but users might be UDP sockets.
Instead of converting sk_dst_lock to a softirq safe version, use xchg()
as we did for sk_rx_dst in commit e47eb5dfb2 ("udp: ipv4: do not use
sk_dst_lock from softirq context")
In a follow up patch, we probably can remove sk_dst_lock, as it is
only used in IPv6.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Fixes: 9cb3a50c5f ("ipv4: Invalidate the socket cached route on pmtu events if possible")
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove the driver as it hasn't been cleaned up and it doesn't look like
anyone is going to work on it anymore. This can be reverted if someone
wants to work to fix the remaining issues the driver has.
Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
Cc: Bill Pemberton <wfp5p@worldbroken.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commig "604b592 UBI: fix rb_tree node comparison in add_map"
broke fastmap backward compatibility and older fastmap images
cannot be mounted anymore. The reason is that it changes the
volumes RB-tree sorting criteria. This patch fixes the problem.
Artem: re-write the commit message
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Remove the driver as it hasn't been cleaned up and it doesn't look like
anyone is going to work on it anymore. This can be reverted if someone
wants to work to fix the remaining issues the driver has.
Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the driver as it hasn't been cleaned up and it doesn't look like
anyone is going to work on it anymore.
Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
Cc: Henk de Groot <pe1dnn@amsat.org>
Cc: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch makes the msm ehci driver available to use on QCOM SOCs,
which have the same IP.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs. This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Michael Büsch <m@bues.ch>
Tested-by: Michael Büsch <m@bues.ch>
Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A few more fixes for this RC cycle. There's a revert of a previous patch
which ended up being the wrong version, so we reverted that commit and
applied a better fix.
CPPI41 got a race condition fix which was found by Thomas Gleixner.
The MSM PHY driver got a runtime pm usage fix so that it wouldn't
kill the PHY while it was still being used.
We also have a fix for a panic caused when removing musb_am335x driver.
Other than that, a few other minor fixes.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTsa7CAAoJEIaOsuA1yqREC7kP/RRECPS8UrZgrVlU9Gch5iqw
WtV3TdkTVuB6bhwvtRGIAjiXOdr8INvRkKvlzVN082cROAdSWjElbD9A/830a2Iv
5sMOWbM6HIkrwr51cGXIMul+0wNhcszftCn4+8UUiuKoP7dFnqTGZBgcyoDhfkHQ
BjQ3/RlzeZ3XjLiBtnA4gTVko9i9L77TMayskOyjDpEEBKJ4HBKcD9Ged2xfgDxV
P7lc5lkehUF9l3BAP4xfJq+vV8nxpRwq5J4OkBmJpODUPmim8XlSTNxA3EJQ+3SQ
1NusKOT/pVcSNYzVtB23C9Qvj6pvocso0ktvJOzwMLmW95GNMwN6NzbJUiSXIUzG
cOGXGA6dJYKVFZ/7QNsV99ZAjEYBrgszZqtDHYmitYdo29ABMSuZ/3ZdfAT09a9P
+Fqm4gqTDLJ9y72PHSc1CPJq4whTINGpIKcyRiVaxl+jFXl4v5rs3BywKV2gMIlM
EhXaNz/AG+wGZVOiZzg0zHSjAhCw0GbthysMmd87z7Ynjcu97pDBEIw+xl1aI3wS
eyFFt16WtRxujXFYqfDtArU0pdqrTxLgTBisxf949LKZJiB6Ta7v+MZOfFKVu//O
5K8KCN1l4vMUPOvTghT0BIGsCg4Td9zi0LTEQOBEwavYzXyATdqGAYnYeLgoqO4z
82XvxgC4fqXzXLhAntC5
=7Mt5
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.16-rc4
A few more fixes for this RC cycle. There's a revert of a previous patch
which ended up being the wrong version, so we reverted that commit and
applied a better fix.
CPPI41 got a race condition fix which was found by Thomas Gleixner.
The MSM PHY driver got a runtime pm usage fix so that it wouldn't
kill the PHY while it was still being used.
We also have a fix for a panic caused when removing musb_am335x driver.
Other than that, a few other minor fixes.
Signed-of-by: Felipe Balbi <balbi@ti.com>
Due to the race condition in userspace, there is chance that two
overlapping megaflows could be installed in datapath. And this
causes userspace unable to delete the less inclusive megaflow flow
even after it timeout, since the flow_del logic will stop at the
first match of masked flow.
This commit fixes the bug by making the kernel flow_del and flow_get
logic check all masks in that case.
Introduced by 03f0d916a (openvswitch: Mega flow implementation).
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
tmon fails to build statically with the following error:
$ make LDFLAGS=-static
gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration -Wimplicit-int -fstack-protector -D VERSION=\"1.0\" -static tmon.o tui.o sysfs.o pid.o -o tmon -lm -lpanel -lncursesw -lpthread
tmon.o: In function `tmon_sig_handler':
tmon.c:(.text+0x21): undefined reference to `stdscr'
tmon.o: In function `tmon_cleanup':
tmon.c:(.text+0xb9): undefined reference to `stdscr'
tmon.c:(.text+0x11e): undefined reference to `stdscr'
tmon.c:(.text+0x123): undefined reference to `keypad'
tmon.c:(.text+0x12d): undefined reference to `nocbreak'
tmon.o: In function `main':
tmon.c:(.text+0x785): undefined reference to `stdscr'
tmon.c:(.text+0x78a): undefined reference to `nodelay'
tui.o: In function `setup_windows':
tui.c:(.text+0x131): undefined reference to `stdscr'
tui.c:(.text+0x176): undefined reference to `stdscr'
tui.c:(.text+0x19f): undefined reference to `stdscr'
tui.c:(.text+0x1cc): undefined reference to `stdscr'
tui.c:(.text+0x1ff): undefined reference to `stdscr'
tui.o:tui.c:(.text+0x229): more undefined references to `stdscr' follow
tui.o: In function `show_cooling_device':
[...]
stdscr() and friends are in libtinfo (part of ncurses) so add it to
the libraries that are linked in when compiling tmon to fix it.
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
On latest i.MX6 SOC with thermal calibration data of 0x5A100000,
the critical trip temperature will be an invalid value and
cause system auto shutdown as below log:
thermal thermal_zone0: critical temperature reached(42 C),shutting down
So, with universal formula for thermal sensor, only room
temperature point is calibrated, which means the calibration
data read from fuse only has valid data of bit [31:20], others
are all 0, the critical trip point temperature can NOT depend
on the hot point calibration data, here we set it to 20 C higher
than default passive temperature.
Signed-off-by: Anson Huang <b20788@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This inclusion guard became pointless after commit
40ca061b1b
"ARM: 7841/1: sa1100: remove complex GPIO interface"
which removed the last complex gpiolib interface.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The long pain of maintaining the legacy <mach/gpio.h> include
ladder is now gone with S5P as the last user being deleted. Cut
this Kconfig option and remove the inclusion directive in
<asm/gpio.h> for good.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This renames all the local <mach/gpio.h> headers in the S5P platforms
to <mach/gpio-samsung.h> indicating a scope local to this platform,
and cuts the implicit inclusion of <mach/gpio.h> from <linux/gpio.h>
by removing the use of NEED_MACH_GPIO_H from all S5P variants.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The number of GPIOs defined for the different S5P platforms using
the tricky #define macros are actually as follows:
S5P64x0: 180 GPIOs
S5PC100: 115 GPIOs
S5PV210: 252 GPIOs
The include file <asm-generic/gpio.h> will automatically bump us
to 256 GPIOs which is a nice default value that happens to encompass
all the S5P platform requirements under its roof.
Cut ARCH_NR_GPIOS and the custom spacing macro for extra GPIOs
that is not used anywhere in the kernel.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use clk_prepare_enable/clk_disable_unprepare to make the driver
work properly with common clock framework.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The musb/cppi41 code installs a hrtimer to work around DMA completion
interrupts that have fired too early on AM335x hardware. This timer
is currently programmed to first fire 140 microseconds after the DMA
completion callback. According to the commit which introduced it
(a655f481d8, "usb: musb: musb_cppi41: handle pre-mature TX complete
interrupt"), that value is is considered a 'rule of thumb' that worked
well with the test case described in the commit log.
Test show, however, that for USB audio devices and much smaller packet
sizes, the timer has to fire earlier in order to correctly handle the audio
stream. The original test case had output transfer sizes of 1514 bytes, and
a delay of 140 microseconds. For audio devices with 24 bytes channel size, 3
microseconds seem to work well.
Hence, let's assume that the time it takes to clear the bit correlates with
the number of bytes transferred. The referenced commit log mentions such a
suspicion as well. Let the timer fire in cppi41_channel->total_len/10
microseconds to correctly handle both cases.
Also, shorten the interval in which the timer fires again in case of
a non-empty early_tx list.
With these changes in place, both FS and HS audio devices appear to work
well on AM335x hardware.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Sebastian Reimers <sebastian.reimers@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit 1af54b7a4.
The commit tried to address cases in which isochronous transfers are 'not
reliable', most probably in the tests conducted, polling for the
MUSB_TXCSR_TXPKTRDY bit in MUSB_TXCSR is done too late.
Hence, it installs a work struct which basically busy-polls for the bit in a
rather agressive way by rescheduling the work if the FIFO is not empty. With
USB audio devices, tests have shown that it takes approximately 100
iterations of the asynchronous worker until the FIFO signals completion,
which leads to 100% CPU loads when streaming audio.
The issue the patch tried to address can be handled differently, which is
what the next patch does.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Sebastian Reimers <sebastian.reimers@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Before accessing any of an endpoint's CSR registers, make sure the
correct endpoint is selected. Otherwise, data read from or written to
the registers is likely to affect the wrong endpoint as long as the
connected device has more than one endpoint.
This, of course, leads to all sorts of strange effects such as stream
starvation and driver internal state machine confusion due to spurious
interrupts.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The musb/cppi41 glue layer is capable of handling transactions that span
over more than one USB packet by reloading the DMA descriptors
partially. An urb is considered completed when either its transfer
buffer has been filled entirely (actual_length ==
transfer_buffer_length) or if a packet in the stream has less bytes than
the endpoint's wMaxPacketSize.
Once one of the above conditions is met, musb_dma_completion() is called
from cppi41_trans_done(). However, the final decision whether or not to
return the urb to its owner is made by the core and its determination of
the variable 'done' in musb_host_rx(). This code has currently no way of
knowing what the size of the last packet was, and whether or not to
give back the urb due to a short read.
Fix this by introducing a new boolean flag in 'struct dma_channel', and
set it from musb_cppi41.c. If set, it will make the core do what the
DMA layer decided and complete the urb.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The datasheet says that MUSB_TXCSR_FLUSHFIFO is only valid when
MUSB_TXCSR_TXPKTRDY is set as well.
With this patch applied, the warning in this function does no longer
kick in when an USB soundcard is unplugged while the stream is active.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On AM33xx platforms, unplugging a device in the middle of an active
transfer leads to a drop of MUSB_DEVCTL_HM in MUSB_DEVCTL before the
system is informed about a disconnect. This consequently makes the musb
core call the gadget code to handle the interrupt request, which then
crashes the kernel because the relevant pointers haven't been set up
for gadget mode.
To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
in musb_interrupt() and musb_dma_completion() to detect whether the
controller is in host or peripheral mode. This information is provided
by the driver logic and does not rely on register contents.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just a little cleanup that removes unnecessary casts.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
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
description of the hardware with SKIP and RESERVED where appropriate.
Unfortunately, we need to be able to refer to these hardwired IRQs.
So, to request these, crossbar driver can use the existing information
from it's table that these SKIP/RESERVED maps are direct wired sources
and generic allocation/programming of crossbar should be avoided.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-17-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-16-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-15-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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
validate requests.
[ jac - remove MAX_SOURCES from binding doc, use integer because we
shouldn't put implementation details in the binding docs ]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-14-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-11-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-10-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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
Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct
Warning(drivers/irqchip/irq-crossbar.c:39): No description found for parameter 'write'
2 warnings
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-9-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 'routable_irq_domain_ops' was not declared. Should it be static?
drivers/irqchip/irq-crossbar.c:261:12: warning: symbol 'irqcrossbar_init' was not declared. Should it be static?
Checkpatch warnings:
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-8-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-7-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 = <a size_b>
ti,max-irqs = is a wrong parameter
class 2: irq-reserved list - which decides which entries in the
address space is not actually wired in
class 3: wrong list of routable-irqs.
In general allocating from max to min tends to have benefits in
ensuring the different issues that may be present in dts is easily
caught at definition time, rather than at a later point in time.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-6-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 written to
ensure that the crossbar mapping matches with interrupt controller
usage.
So provide a safe value in the dt data to map if
'0' is not safe for the platform and use it during init and unmap
While at this, fix the below checkpatch warning.
Fixes checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#37: FILE: drivers/irqchip/irq-crossbar.c:37:
+ void (*write) (int, int);
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-5-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
