ARM: dts: DRA7: enabling optional clks in DT
This flag had to be moved to the device tree because by
having it set in the compile time will cause issues for
other cores which are using the corresponding hardware
module.
Change-Id: I30f2256759520cc6b303ba71492e6580b954bdd1
Signed-off-by: Rakesh Movva <r-movva@ti.com>
This flag had to be moved to the device tree because by
having it set in the compile time will cause issues for
other cores which are using the corresponding hardware
module.
Change-Id: I30f2256759520cc6b303ba71492e6580b954bdd1
Signed-off-by: Rakesh Movva <r-movva@ti.com>
ARM: dts: omap: Add enable optional clks during reset
binding for OMAP
Need to move this flag to dts entry because by having
this flag during the compile time will cause problem
for modules which are being accessed by other cores
on the SoC.
Change-Id: I2af24af91592adc676cb0f337a9c53107210da10
Signed-off-by: Rakesh Movva <r-movva@ti.com>
binding for OMAP
Need to move this flag to dts entry because by having
this flag during the compile time will cause problem
for modules which are being accessed by other cores
on the SoC.
Change-Id: I2af24af91592adc676cb0f337a9c53107210da10
Signed-off-by: Rakesh Movva <r-movva@ti.com>
arm: dra7: hwmod: remove opt clks enable flag from hwmod
This flag is now enabled from the DT, having it
initalized here is causing problem for other
cores(comes up much earlier) during bootup which
are using the corresponding hw module.
Change-Id: Ia782e47a295a5ff46eeda59f38a4d4fbfd0e327a
Signed-off-by: Rakesh Movva <r-movva@ti.com>
This flag is now enabled from the DT, having it
initalized here is causing problem for other
cores(comes up much earlier) during bootup which
are using the corresponding hw module.
Change-Id: Ia782e47a295a5ff46eeda59f38a4d4fbfd0e327a
Signed-off-by: Rakesh Movva <r-movva@ti.com>
OMAPDSS: Adapt DSS driver for skipping initialization during bootup
Leverage the detection methods for display skip during init
and conditionally configure dss, dispc and overlay managers.
Since DSS clock configuration is required for overlay scaling
function to work correctly disabling only the pm runtime enable
logic should be enough.
Change-Id: I4898db98d04a68d0159de137823b95b7c96241de
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
Leverage the detection methods for display skip during init
and conditionally configure dss, dispc and overlay managers.
Since DSS clock configuration is required for overlay scaling
function to work correctly disabling only the pm runtime enable
logic should be enough.
Change-Id: I4898db98d04a68d0159de137823b95b7c96241de
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
OMAPDSS: tlc59108: adapt panel driver for display sharing use case
Make changes to not configure the display panel when the remote
core is using it.
Change-Id: Ib8428595949176647530958e4c338f8257100644
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
Make changes to not configure the display panel when the remote
core is using it.
Change-Id: Ib8428595949176647530958e4c338f8257100644
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
OMAPDSS: Adapt DSS driver for display sharing use-case
This patch makes sure that the interrupts used by the
remote core are not reset inadvertently by the kernel.
Change-Id: I645e26f21c25755b447157d29390447a729d6031
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
This patch makes sure that the interrupts used by the
remote core are not reset inadvertently by the kernel.
Change-Id: I645e26f21c25755b447157d29390447a729d6031
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
OMAPDSS: Add methods for skipping display initialization
Adds methods to handle skipping display initialization during
kernel bootup for cases where the display is pre-initialized by
either the remote core or u-boot.
Change-Id: Ied3498d35924c46e488620f6753caf15256159ce
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
Adds methods to handle skipping display initialization during
kernel bootup for cases where the display is pre-initialized by
either the remote core or u-boot.
Change-Id: Ied3498d35924c46e488620f6753caf15256159ce
Signed-off-by: Sundar Raman <sunds@ti.com>
Signed-off-by: Rakesh Movva <r-movva@ti.com>
OMAPDSS: provide a way to set number of overlays
enabling the path to change the number of overlays being used
by the dss.
Change-Id: I91f04701cd8d584780e3eb35ebc01586c42ef223
Signed-off-by: Rakesh Movva <r-movva@ti.com>
enabling the path to change the number of overlays being used
by the dss.
Change-Id: I91f04701cd8d584780e3eb35ebc01586c42ef223
Signed-off-by: Rakesh Movva <r-movva@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
dmaengine: omap-dma: Support for polled memcpy transfers
hack: increase tty buffer size and complain if tty buffer full
dma: omap-dma: don't return an error if pause failed due to completion
dma: omap-dma: don't return an error if pause a non-existent transfers
serial: 8250: omap: restore registers on shutdown
serial: 8250: move rx_running out of the bitfield
dma: omap-dma: add support for pause of non-cyclic transfers
dma: add __must_check annotation for dmaengine_pause()
tty: serial: 8250_omap: do not use RX DMA if pause is not supported
Change-Id: Iecf0f9f2f72b340fad72cd2f9552995caad7371b
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
* p-ti-linux-3.14.y-common:
dmaengine: omap-dma: Support for polled memcpy transfers
hack: increase tty buffer size and complain if tty buffer full
dma: omap-dma: don't return an error if pause failed due to completion
dma: omap-dma: don't return an error if pause a non-existent transfers
serial: 8250: omap: restore registers on shutdown
serial: 8250: move rx_running out of the bitfield
dma: omap-dma: add support for pause of non-cyclic transfers
dma: add __must_check annotation for dmaengine_pause()
tty: serial: 8250_omap: do not use RX DMA if pause is not supported
Change-Id: Iecf0f9f2f72b340fad72cd2f9552995caad7371b
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
dmaengine: omap-dma: Support for polled memcpy transfers
When copying small chunks of data the client driver can decide to not use
callbacks and completion (or other means of handling the end of transfer),
but to simply poll the status of the transfer.
This is indicated by the missing DMA_PREP_INTERRUPT flag - so that the
client has no interest in the interrupt.
In such a case the driver will start the transfer without delay and in the
omap_dma_tx_status() callback we will check if the channel is still enabled
or not, if not enabled, DMA_COMPLETED status is returned.
Change-Id: I676b9e978d31541b25366eae3aa524b3743cb082
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
When copying small chunks of data the client driver can decide to not use
callbacks and completion (or other means of handling the end of transfer),
but to simply poll the status of the transfer.
This is indicated by the missing DMA_PREP_INTERRUPT flag - so that the
client has no interest in the interrupt.
In such a case the driver will start the transfer without delay and in the
omap_dma_tx_status() callback we will check if the channel is still enabled
or not, if not enabled, DMA_COMPLETED status is returned.
Change-Id: I676b9e978d31541b25366eae3aa524b3743cb082
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
hack: increase tty buffer size and complain if tty buffer full
Change-Id: I7b963898b0acb8a3ee255184f692e76499efea7a
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Change-Id: I7b963898b0acb8a3ee255184f692e76499efea7a
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
dma: omap-dma: don't return an error if pause failed due to completion
During testing it seemed that sometimes that enable bit is gone but the
completion handler did not run yet cause the UART driver to pause the
transfer.
Change-Id: I6970db7a9aee388cdf49f0be6081de416c250769
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
During testing it seemed that sometimes that enable bit is gone but the
completion handler did not run yet cause the UART driver to pause the
transfer.
Change-Id: I6970db7a9aee388cdf49f0be6081de416c250769
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
dma: omap-dma: don't return an error if pause a non-existent transfers
Currently we get an error from the pause function if we try to pause a
channel with a non-existing descriptor. This happens if we schedule a
transfer and pause it before the tasklet as scheduled and able to
*really* start this transfer. So we try to pause a transfer which has not
yet been scheduled.
For the time now we try to ignore this since if it has not been
scheduled yet, it shouldn't be before we try to cancel it completely.
Change-Id: I0b623cb54a7441fb14698136f90d89a534ba0678
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Currently we get an error from the pause function if we try to pause a
channel with a non-existing descriptor. This happens if we schedule a
transfer and pause it before the tasklet as scheduled and able to
*really* start this transfer. So we try to pause a transfer which has not
yet been scheduled.
For the time now we try to ignore this since if it has not been
scheduled yet, it shouldn't be before we try to cancel it completely.
Change-Id: I0b623cb54a7441fb14698136f90d89a534ba0678
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
serial: 8250: omap: restore registers on shutdown
If DMA is active during a shutdown, a delayed restore of the
registers may be pending. The restore must be performed after
the DMA is stopped, otherwise the delayed restore remains
pending and will fire upon the first DMA TX complete of a
totally different serial session.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/tty/serial/8250/8250_omap.c
Change-Id: Ib3ca6ddd4444dea091d30235714a6c53cb565aa8
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
If DMA is active during a shutdown, a delayed restore of the
registers may be pending. The restore must be performed after
the DMA is stopped, otherwise the delayed restore remains
pending and will fire upon the first DMA TX complete of a
totally different serial session.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/tty/serial/8250/8250_omap.c
Change-Id: Ib3ca6ddd4444dea091d30235714a6c53cb565aa8
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
serial: 8250: move rx_running out of the bitfield
That bitfield is modified by read + or + write operation. If someone
sets any of the other two bits it might render the lock useless.
While at it, remove other bitfields as well to avoid more such
errors.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/tty/serial/8250/8250.h
Change-Id: Icf01563ab0b9a30e87ed8fba31eac410178dc3ca
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
That bitfield is modified by read + or + write operation. If someone
sets any of the other two bits it might render the lock useless.
While at it, remove other bitfields as well to avoid more such
errors.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/tty/serial/8250/8250.h
Change-Id: Icf01563ab0b9a30e87ed8fba31eac410178dc3ca
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
dma: omap-dma: add support for pause of non-cyclic transfers
This DMA driver is used by 8250-omap on DRA7-evm. There is one
requirement that is to pause a transfer. This is currently used on the RX
side. It is possible that the UART HW aborted the RX (UART's RX-timeout)
but the DMA controller starts the transfer shortly after.
Before we can manually purge the FIFO we need to pause the transfer,
check how many bytes it already received and terminate the transfer
without it making any progress.
From testing on the TX side it seems that it is possible that we invoke
pause once the transfer has completed which is indicated by the missing
CCR_ENABLE bit but before the interrupt has been noticed. In that case the
interrupt will come even after disabling it.
The AM572x manual says that we have to wait for the CCR_RD_ACTIVE &
CCR_WR_ACTIVE bits to be gone before programming it again here is the
drain loop. Also it looks like without the drain the TX-transfer makes
sometimes progress.
One note: The pause + resume combo is broken because after resume the
the complete transfer will be programmed again. That means the already
transferred bytes (until the pause event) will be sent again. This is
currently not important for my UART user because it does only pause +
terminate.
v2…v3:
- rephrase the comment based on Russell's information / feedback.
v1…v2:
- move the drain loop into omap_dma_drain_chan() instead of having it
twice.
- allow pause only for DMA_DEV_TO_MEM transfers if non-cyclic. Add a
comment why DMA_MEM_TO_DEV not allowed.
- clear pause on terminate_all. Otherwise pause() + terminate_all()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/dma/omap-dma.c
Change-Id: I990b19e261ac3faf222f39cdcd410e97c8ad505a
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
This DMA driver is used by 8250-omap on DRA7-evm. There is one
requirement that is to pause a transfer. This is currently used on the RX
side. It is possible that the UART HW aborted the RX (UART's RX-timeout)
but the DMA controller starts the transfer shortly after.
Before we can manually purge the FIFO we need to pause the transfer,
check how many bytes it already received and terminate the transfer
without it making any progress.
From testing on the TX side it seems that it is possible that we invoke
pause once the transfer has completed which is indicated by the missing
CCR_ENABLE bit but before the interrupt has been noticed. In that case the
interrupt will come even after disabling it.
The AM572x manual says that we have to wait for the CCR_RD_ACTIVE &
CCR_WR_ACTIVE bits to be gone before programming it again here is the
drain loop. Also it looks like without the drain the TX-transfer makes
sometimes progress.
One note: The pause + resume combo is broken because after resume the
the complete transfer will be programmed again. That means the already
transferred bytes (until the pause event) will be sent again. This is
currently not important for my UART user because it does only pause +
terminate.
v2…v3:
- rephrase the comment based on Russell's information / feedback.
v1…v2:
- move the drain loop into omap_dma_drain_chan() instead of having it
twice.
- allow pause only for DMA_DEV_TO_MEM transfers if non-cyclic. Add a
comment why DMA_MEM_TO_DEV not allowed.
- clear pause on terminate_all. Otherwise pause() + terminate_all()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/dma/omap-dma.c
Change-Id: I990b19e261ac3faf222f39cdcd410e97c8ad505a
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
dma: add __must_check annotation for dmaengine_pause()
In 8250-omap I learned it the hard way that ignoring the return code
of dmaengine_pause() might be bad because the underlying DMA driver
might not support the function at all and so not doing what one is
expecting.
This patch adds the __must_check annotation as suggested by Russell King.
Change-Id: Iba78c8416f0ee6708663e87b012fc7c419dc820a
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
In 8250-omap I learned it the hard way that ignoring the return code
of dmaengine_pause() might be bad because the underlying DMA driver
might not support the function at all and so not doing what one is
expecting.
This patch adds the __must_check annotation as suggested by Russell King.
Change-Id: Iba78c8416f0ee6708663e87b012fc7c419dc820a
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
tty: serial: 8250_omap: do not use RX DMA if pause is not supported
The 8250-omap driver requires the DMA-engine driver to support the pause
command in order to properly turn off programmed RX transfer before the
driver stars manually reading from the FIFO.
The lacking support of the requirement has been discovered recently. In
order to stay safe here we disable support for RX-DMA as soon as we
notice that it does not work. This should happen very early.
If the user does not want to see this backtrace he can either disable
DMA support (completely or RX-only) or backport the required patches for
edma / omap-dma once they hit mainline.
Change-Id: If04b9c5c4a6fd6c0ae16c2a67be4d70d5a1f2af0
Cc: <stable@vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
The 8250-omap driver requires the DMA-engine driver to support the pause
command in order to properly turn off programmed RX transfer before the
driver stars manually reading from the FIFO.
The lacking support of the requirement has been discovered recently. In
order to stay safe here we disable support for RX-DMA as soon as we
notice that it does not work. This should happen very early.
If the user does not want to see this backtrace he can either disable
DMA support (completely or RX-only) or backport the required patches for
edma / omap-dma once they hit mainline.
Change-Id: If04b9c5c4a6fd6c0ae16c2a67be4d70d5a1f2af0
Cc: <stable@vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Rajkumar Raghupathy <x0241314@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Revert "ti: config: android: disable kdevtmpfs"
This reverts commit 9ecb64e136c1d147f3a467fb64c9589d17e95267.
This commit 9ecb64e ("ti: config: android: disable kdevtmpfs") was
added for removing need to write SELinux rule for devtempfs, this
SELinux rule was not needed as Android does not use kdevtmpfs.
But looks like this is used for kernel component testing framework.
So adding it back, noaudit rule will be written for kdevtmpfs related
denials.
Change-Id: I37877e365ede43ea03cf14875a70251c73a59e4f
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
This reverts commit 9ecb64e136c1d147f3a467fb64c9589d17e95267.
This commit 9ecb64e ("ti: config: android: disable kdevtmpfs") was
added for removing need to write SELinux rule for devtempfs, this
SELinux rule was not needed as Android does not use kdevtmpfs.
But looks like this is used for kernel component testing framework.
So adding it back, noaudit rule will be written for kdevtmpfs related
denials.
Change-Id: I37877e365ede43ea03cf14875a70251c73a59e4f
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
ARM: dts: dra7-evm: add pinmux configuration for MMC4
arm: dts: pad DTB size by 4 KB.
Change-Id: If2eb6bb2bc27e7d6cd566fd4ea9060f3fa36f02e
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
* p-ti-linux-3.14.y-common:
ARM: dts: dra7-evm: add pinmux configuration for MMC4
arm: dts: pad DTB size by 4 KB.
Change-Id: If2eb6bb2bc27e7d6cd566fd4ea9060f3fa36f02e
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
ARM: dts: dra7-evm: add pinmux configuration for MMC4
Add pinmux configuration and IODELAY values for MMC4.
Change-Id: I49ebb962827ff7e9eea85b53cb4a0655f9dcdd27
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Add pinmux configuration and IODELAY values for MMC4.
Change-Id: I49ebb962827ff7e9eea85b53cb4a0655f9dcdd27
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Merge "arm: dts: pad DTB size by 4 KB." into p-ti-linux-3.14.y-common
Merge branch 'p-android-3.14' into p-ti-linux-3.14.y-android
* p-android-3.14:
ion: Handle the memory mapping correctly on x86
arm64 Kconfig: Move LIST_POISON to a safe value
sysrq: Emergency Remount R/O in reverse order
pstore: pmsg: return -ENOMEM on vmalloc failure
wakeup_reason: use vsnprintf instead of snsprintf for vargs.
usb: gadget: fix NULL ptr derefer while symlinking PTP func
uid_cputime: Iterates over all the threads instead of processes.
Conflicts:
drivers/staging/android/ion/ion_priv.h
Change-Id: Ie90843abc87ecca3e9e8575c87f612a878aafabe
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-android-3.14:
ion: Handle the memory mapping correctly on x86
arm64 Kconfig: Move LIST_POISON to a safe value
sysrq: Emergency Remount R/O in reverse order
pstore: pmsg: return -ENOMEM on vmalloc failure
wakeup_reason: use vsnprintf instead of snsprintf for vargs.
usb: gadget: fix NULL ptr derefer while symlinking PTP func
uid_cputime: Iterates over all the threads instead of processes.
Conflicts:
drivers/staging/android/ion/ion_priv.h
Change-Id: Ie90843abc87ecca3e9e8575c87f612a878aafabe
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'android-3.14' of https://android.googlesource.com/kernel/common into p-android-3.14
* 'android-3.14' of https://android.googlesource.com/kernel/common:
ion: Handle the memory mapping correctly on x86
arm64 Kconfig: Move LIST_POISON to a safe value
sysrq: Emergency Remount R/O in reverse order
pstore: pmsg: return -ENOMEM on vmalloc failure
wakeup_reason: use vsnprintf instead of snsprintf for vargs.
usb: gadget: fix NULL ptr derefer while symlinking PTP func
uid_cputime: Iterates over all the threads instead of processes.
Change-Id: I0eeef80b649640efea2f0dccfb88d403e759a2ba
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'android-3.14' of https://android.googlesource.com/kernel/common:
ion: Handle the memory mapping correctly on x86
arm64 Kconfig: Move LIST_POISON to a safe value
sysrq: Emergency Remount R/O in reverse order
pstore: pmsg: return -ENOMEM on vmalloc failure
wakeup_reason: use vsnprintf instead of snsprintf for vargs.
usb: gadget: fix NULL ptr derefer while symlinking PTP func
uid_cputime: Iterates over all the threads instead of processes.
Change-Id: I0eeef80b649640efea2f0dccfb88d403e759a2ba
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Change-Id: I5251a718ba2e4d63cf0bc26176b178f0b3db7ce4
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Change-Id: I5251a718ba2e4d63cf0bc26176b178f0b3db7ce4
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Change-Id: I6f2c6754e9d801dd494afac8b5bda9d2db03dfad
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Change-Id: I6f2c6754e9d801dd494afac8b5bda9d2db03dfad
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
arm: dts: pad DTB size by 4 KB.
The padding helps when manipulating the device tree in SPL in place
during single stage boot.
Some of the nodes that may need modifications are
1. chosen - for boot arguments, initramfs start and end locations
2. eth0 and eth1 - to update the mac address read from efuse
3. remoteproc nodes and corresponding timer, watchdog and mmu nodes -
for adding late attach properties.
Without padding, the device tree may need to be resized by SPL. As SPL
does not have dcache support enabled, the resize operation might be
costlier than loading an additional 4 KB from flash.
Manipulating the above nodes needs about 1.5 KB of additional space. I
am choosing a 4 KB padding to avoid similar changes in the future.
Change-Id: Ice5eab91bf62320b9634ab851416fac0bd6a4425
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
The padding helps when manipulating the device tree in SPL in place
during single stage boot.
Some of the nodes that may need modifications are
1. chosen - for boot arguments, initramfs start and end locations
2. eth0 and eth1 - to update the mac address read from efuse
3. remoteproc nodes and corresponding timer, watchdog and mmu nodes -
for adding late attach properties.
Without padding, the device tree may need to be resized by SPL. As SPL
does not have dcache support enabled, the resize operation might be
costlier than loading an additional 4 KB from flash.
Manipulating the above nodes needs about 1.5 KB of additional space. I
am choosing a 4 KB padding to avoid similar changes in the future.
Change-Id: Ice5eab91bf62320b9634ab851416fac0bd6a4425
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
arm: dtsi: jamr3: Use falling edge for embedded sync
v4l: of: Correct pclk-sample for BT656 bus
ARM: dts: dra7: Single OPP entry for GPU.
Change-Id: Ie174fcfdce45f790e7faa7f216ffe0bc33bb856b
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common:
arm: dtsi: jamr3: Use falling edge for embedded sync
v4l: of: Correct pclk-sample for BT656 bus
ARM: dts: dra7: Single OPP entry for GPU.
Change-Id: Ie174fcfdce45f790e7faa7f216ffe0bc33bb856b
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
arm: dtsi: jamr3: Use falling edge for embedded sync
With the V4L2 parser fix for allowing pixel clock polarity
setting for the embedded sync, the endpoint property can be
added to describe the correct polarity of the pixel clock.
Change-Id: Ia46de13a48b9bab95db24f96f248251b13acbea1
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
With the V4L2 parser fix for allowing pixel clock polarity
setting for the embedded sync, the endpoint property can be
added to describe the correct polarity of the pixel clock.
Change-Id: Ia46de13a48b9bab95db24f96f248251b13acbea1
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
v4l: of: Correct pclk-sample for BT656 bus
commit 7a60743f347c9d03811c5a2b9aa92431be19e512 upstream
Current v4l2_of_parse_parallel_bus function attempts to parse the
DT properties for the parallel bus as well as BT656 bus.
If the pclk-sample property is defined for the BT656 bus, it is still
marked as a parallel bus.
Fix this by parsing the pclk after the bus_type is selected.
Only when hsync or vsync properties are specified, the bus_type should
be set to V4L2_MBUS_PARALLEL.
Change-Id: If61007ac5c639c8866f3c5510fdf7a9b528f0ec5
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
commit 7a60743f347c9d03811c5a2b9aa92431be19e512 upstream
Current v4l2_of_parse_parallel_bus function attempts to parse the
DT properties for the parallel bus as well as BT656 bus.
If the pclk-sample property is defined for the BT656 bus, it is still
marked as a parallel bus.
Fix this by parsing the pclk after the bus_type is selected.
Only when hsync or vsync properties are specified, the bus_type should
be set to V4L2_MBUS_PARALLEL.
Change-Id: If61007ac5c639c8866f3c5510fdf7a9b528f0ec5
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
ion: Handle the memory mapping correctly on x86
This patch modifies the ion page pool code to address
limitation in x86 PAT. When one physical page is mapped
to multiple virtual pages, the same cache policy
should be used. Add set_memory_wc/uc call to avoid aliases.
If not, all mappings will be cached(write back).
Change-Id: I98ee8902df0c80135dddfa998c4ca4c2bb44e40e
Signed-off-by: Zhebin Jin <zhebin.jin@intel.com>
Signed-off-by: Vinil Cheeramvelil <vinil.cheeramvelil@intel.com>
This patch modifies the ion page pool code to address
limitation in x86 PAT. When one physical page is mapped
to multiple virtual pages, the same cache policy
should be used. Add set_memory_wc/uc call to avoid aliases.
If not, all mappings will be cached(write back).
Change-Id: I98ee8902df0c80135dddfa998c4ca4c2bb44e40e
Signed-off-by: Zhebin Jin <zhebin.jin@intel.com>
Signed-off-by: Vinil Cheeramvelil <vinil.cheeramvelil@intel.com>
ARM: dts: dra7: Single OPP entry for GPU.
SGX DVFS module is not validated for lower OPP setting. Setting
OPP_HIGH for graphics module.
Change-Id: I3e00f596592c3d01c567bdf8857fb524c37f9eba
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
SGX DVFS module is not validated for lower OPP setting. Setting
OPP_HIGH for graphics module.
Change-Id: I3e00f596592c3d01c567bdf8857fb524c37f9eba
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Merge 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
arm: dts: dra72: Use gpio hog only for baseboard ethernet
ARM: dts: DRA7: fix a typo in ethernet
net/rpmsg: sanity check the input buffer length in sendmsg
Change-Id: Icfbd5952f57bb46b3ac8fb880ffa2d2b0fe7e0ce
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
arm: dts: dra72: Use gpio hog only for baseboard ethernet
ARM: dts: DRA7: fix a typo in ethernet
net/rpmsg: sanity check the input buffer length in sendmsg
Change-Id: Icfbd5952f57bb46b3ac8fb880ffa2d2b0fe7e0ce
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into p-ti-linux-3.14.y-common
* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
net/rpmsg: sanity check the input buffer length in sendmsg
Change-Id: Ifca851f35a253ac97cc5ce4cd9ca5e50a3b22036
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
net/rpmsg: sanity check the input buffer length in sendmsg
Change-Id: Ifca851f35a253ac97cc5ce4cd9ca5e50a3b22036
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes the
fixes for PM suspend/resume support on the DSP remote processors
on DRA7xx family of SoCs.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes the
fixes for PM suspend/resume support on the DSP remote processors
on DRA7xx family of SoCs.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix various DRA7 DSP PM suspend/
resume issues.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix various DRA7 DSP PM suspend/
resume issues.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP
Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.
Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.
This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP
Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.
Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.
This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.
The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit 9d964601689c ("ARM: OMAP2+: use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.
Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.
The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit 9d964601689c ("ARM: OMAP2+: use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.
Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
arm: dts: dra72: Use gpio hog only for baseboard ethernet
On J6eco EVM, the ethernet is muxed with the vin2a interface.
For using vin2a, ethernet slave0 is rerouted to use the PHY1.
This is done by hogging a GPIO to output-low.
For vision use cases, we need to set the GPIO from driver.
Therefore, hogging is not correct solution. Also, gpio-hog does not
respect the status="disabled" property.
So keep the gpio hog node in baseboard dts but delete from the vision dts.
This will enable ethernet on baseboard and would allow setting thr GPIO
for vision use cases.
Fixes: 1eedfa4af ("arm: dts: dra72-evm: New device tree for dra72-evm")
Change-Id: I94d6aba3f5582da5664d4a91734b638dd90c572e
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
On J6eco EVM, the ethernet is muxed with the vin2a interface.
For using vin2a, ethernet slave0 is rerouted to use the PHY1.
This is done by hogging a GPIO to output-low.
For vision use cases, we need to set the GPIO from driver.
Therefore, hogging is not correct solution. Also, gpio-hog does not
respect the status="disabled" property.
So keep the gpio hog node in baseboard dts but delete from the vision dts.
This will enable ethernet on baseboard and would allow setting thr GPIO
for vision use cases.
Fixes: 1eedfa4af ("arm: dts: dra72-evm: New device tree for dra72-evm")
Change-Id: I94d6aba3f5582da5664d4a91734b638dd90c572e
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm64 Kconfig: Move LIST_POISON to a safe value
Move the poison pointer offset to 0xdead000000000000, a
recognized value that is not mappable by user-space exploits.
Change-Id: I14da595fd063af5926b2e91b410b922074056c90
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Move the poison pointer offset to 0xdead000000000000, a
recognized value that is not mappable by user-space exploits.
Change-Id: I14da595fd063af5926b2e91b410b922074056c90
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
ARM: dts: DRA7: fix a typo in ethernet
Register address in name of the node is wrong
Change-Id: Ibb9be2fafaeb0aca2920c5ef9d3ff469cab2c82d
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Register address in name of the node is wrong
Change-Id: Ibb9be2fafaeb0aca2920c5ef9d3ff469cab2c82d
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
ASoC: davinci-mcasp: dai format runtime reconfiguration
ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt
Change-Id: Ie270f08250390ddf33af4fc46d1b9ea726a8669c
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common:
ASoC: davinci-mcasp: dai format runtime reconfiguration
ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt
Change-Id: Ie270f08250390ddf33af4fc46d1b9ea726a8669c
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common
* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
ASoC: davinci-mcasp: dai format runtime reconfiguration
Change-Id: I2c9efe9f442e8ac18f5e3063ebde4ae31362b265
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
ASoC: davinci-mcasp: dai format runtime reconfiguration
Change-Id: I2c9efe9f442e8ac18f5e3063ebde4ae31362b265
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
sysrq: Emergency Remount R/O in reverse order
This change fixes a problem where reboot on Android panics the kernel
almost every time when file systems are mounted over loop devices.
Android reboot command does:
- sync
- echo u > /proc/sysrq-trigger
- syscall_reboot
The problem is with sysrq emergency remount R/O trying to remount-ro
in wrong order.
since /data is re-mounted ro before loop devices, loop device
remount-ro fails to flush the journal and panics the kernel:
EXT4-fs (loop0): Remounting filesystem read-only
EXT4-fs (loop0): previous I/O error to superblock detected
loop: Write error at byte offset 0, length 4096.
Buffer I/O error on device loop0, logical block 0
lost page write due to I/O error on loop0
Kernel panic - not syncing: EXT4-fs panic from previous error
The fix is quite simple. In do_emergency_remount(), use
list_for_each_entry_reverse() on sb list instead of list_for_each_entry().
It makes a lot of sense to umount the file systems in reverse order in
which they were added to sb list.
Change-Id: I4370e39b5873bd16ade5d5f9ddb2704beb02a2bb
Signed-off-by: Amir Goldstein <amir@cellrox.com>
Acked-by: Oren Laadan <orenl@cellrox.com>
This change fixes a problem where reboot on Android panics the kernel
almost every time when file systems are mounted over loop devices.
Android reboot command does:
- sync
- echo u > /proc/sysrq-trigger
- syscall_reboot
The problem is with sysrq emergency remount R/O trying to remount-ro
in wrong order.
since /data is re-mounted ro before loop devices, loop device
remount-ro fails to flush the journal and panics the kernel:
EXT4-fs (loop0): Remounting filesystem read-only
EXT4-fs (loop0): previous I/O error to superblock detected
loop: Write error at byte offset 0, length 4096.
Buffer I/O error on device loop0, logical block 0
lost page write due to I/O error on loop0
Kernel panic - not syncing: EXT4-fs panic from previous error
The fix is quite simple. In do_emergency_remount(), use
list_for_each_entry_reverse() on sb list instead of list_for_each_entry().
It makes a lot of sense to umount the file systems in reverse order in
which they were added to sb list.
Change-Id: I4370e39b5873bd16ade5d5f9ddb2704beb02a2bb
Signed-off-by: Amir Goldstein <amir@cellrox.com>
Acked-by: Oren Laadan <orenl@cellrox.com>
pstore: pmsg: return -ENOMEM on vmalloc failure
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 23385441
Change-Id: I0b965c3f26f2a81c579071bff81523fd9139fd92
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 23385441
Change-Id: I0b965c3f26f2a81c579071bff81523fd9139fd92
ASoC: davinci-mcasp: dai format runtime reconfiguration
In case when the dai format is set via the dai_link the format
configuration happens once when the links are probed. If the McASP lose
context after this, the information will be lost and McASP will not going
to work correctly.
To overcome this issue, we save the fmt and set it within hw_params as
well.
Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
In case when the dai format is set via the dai_link the format
configuration happens once when the links are probed. If the McASP lose
context after this, the information will be lost and McASP will not going
to work correctly.
To overcome this issue, we save the fmt and set it within hw_params as
well.
Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt
ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.
Fix it by making ldo1_reg as always_on.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[cherrypick to p-ti-linux-3.14.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Change-Id: I58acd0da5a744cf2554eeff05b5acfa0dfd97dfd
ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.
Fix it by making ldo1_reg as always_on.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[cherrypick to p-ti-linux-3.14.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Change-Id: I58acd0da5a744cf2554eeff05b5acfa0dfd97dfd
Merge tag 'v3.14.51' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-3.14.y
This is the 3.14.51 stable release
* tag 'v3.14.51' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
This is the 3.14.51 stable release
* tag 'v3.14.51' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (75 commits)
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
md/bitmap: return an error when bitmap superblock is corrupt.
path_openat(): fix double fput()
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
dcache: don't need rcu in shrink_dentry_list()
more graceful recovery in umount_collect()
don't remove from shrink list in select_collect()
dentry_kill(): don't try to remove from shrink list
expand the call of dentry_lru_del() in dentry_kill()
new helper: dentry_free()
fold try_prune_one_dentry()
fold d_kill() and d_free()
signal: fix information leak in copy_siginfo_from_user32
signal: fix information leak in copy_siginfo_to_user
signalfd: fix information leak in signalfd_copyinfo
sg_start_req(): make sure that there's not too many elements in iovec
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
...
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common: (37 commits)
media: ti-vpe: vip: Create VIP streams based on DTS channel info
media: ti-vpe: vpdma: Use bidirectional cached buffers
media: ti-vpe: vip: Fix crash when streaming without buffers
i2c: ov1063x: Cleanup and optimize sensor configuration
arm: dts: dra7: jamr3: Add channel info for tvp5158
media: ti-vpe: vip: cleanup parser configuration code
v4l: of: Parse endpoint channel information for BT656 bus
media: ti-vpe: vip: Add support for port B capture
arm: dts: dra72-evm: New device tree for dra72-evm with vision card
arm: dtsi: dra72: Add VIP mux pinctrl node and bindings
arm: dts: dra7: vision: Remove gpio from generic vision DTB
arm: dtsi: dra7: Add port B endpoints in VIP nodes
drivers: of: export of_remove_property()
dra7: dt: Update coproc opp voltages for dsp and iva
dra7: dt: update vdd voltages as per DM
DRA7x: dt: Remove duplicate OPPs for DSP coproc
drivers: coproc: clean up driver code
PM / OPP / clk: Remove unnecessary OOM message
PM / OPP: Assert RCU lock in exported functions
PM / OPP: Update kernel documentation
...
Change-Id: Iea886497a086b6de6e709d6721435d6b529d82bf
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common: (37 commits)
media: ti-vpe: vip: Create VIP streams based on DTS channel info
media: ti-vpe: vpdma: Use bidirectional cached buffers
media: ti-vpe: vip: Fix crash when streaming without buffers
i2c: ov1063x: Cleanup and optimize sensor configuration
arm: dts: dra7: jamr3: Add channel info for tvp5158
media: ti-vpe: vip: cleanup parser configuration code
v4l: of: Parse endpoint channel information for BT656 bus
media: ti-vpe: vip: Add support for port B capture
arm: dts: dra72-evm: New device tree for dra72-evm with vision card
arm: dtsi: dra72: Add VIP mux pinctrl node and bindings
arm: dts: dra7: vision: Remove gpio from generic vision DTB
arm: dtsi: dra7: Add port B endpoints in VIP nodes
drivers: of: export of_remove_property()
dra7: dt: Update coproc opp voltages for dsp and iva
dra7: dt: update vdd voltages as per DM
DRA7x: dt: Remove duplicate OPPs for DSP coproc
drivers: coproc: clean up driver code
PM / OPP / clk: Remove unnecessary OOM message
PM / OPP: Assert RCU lock in exported functions
PM / OPP: Update kernel documentation
...
Change-Id: Iea886497a086b6de6e709d6721435d6b529d82bf
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
media: ti-vpe: vip: Create VIP streams based on DTS channel info
With support for multi channel capture and multiple subdevices, sometimes,
driver has to choose between available subdevices. e.g. muxed cameras.
This means, the driver cannot preallocate the capture streams before knowing
the subdevice. This won't work great with multichannel capture subdevices.
Create the capture streams after a subdevice of higher priority is matched.
Of couse, cleanup all the streams associated with the old subdev.
Negotiate with the subdevice to find out the supported formats.
Set the port specific endpoint and subdev info accordingly.
With this, sometimes the video devices would get created, deleted and
re-created again. This may be a problem with video_device. Therefore,
as recommended, allocate the video_device instead of using embedded one.
Change-Id: Ia8f27a2f3ac3880dda9f6801081399cd52630d74
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
With support for multi channel capture and multiple subdevices, sometimes,
driver has to choose between available subdevices. e.g. muxed cameras.
This means, the driver cannot preallocate the capture streams before knowing
the subdevice. This won't work great with multichannel capture subdevices.
Create the capture streams after a subdevice of higher priority is matched.
Of couse, cleanup all the streams associated with the old subdev.
Negotiate with the subdevice to find out the supported formats.
Set the port specific endpoint and subdev info accordingly.
With this, sometimes the video devices would get created, deleted and
re-created again. This may be a problem with video_device. Therefore,
as recommended, allocate the video_device instead of using embedded one.
Change-Id: Ia8f27a2f3ac3880dda9f6801081399cd52630d74
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
media: ti-vpe: vpdma: Use bidirectional cached buffers
VPDMA buffer will be used by CPU as well as by the VPDMA.
CPU will write/update the VPDMA descriptors containing data
about the video buffer DMA addresses.
VPDMA will write the "write descriptor" containing the
data about the DMA operation.
When mapping/unmapping the buffer, driver has to take care of
WriteBack and invalidation of the cache so that all the
coherency is maintained from both directions.
Use DMA_BIDIRECTIONAL to maintain coherency between CPU and VPDMA.
Change-Id: I44c166391676f457c1b3c983d178e65592a4523d
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
VPDMA buffer will be used by CPU as well as by the VPDMA.
CPU will write/update the VPDMA descriptors containing data
about the video buffer DMA addresses.
VPDMA will write the "write descriptor" containing the
data about the DMA operation.
When mapping/unmapping the buffer, driver has to take care of
WriteBack and invalidation of the cache so that all the
coherency is maintained from both directions.
Use DMA_BIDIRECTIONAL to maintain coherency between CPU and VPDMA.
Change-Id: I44c166391676f457c1b3c983d178e65592a4523d
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
media: ti-vpe: vip: Fix crash when streaming without buffers
When starting a video streaming, to ensure capture without frame drops,
VIP driver tries to post VPDMA descriptors untill the VPDMA FIFO is full.
This adds a constraint that the application should have queued at least
three buffers into the CAPTURE stream before calling STREAMON ioctl.
If for some reason, application calls the STREAMON with zero or less than
three buffers, driver would still try to get the DMA address of the
vb2 buffers and eventually result into NULL pointer crash in vb2 framework
Check the queued buffer count and fail the ioctl gracefully if the required
number of buffers are not queued already.
Change-Id: Ib961500502937de74e6fcf0ae7569f02e98dace3
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
When starting a video streaming, to ensure capture without frame drops,
VIP driver tries to post VPDMA descriptors untill the VPDMA FIFO is full.
This adds a constraint that the application should have queued at least
three buffers into the CAPTURE stream before calling STREAMON ioctl.
If for some reason, application calls the STREAMON with zero or less than
three buffers, driver would still try to get the DMA address of the
vb2 buffers and eventually result into NULL pointer crash in vb2 framework
Check the queued buffer count and fail the ioctl gracefully if the required
number of buffers are not queued already.
Change-Id: Ib961500502937de74e6fcf0ae7569f02e98dace3
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
i2c: ov1063x: Cleanup and optimize sensor configuration
Remove unnecessary delay for sensor internal writes.
Also remove the LVDS specific sensor configuration parameters.
No need to configure the sensor registers differently for LVDS cameras.
Exception for this being the PLL values. Configure the LVDS specific
PLL values (which work for the normal cameras also)
Change-Id: I9c0f0b06869f2cff37fb9f38a8f8dc8ca4f37fbb
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Remove unnecessary delay for sensor internal writes.
Also remove the LVDS specific sensor configuration parameters.
No need to configure the sensor registers differently for LVDS cameras.
Exception for this being the PLL values. Configure the LVDS specific
PLL values (which work for the normal cameras also)
Change-Id: I9c0f0b06869f2cff37fb9f38a8f8dc8ca4f37fbb
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm: dts: dra7: jamr3: Add channel info for tvp5158
Describe the channel numbers used by TVP5158 to multiplex the
4 analog video inputs.
Specify the list of channel numbers correctly, so that the video
devices for each of them are created.
Change-Id: Iec99fe010c9721390d77fdd2ca4fcd22b8c50ba7
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Describe the channel numbers used by TVP5158 to multiplex the
4 analog video inputs.
Specify the list of channel numbers correctly, so that the video
devices for each of them are created.
Change-Id: Iec99fe010c9721390d77fdd2ca4fcd22b8c50ba7
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
media: ti-vpe: vip: cleanup parser configuration code
Remove redundant checks with simple inline function.
Optimize the parser configuration with minimal register writes.
Remove the independent functions to configure the hsync, vsync, pclk,
actvid, etc and replace that with simple config0.
Split the vip_set_polarity into the vip_set_pclk_invert to take care of
the pixel clock inversion via SMA_SW1 regmap.
Also add the missing single channel embedded sync type.
Change-Id: I749da57c305e12111413608895f594f4cdb83661
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Remove redundant checks with simple inline function.
Optimize the parser configuration with minimal register writes.
Remove the independent functions to configure the hsync, vsync, pclk,
actvid, etc and replace that with simple config0.
Split the vip_set_polarity into the vip_set_pclk_invert to take care of
the pixel clock inversion via SMA_SW1 regmap.
Also add the missing single channel embedded sync type.
Change-Id: I749da57c305e12111413608895f594f4cdb83661
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
v4l: of: Parse endpoint channel information for BT656 bus
For BT656 bus, there can be more than one video time multiplexed.
These are called as channels. There can be multiple methods of
multiplexing, commonly used are, single channel, 2chan, 4chan
pixel multiplexed and line multiplexed(variable chan num).
Alos, the channel numbers for the multiplexed videos can vary.
Add support for describing the channel numbers and multiplexing method
in the device tree endpoint node for the BT656 video interface.
Change-Id: Idcf606854cb9af5af05280136b605c9332d815f0
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
For BT656 bus, there can be more than one video time multiplexed.
These are called as channels. There can be multiple methods of
multiplexing, commonly used are, single channel, 2chan, 4chan
pixel multiplexed and line multiplexed(variable chan num).
Alos, the channel numbers for the multiplexed videos can vary.
Add support for describing the channel numbers and multiplexing method
in the device tree endpoint node for the BT656 video interface.
Change-Id: Idcf606854cb9af5af05280136b605c9332d815f0
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
media: ti-vpe: vip: Add support for port B capture
Current VIP driver only supports port A video capture.
Parse the endpoint nodes to figure out the port information from DT.
For each of the found device, register a separate notifier for it.
Move all the port specific fields from vip_dev to vip_port structure.
Keep a port specific copy for notifier, subdev and active_fmt.
Change-Id: I864ecf8f17b00bfb29ee69a8959725af38ce53bd
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Current VIP driver only supports port A video capture.
Parse the endpoint nodes to figure out the port information from DT.
For each of the found device, register a separate notifier for it.
Move all the port specific fields from vip_dev to vip_port structure.
Keep a port specific copy for notifier, subdev and active_fmt.
Change-Id: I864ecf8f17b00bfb29ee69a8959725af38ce53bd
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm: dts: dra72-evm: New device tree for dra72-evm with vision card
Override the ovcam nodes for cam1, cam2, cam3, cam4 nodes.
Add endpoint nodes for vin1a, 1b, 2a, 2b interfaces.
Also, add the GPIO properties to drive the board muxes.
Add a comment table to map the cameras with the video interfaces.
Change-Id: I494778f1461784183473658302efb218a89d0d49
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Override the ovcam nodes for cam1, cam2, cam3, cam4 nodes.
Add endpoint nodes for vin1a, 1b, 2a, 2b interfaces.
Also, add the GPIO properties to drive the board muxes.
Add a comment table to map the cameras with the video interfaces.
Change-Id: I494778f1461784183473658302efb218a89d0d49
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm: dtsi: dra72: Add VIP mux pinctrl node and bindings
DRA72 device has only one instance of VIP (VIP1)
But the SoC has more video pads(total 8) than available ports (1a,2a,1b,2b)
Each video port can be connected to one of the pad group.
This is selected via a control module register CTRL_CORE_VIP_MUX_SELECT.
Depending on the board design, some of the interfaces would be used and
this register needs to be programmed.
As this can be best fit as a pinctrl device, Add a pinctrl node in dra72x.dtsi
and also add the bindings for the bitfields to be used when configuring
this mux.
Change-Id: I7498ee9c270ac399ac112748c8c19ee93eb8c51e
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
DRA72 device has only one instance of VIP (VIP1)
But the SoC has more video pads(total 8) than available ports (1a,2a,1b,2b)
Each video port can be connected to one of the pad group.
This is selected via a control module register CTRL_CORE_VIP_MUX_SELECT.
Depending on the board design, some of the interfaces would be used and
this register needs to be programmed.
As this can be best fit as a pinctrl device, Add a pinctrl node in dra72x.dtsi
and also add the bindings for the bitfields to be used when configuring
this mux.
Change-Id: I7498ee9c270ac399ac112748c8c19ee93eb8c51e
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm: dts: dra7: vision: Remove gpio from generic vision DTB
dra7xx-vision.dtsi is a generic device tree file while describes the
devices on the vision application board (daughter card)
But the gpios to drive the board muxes for routing the camera signals
vary depending on board muxes.
Remove this information from the generic device tree and add it in the
board specific (dra7-evm-vision) device tree.
Also add a comment table to map camera and video interfaces.
Change-Id: I43fb1f1989ecb2b3f87fae874e395a3424d747d7
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
dra7xx-vision.dtsi is a generic device tree file while describes the
devices on the vision application board (daughter card)
But the gpios to drive the board muxes for routing the camera signals
vary depending on board muxes.
Remove this information from the generic device tree and add it in the
board specific (dra7-evm-vision) device tree.
Also add a comment table to map camera and video interfaces.
Change-Id: I43fb1f1989ecb2b3f87fae874e395a3424d747d7
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
arm: dtsi: dra7: Add port B endpoints in VIP nodes
Each VIP slice has a 24bit port A and an 8bit port B for video capture.
For each of this port, there has to be an endpoint device node which
should connect to the camera endpoint node.
Add the endpoint device nodes for port B. The reg property of the endpoint
node describes the slice and port it belongs to.
Change-Id: I9ead7caa8fc09b898b8f396765a39a75afd3acaf
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Each VIP slice has a 24bit port A and an 8bit port B for video capture.
For each of this port, there has to be an endpoint device node which
should connect to the camera endpoint node.
Add the endpoint device nodes for port B. The reg property of the endpoint
node describes the slice and port it belongs to.
Change-Id: I9ead7caa8fc09b898b8f396765a39a75afd3acaf
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Linux 3.14.51
mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
commit ecf5fc6e9654cd7a268c782a523f072b2f1959f9 upstream.
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync"
#0 __schedule at ffffffff815ab152
#1 schedule at ffffffff815ab76e
#2 schedule_timeout at ffffffff815ae5e5
#3 io_schedule_timeout at ffffffff815aad6a
#4 bit_wait_io at ffffffff815abfc6
#5 __wait_on_bit at ffffffff815abda5
#6 wait_on_page_bit at ffffffff8111fd4f
#7 shrink_page_list at ffffffff81135445
#8 shrink_inactive_list at ffffffff81135845
#9 shrink_lruvec at ffffffff81135ead
#10 shrink_zone at ffffffff811360c3
#11 shrink_zones at ffffffff81136eff
#12 do_try_to_free_pages at ffffffff8113712f
#13 try_to_free_mem_cgroup_pages at ffffffff811372be
#14 try_charge at ffffffff81189423
#15 mem_cgroup_try_charge at ffffffff8118c6f5
#16 __add_to_page_cache_locked at ffffffff8112137d
#17 add_to_page_cache_lru at ffffffff81121618
#18 pagecache_get_page at ffffffff8112170b
#19 grow_dev_page at ffffffff811c8297
#20 __getblk_slow at ffffffff811c91d6
#21 __getblk_gfp at ffffffff811c92c1
#22 ext4_ext_grow_indepth at ffffffff8124565c
#23 ext4_ext_create_new_leaf at ffffffff81246ca8
#24 ext4_ext_insert_extent at ffffffff81246f09
#25 ext4_ext_map_blocks at ffffffff8124a848
#26 ext4_map_blocks at ffffffff8121a5b7
#27 mpage_map_one_extent at ffffffff8121b1fa
#28 mpage_map_and_submit_extent at ffffffff8121f07b
#29 ext4_writepages at ffffffff8121f6d5
#30 do_writepages at ffffffff8112c490
#31 __filemap_fdatawrite_range at ffffffff81120199
#32 filemap_flush at ffffffff8112041c
#33 ext4_alloc_da_blocks at ffffffff81219da1
#34 ext4_rename at ffffffff81229b91
#35 ext4_rename2 at ffffffff81229e32
#36 vfs_rename at ffffffff811a08a5
#37 SYSC_renameat2 at ffffffff811a3ffc
#38 sys_renameat2 at ffffffff811a408e
#39 sys_rename at ffffffff8119e51e
#40 system_call_fastpath at ffffffff815afa89
Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.
The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified. The code has been changed by c3b94f44fcb0 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code. But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.
ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.
Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback. The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.
As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ecf5fc6e9654cd7a268c782a523f072b2f1959f9 upstream.
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync"
#0 __schedule at ffffffff815ab152
#1 schedule at ffffffff815ab76e
#2 schedule_timeout at ffffffff815ae5e5
#3 io_schedule_timeout at ffffffff815aad6a
#4 bit_wait_io at ffffffff815abfc6
#5 __wait_on_bit at ffffffff815abda5
#6 wait_on_page_bit at ffffffff8111fd4f
#7 shrink_page_list at ffffffff81135445
#8 shrink_inactive_list at ffffffff81135845
#9 shrink_lruvec at ffffffff81135ead
#10 shrink_zone at ffffffff811360c3
#11 shrink_zones at ffffffff81136eff
#12 do_try_to_free_pages at ffffffff8113712f
#13 try_to_free_mem_cgroup_pages at ffffffff811372be
#14 try_charge at ffffffff81189423
#15 mem_cgroup_try_charge at ffffffff8118c6f5
#16 __add_to_page_cache_locked at ffffffff8112137d
#17 add_to_page_cache_lru at ffffffff81121618
#18 pagecache_get_page at ffffffff8112170b
#19 grow_dev_page at ffffffff811c8297
#20 __getblk_slow at ffffffff811c91d6
#21 __getblk_gfp at ffffffff811c92c1
#22 ext4_ext_grow_indepth at ffffffff8124565c
#23 ext4_ext_create_new_leaf at ffffffff81246ca8
#24 ext4_ext_insert_extent at ffffffff81246f09
#25 ext4_ext_map_blocks at ffffffff8124a848
#26 ext4_map_blocks at ffffffff8121a5b7
#27 mpage_map_one_extent at ffffffff8121b1fa
#28 mpage_map_and_submit_extent at ffffffff8121f07b
#29 ext4_writepages at ffffffff8121f6d5
#30 do_writepages at ffffffff8112c490
#31 __filemap_fdatawrite_range at ffffffff81120199
#32 filemap_flush at ffffffff8112041c
#33 ext4_alloc_da_blocks at ffffffff81219da1
#34 ext4_rename at ffffffff81229b91
#35 ext4_rename2 at ffffffff81229e32
#36 vfs_rename at ffffffff811a08a5
#37 SYSC_renameat2 at ffffffff811a3ffc
#38 sys_renameat2 at ffffffff811a408e
#39 sys_rename at ffffffff8119e51e
#40 system_call_fastpath at ffffffff815afa89
Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.
The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified. The code has been changed by c3b94f44fcb0 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code. But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.
ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.
Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback. The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.
As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
md/bitmap: return an error when bitmap superblock is corrupt.
commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
Use separate bitmaps for each nodes in the cluster
bitmap_read_sb() validates the bitmap superblock that it reads in.
If it finds an inconsistency like a bad magic number or out-of-range
version number, it prints an error and returns, but it incorrectly
returns zero, so the array is still assembled with the (invalid) bitmap.
This means it could try to use a bitmap with a new version number which
it therefore does not understand.
This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
So the patch is suitable for any -stable kernel in that range.
Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
Signed-off-by: NeilBrown <neilb@suse.com>
Reported-by: GuoQing Jiang <gqjiang@suse.com>
commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
Use separate bitmaps for each nodes in the cluster
bitmap_read_sb() validates the bitmap superblock that it reads in.
If it finds an inconsistency like a bad magic number or out-of-range
version number, it prints an error and returns, but it incorrectly
returns zero, so the array is still assembled with the (invalid) bitmap.
This means it could try to use a bitmap with a new version number which
it therefore does not understand.
This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
So the patch is suitable for any -stable kernel in that range.
Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
Signed-off-by: NeilBrown <neilb@suse.com>
Reported-by: GuoQing Jiang <gqjiang@suse.com>
path_openat(): fix double fput()
commit f15133df088ecadd141ea1907f2c96df67c729f0 upstream.
path_openat() jumps to the wrong place after do_tmpfile() - it has
already done path_cleanup() (as part of path_lookupat() called by
do_tmpfile()), so doing that again can lead to double fput().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f15133df088ecadd141ea1907f2c96df67c729f0 upstream.
path_openat() jumps to the wrong place after do_tmpfile() - it has
already done path_cleanup() (as part of path_lookupat() called by
do_tmpfile()), so doing that again can lead to double fput().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kvm: x86: fix kvm_apic_has_events to check for NULL pointer
commit ce40cd3fc7fa40a6119e5fe6c0f2bc0eb4541009 upstream.
Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wang Kai <morgan.wang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce40cd3fc7fa40a6119e5fe6c0f2bc0eb4541009 upstream.
Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wang Kai <morgan.wang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dcache: don't need rcu in shrink_dentry_list()
commit 60942f2f235ce7b817166cdf355eed729094834d upstream.
Since now the shrink list is private and nobody can free the dentry while
it is on the shrink list, we can remove RCU protection from this.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 60942f2f235ce7b817166cdf355eed729094834d upstream.
Since now the shrink list is private and nobody can free the dentry while
it is on the shrink list, we can remove RCU protection from this.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
more graceful recovery in umount_collect()
commit 9c8c10e262e0f62cb2530f1b076de979123183dd upstream.
Start with shrink_dcache_parent(), then scan what remains.
First of all, BUG() is very much an overkill here; we are holding
->s_umount, and hitting BUG() means that a lot of interesting stuff
will be hanging after that point (sync(2), for example). Moreover,
in cases when there had been more than one leak, we'll be better
off reporting all of them. And more than just the last component
of pathname - %pd is there for just such uses...
That was the last user of dentry_lru_del(), so kill it off...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c8c10e262e0f62cb2530f1b076de979123183dd upstream.
Start with shrink_dcache_parent(), then scan what remains.
First of all, BUG() is very much an overkill here; we are holding
->s_umount, and hitting BUG() means that a lot of interesting stuff
will be hanging after that point (sync(2), for example). Moreover,
in cases when there had been more than one leak, we'll be better
off reporting all of them. And more than just the last component
of pathname - %pd is there for just such uses...
That was the last user of dentry_lru_del(), so kill it off...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
don't remove from shrink list in select_collect()
commit fe91522a7ba82ca1a51b07e19954b3825e4aaa22 upstream.
If we find something already on a shrink list, just increment
data->found and do nothing else. Loops in shrink_dcache_parent() and
check_submounts_and_drop() will do the right thing - everything we
did put into our list will be evicted and if there had been nothing,
but data->found got non-zero, well, we have somebody else shrinking
those guys; just try again.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe91522a7ba82ca1a51b07e19954b3825e4aaa22 upstream.
If we find something already on a shrink list, just increment
data->found and do nothing else. Loops in shrink_dcache_parent() and
check_submounts_and_drop() will do the right thing - everything we
did put into our list will be evicted and if there had been nothing,
but data->found got non-zero, well, we have somebody else shrinking
those guys; just try again.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dentry_kill(): don't try to remove from shrink list
commit 41edf278fc2f042f4e22a12ed87d19c5201210e1 upstream.
If the victim in on the shrink list, don't remove it from there.
If shrink_dentry_list() manages to remove it from the list before
we are done - fine, we'll just free it as usual. If not - mark
it with new flag (DCACHE_MAY_FREE) and leave it there.
Eventually, shrink_dentry_list() will get to it, remove the sucker
from shrink list and call dentry_kill(dentry, 0). Which is where
we'll deal with freeing.
Since now dentry_kill(dentry, 0) may happen after or during
dentry_kill(dentry, 1), we need to recognize that (by seeing
DCACHE_DENTRY_KILLED already set), unlock everything
and either free the sucker (in case DCACHE_MAY_FREE has been
set) or leave it for ongoing dentry_kill(dentry, 1) to deal with.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 41edf278fc2f042f4e22a12ed87d19c5201210e1 upstream.
If the victim in on the shrink list, don't remove it from there.
If shrink_dentry_list() manages to remove it from the list before
we are done - fine, we'll just free it as usual. If not - mark
it with new flag (DCACHE_MAY_FREE) and leave it there.
Eventually, shrink_dentry_list() will get to it, remove the sucker
from shrink list and call dentry_kill(dentry, 0). Which is where
we'll deal with freeing.
Since now dentry_kill(dentry, 0) may happen after or during
dentry_kill(dentry, 1), we need to recognize that (by seeing
DCACHE_DENTRY_KILLED already set), unlock everything
and either free the sucker (in case DCACHE_MAY_FREE has been
set) or leave it for ongoing dentry_kill(dentry, 1) to deal with.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
expand the call of dentry_lru_del() in dentry_kill()
commit 01b6035190b024240a43ac1d8e9c6f964f5f1c63 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01b6035190b024240a43ac1d8e9c6f964f5f1c63 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
new helper: dentry_free()
commit b4f0354e968f5fabd39bc85b99fedae4a97589fe upstream.
The part of old d_free() that dealt with actual freeing of dentry.
Taken out of dentry_kill() into a separate function.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4f0354e968f5fabd39bc85b99fedae4a97589fe upstream.
The part of old d_free() that dealt with actual freeing of dentry.
Taken out of dentry_kill() into a separate function.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fold try_prune_one_dentry()
commit 5c47e6d0ad608987b91affbcf7d1fc12dfbe8fb4 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c47e6d0ad608987b91affbcf7d1fc12dfbe8fb4 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fold d_kill() and d_free()
commit 03b3b889e79cdb6b806fc0ba9be0d71c186bbfaa upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03b3b889e79cdb6b806fc0ba9be0d71c186bbfaa upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
signal: fix information leak in copy_siginfo_from_user32
commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 upstream.
This function can leak kernel stack data when the user siginfo_t has a
positive si_code value. The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.
copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.
This fixes the following information leaks:
x86: 8 bytes leaked when sending a signal from a 32-bit process to
itself. This leak grows to 16 bytes if the process uses x32.
(si_code = __SI_CHLD)
x86: 100 bytes leaked when sending a signal from a 32-bit process to
a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
64-bit process. (si_code = any)
parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process. These bugs are also fixed for consistency.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 upstream.
This function can leak kernel stack data when the user siginfo_t has a
positive si_code value. The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.
copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.
This fixes the following information leaks:
x86: 8 bytes leaked when sending a signal from a 32-bit process to
itself. This leak grows to 16 bytes if the process uses x32.
(si_code = __SI_CHLD)
x86: 100 bytes leaked when sending a signal from a 32-bit process to
a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
64-bit process. (si_code = any)
parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process. These bugs are also fixed for consistency.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
signal: fix information leak in copy_siginfo_to_user
commit 26135022f85105ad725cda103fa069e29e83bd16 upstream.
This function may copy the si_addr_lsb, si_lower and si_upper fields to
user mode when they haven't been initialized, which can leak kernel
stack data to user mode.
Just checking the value of si_code is insufficient because the same
si_code value is shared between multiple signals. This is solved by
checking the value of si_signo in addition to si_code.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26135022f85105ad725cda103fa069e29e83bd16 upstream.
This function may copy the si_addr_lsb, si_lower and si_upper fields to
user mode when they haven't been initialized, which can leak kernel
stack data to user mode.
Just checking the value of si_code is insufficient because the same
si_code value is shared between multiple signals. This is solved by
checking the value of si_signo in addition to si_code.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
signalfd: fix information leak in signalfd_copyinfo
commit 3ead7c52bdb0ab44f4bb1feed505a8323cc12ba7 upstream.
This function may copy the si_addr_lsb field to user mode when it hasn't
been initialized, which can leak kernel stack data to user mode.
Just checking the value of si_code is insufficient because the same
si_code value is shared between multiple signals. This is solved by
checking the value of si_signo in addition to si_code.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ead7c52bdb0ab44f4bb1feed505a8323cc12ba7 upstream.
This function may copy the si_addr_lsb field to user mode when it hasn't
been initialized, which can leak kernel stack data to user mode.
Just checking the value of si_code is insufficient because the same
si_code value is shared between multiple signals. This is solved by
checking the value of si_signo in addition to si_code.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sg_start_req(): make sure that there's not too many elements in iovec
commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.
unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there. If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.
X-Coverup: TINC (and there's no lumber cartel either)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
that function.]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.
unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there. If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.
X-Coverup: TINC (and there's no lumber cartel either)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
that function.]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
commit 423f04d63cf421ea436bcc5be02543d549ce4b28 upstream.
raid1_end_read_request() assumes that the In_sync bits are consistent
with the ->degaded count.
raid1_spare_active updates the In_sync bit before the ->degraded count
and so exposes an inconsistency, as does error()
So extend the spinlock in raid1_spare_active() and error() to hide those
inconsistencies.
This should probably be part of
Commit: 34cab6f42003 ("md/raid1: fix test for 'was read error from
last working device'.")
as it addresses the same issue. It fixes the same bug and should go
to -stable for same reasons.
Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 423f04d63cf421ea436bcc5be02543d549ce4b28 upstream.
raid1_end_read_request() assumes that the In_sync bits are consistent
with the ->degaded count.
raid1_spare_active updates the In_sync bit before the ->degraded count
and so exposes an inconsistency, as does error()
So extend the spinlock in raid1_spare_active() and error() to hide those
inconsistencies.
This should probably be part of
Commit: 34cab6f42003 ("md/raid1: fix test for 'was read error from
last working device'.")
as it addresses the same issue. It fixes the same bug and should go
to -stable for same reasons.
Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
commit c9ddbac9c89110f77cb0fa07e634aaf1194899aa upstream.
09a2c73ddfc7 ("PCI: Remove unused PCI_MSIX_FLAGS_BIRMASK definition")
removed PCI_MSIX_FLAGS_BIRMASK from an exported header because it was
unused in the kernel. But that breaks user programs that were using it
(QEMU in particular).
Restore the PCI_MSIX_FLAGS_BIRMASK definition.
[bhelgaas: changelog]
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9ddbac9c89110f77cb0fa07e634aaf1194899aa upstream.
09a2c73ddfc7 ("PCI: Remove unused PCI_MSIX_FLAGS_BIRMASK definition")
removed PCI_MSIX_FLAGS_BIRMASK from an exported header because it was
unused in the kernel. But that breaks user programs that were using it
(QEMU in particular).
Restore the PCI_MSIX_FLAGS_BIRMASK definition.
[bhelgaas: changelog]
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
commit 209f7512d007980fd111a74a064d70a3656079cf upstream.
The "BUG_ON(list_empty(&osb->blocked_lock_list))" in
ocfs2_downconvert_thread_do_work can be triggered in the following case:
ocfs2dc has firstly saved osb->blocked_lock_count to local varibale
processed, and then processes the dentry lockres. During the dentry
put, it calls iput and then deletes rw, inode and open lockres from
blocked list in ocfs2_mark_lockres_freeing. And this causes the
variable `processed' to not reflect the number of blocked lockres to be
processed, which triggers the BUG.
Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 209f7512d007980fd111a74a064d70a3656079cf upstream.
The "BUG_ON(list_empty(&osb->blocked_lock_list))" in
ocfs2_downconvert_thread_do_work can be triggered in the following case:
ocfs2dc has firstly saved osb->blocked_lock_count to local varibale
processed, and then processes the dentry lockres. During the dentry
put, it calls iput and then deletes rw, inode and open lockres from
blocked list in ocfs2_mark_lockres_freeing. And this causes the
variable `processed' to not reflect the number of blocked lockres to be
processed, which triggers the BUG.
Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipc: modify message queue accounting to not take kernel data structures into account
commit de54b9ac253787c366bbfb28d901a31954eb3511 upstream.
A while back, the message queue implementation in the kernel was
improved to use btrees to speed up retrieval of messages, in commit
d6629859b36d ("ipc/mqueue: improve performance of send/recv").
That patch introducing the improved kernel handling of message queues
(using btrees) has, as a by-product, changed the meaning of the QSIZE
field in the pseudo-file created for the queue. Before, this field
reflected the size of the user-data in the queue. Since, it also takes
kernel data structures into account. For example, if 13 bytes of user
data are in the queue, on my machine the file reports a size of 61
bytes.
There was some discussion on this topic before (for example
https://lkml.org/lkml/2014/10/1/115). Commenting on a th lkml, Michael
Kerrisk gave the following background
(https://lkml.org/lkml/2015/6/16/74):
The pseudofiles in the mqueue filesystem (usually mounted at
/dev/mqueue) expose fields with metadata describing a message
queue. One of these fields, QSIZE, as originally implemented,
showed the total number of bytes of user data in all messages in
the message queue, and this feature was documented from the
beginning in the mq_overview(7) page. In 3.5, some other (useful)
work happened to break the user-space API in a couple of places,
including the value exposed via QSIZE, which now includes a measure
of kernel overhead bytes for the queue, a figure that renders QSIZE
useless for its original purpose, since there's no way to deduce
the number of overhead bytes consumed by the implementation.
(The other user-space breakage was subsequently fixed.)
This patch removes the accounting of kernel data structures in the
queue. Reporting the size of these data-structures in the QSIZE field
was a breaking change (see Michael's comment above). Without the QSIZE
field reporting the total size of user-data in the queue, there is no
way to deduce this number.
It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
against the worst-case size of the queue (in both the old and the new
implementation). Therefore, the kernel overhead accounting in QSIZE is
not necessary to help the user understand the limitations RLIMIT imposes
on the processes.
Signed-off-by: Marcus Gelderie <redmnic@gmail.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: John Duffy <jb_duffy@btinternet.com>
Cc: Arto Bendiken <arto@bendiken.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de54b9ac253787c366bbfb28d901a31954eb3511 upstream.
A while back, the message queue implementation in the kernel was
improved to use btrees to speed up retrieval of messages, in commit
d6629859b36d ("ipc/mqueue: improve performance of send/recv").
That patch introducing the improved kernel handling of message queues
(using btrees) has, as a by-product, changed the meaning of the QSIZE
field in the pseudo-file created for the queue. Before, this field
reflected the size of the user-data in the queue. Since, it also takes
kernel data structures into account. For example, if 13 bytes of user
data are in the queue, on my machine the file reports a size of 61
bytes.
There was some discussion on this topic before (for example
https://lkml.org/lkml/2014/10/1/115). Commenting on a th lkml, Michael
Kerrisk gave the following background
(https://lkml.org/lkml/2015/6/16/74):
The pseudofiles in the mqueue filesystem (usually mounted at
/dev/mqueue) expose fields with metadata describing a message
queue. One of these fields, QSIZE, as originally implemented,
showed the total number of bytes of user data in all messages in
the message queue, and this feature was documented from the
beginning in the mq_overview(7) page. In 3.5, some other (useful)
work happened to break the user-space API in a couple of places,
including the value exposed via QSIZE, which now includes a measure
of kernel overhead bytes for the queue, a figure that renders QSIZE
useless for its original purpose, since there's no way to deduce
the number of overhead bytes consumed by the implementation.
(The other user-space breakage was subsequently fixed.)
This patch removes the accounting of kernel data structures in the
queue. Reporting the size of these data-structures in the QSIZE field
was a breaking change (see Michael's comment above). Without the QSIZE
field reporting the total size of user-data in the queue, there is no
way to deduce this number.
It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
against the worst-case size of the queue (in both the old and the new
implementation). Therefore, the kernel overhead accounting in QSIZE is
not necessary to help the user understand the limitations RLIMIT imposes
on the processes.
Signed-off-by: Marcus Gelderie <redmnic@gmail.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: John Duffy <jb_duffy@btinternet.com>
Cc: Arto Bendiken <arto@bendiken.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - fix cs4210_spdif_automute()
commit 44008f0896ae205b02b0882dbf807f0de149efc4 upstream.
Smatch complains that we have nested checks for "spdif_present". It
turns out the current behavior isn't correct, we should remove the first
check and keep the second.
Fixes: 1077a024812d ('ALSA: hda - Use generic parser for Cirrus codec driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 44008f0896ae205b02b0882dbf807f0de149efc4 upstream.
Smatch complains that we have nested checks for "spdif_present". It
turns out the current behavior isn't correct, we should remove the first
check and keep the second.
Fixes: 1077a024812d ('ALSA: hda - Use generic parser for Cirrus codec driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iscsi-target: Fix iscsit_start_kthreads failure OOPs
commit e54198657b65625085834847ab6271087323ffea upstream.
This patch fixes a regression introduced with the following commit
in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers
a NULL pointer dereference OOPs:
commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Thu Feb 26 22:19:15 2015 -0800
iscsi-target: Convert iscsi_thread_set usage to kthread.h
To address this bug, move iscsit_start_kthreads() immediately
preceeding the transmit of last login response, before signaling
a successful transition into full-feature-phase within existing
iscsi_target_do_tx_login_io() logic.
This ensures that no target-side resource allocation failures can
occur after the final login response has been successfully sent.
Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread
to sleep to prevent other socket related failures until the final
iscsi_post_login_handler() call is able to complete.
Cc: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Nicholas Bellinger <nab@daterainc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e54198657b65625085834847ab6271087323ffea upstream.
This patch fixes a regression introduced with the following commit
in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers
a NULL pointer dereference OOPs:
commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Thu Feb 26 22:19:15 2015 -0800
iscsi-target: Convert iscsi_thread_set usage to kthread.h
To address this bug, move iscsit_start_kthreads() immediately
preceeding the transmit of last login response, before signaling
a successful transition into full-feature-phase within existing
iscsi_target_do_tx_login_io() logic.
This ensures that no target-side resource allocation failures can
occur after the final login response has been successfully sent.
Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread
to sleep to prevent other socket related failures until the final
iscsi_post_login_handler() call is able to complete.
Cc: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Nicholas Bellinger <nab@daterainc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
commit 9a258afa928b45e6dd2efcac46ccf7eea705d35a upstream.
For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready state check
on those modules after the module is enabled.
This can potentially cause a bus access error if the module is accessed
before the module is ready.
Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
_init(). Do ioremap only if we need SYSC access.
Eventhough _wait_target_ready() check doesn't really need MPU RT port but
just the PRCM registers, we still mandate that the hwmod must have an
MPU RT port if ready state check needs to be done. Else it would mean that
the module is not accessible by MPU so there is no point in waiting
for target to be ready.
e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
[ 16.672978] ------------[ cut here ]------------
[ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c()
[ 16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
[ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc
[ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180
[ 16.739747] Backtrace:
[ 16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c)
[ 16.750285] r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000
[ 16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28)
[ 16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c)
[ 16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40)
[ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
[ 16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c)
[ 16.797968] r3:ed0cd480 r2:c0730508
[ 16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc)
[ 16.811533] r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a
[ 16.819780] r4:ed0e6d80
[ 16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40)
[ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a
[ 16.840052] r4:ed005600
[ 16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128)
[ 16.851702] r4:ed005600 r3:00000000
[ 16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38)
[ 16.864523] r4:0000002a r3:c0066164
[ 16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c)
[ 16.876612] r4:c081c640 r3:00000202
[ 16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c)
[ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100
[ 16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50)
[ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
[ 16.907499] ba20: 00000000 00000006
[ 16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960
[ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff
[ 16.933317] r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c
[ 16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can])
[ 16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev])
[ 16.963480] r5:ec8c9740 r4:ed3d3000
[ 16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc)
[ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
[ 16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc)
[ 16.990401] r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000
[ 16.998671] r4:00000000
[ 17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0)
[ 17.009772] r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740
[ 17.018050] r4:ebd4d000
[ 17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154)
[ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
[ 17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4)
[ 17.043778] r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0
[ 17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8)
[ 17.058449] r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
[ 17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c)
[ 17.073854] r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110
[ 17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec)
[ 17.088363] r4:ed0c6800 r3:c0504110
[ 17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380)
[ 17.100813] r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4
[ 17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0)
[ 17.117305] r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70
[ 17.125563] r4:c05103c4
[ 17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc)
[ 17.136001] r6:becdda5c r5:00000014 r4:ecd37040
[ 17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30)
[ 17.148923] r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c
[ 17.157169] ---[ end trace 2b71e15b38f58bad ]---
Fixes: 6423d6df1440 ("ARM: OMAP2+: hwmod: check for module address space during init")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9a258afa928b45e6dd2efcac46ccf7eea705d35a upstream.
For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready state check
on those modules after the module is enabled.
This can potentially cause a bus access error if the module is accessed
before the module is ready.
Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
_init(). Do ioremap only if we need SYSC access.
Eventhough _wait_target_ready() check doesn't really need MPU RT port but
just the PRCM registers, we still mandate that the hwmod must have an
MPU RT port if ready state check needs to be done. Else it would mean that
the module is not accessible by MPU so there is no point in waiting
for target to be ready.
e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
[ 16.672978] ------------[ cut here ]------------
[ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c()
[ 16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
[ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc
[ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180
[ 16.739747] Backtrace:
[ 16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c)
[ 16.750285] r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000
[ 16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28)
[ 16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c)
[ 16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40)
[ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
[ 16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c)
[ 16.797968] r3:ed0cd480 r2:c0730508
[ 16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc)
[ 16.811533] r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a
[ 16.819780] r4:ed0e6d80
[ 16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40)
[ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a
[ 16.840052] r4:ed005600
[ 16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128)
[ 16.851702] r4:ed005600 r3:00000000
[ 16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38)
[ 16.864523] r4:0000002a r3:c0066164
[ 16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c)
[ 16.876612] r4:c081c640 r3:00000202
[ 16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c)
[ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100
[ 16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50)
[ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
[ 16.907499] ba20: 00000000 00000006
[ 16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960
[ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff
[ 16.933317] r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c
[ 16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can])
[ 16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev])
[ 16.963480] r5:ec8c9740 r4:ed3d3000
[ 16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc)
[ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
[ 16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc)
[ 16.990401] r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000
[ 16.998671] r4:00000000
[ 17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0)
[ 17.009772] r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740
[ 17.018050] r4:ebd4d000
[ 17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154)
[ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
[ 17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4)
[ 17.043778] r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0
[ 17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8)
[ 17.058449] r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
[ 17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c)
[ 17.073854] r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110
[ 17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec)
[ 17.088363] r4:ed0c6800 r3:c0504110
[ 17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380)
[ 17.100813] r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4
[ 17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0)
[ 17.117305] r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70
[ 17.125563] r4:c05103c4
[ 17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc)
[ 17.136001] r6:becdda5c r5:00000014 r4:ecd37040
[ 17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30)
[ 17.148923] r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c
[ 17.157169] ---[ end trace 2b71e15b38f58bad ]---
Fixes: 6423d6df1440 ("ARM: OMAP2+: hwmod: check for module address space during init")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rbd: fix copyup completion race
commit 2761713d35e370fd640b5781109f753066b746c4 upstream.
For write/discard obj_requests that involved a copyup method call, the
opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
rbd_img_obj_copyup_callback(). The latter frees copyup pages, sets
->xferred and delegates to rbd_img_obj_callback(), the "normal" image
object callback, for reporting to block layer and putting refs.
rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
which means obj_request is marked done in rbd_osd_trivial_callback(),
*before* ->callback is invoked and rbd_img_obj_copyup_callback() has
a chance to run. Marking obj_request done essentially means giving
rbd_img_obj_callback() a license to end it at any moment, so if another
obj_request from the same img_request is being completed concurrently,
rbd_img_obj_end_request() may very well be called on such prematurally
marked done request:
<obj_request-1/2 reply>
handle_reply()
rbd_osd_req_callback()
rbd_osd_trivial_callback()
rbd_obj_request_complete()
rbd_img_obj_copyup_callback()
rbd_img_obj_callback()
<obj_request-2/2 reply>
handle_reply()
rbd_osd_req_callback()
rbd_osd_trivial_callback()
for_each_obj_request(obj_request->img_request) {
rbd_img_obj_end_request(obj_request-1/2)
rbd_img_obj_end_request(obj_request-2/2) <--
}
Calling rbd_img_obj_end_request() on such a request leads to trouble,
in particular because its ->xfferred is 0. We report 0 to the block
layer with blk_update_request(), get back 1 for "this request has more
data in flight" and then trip on
rbd_assert(more ^ (which == img_request->obj_request_count));
with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
been called for both requests and lhs (more) being 1 because we haven't
got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
To fix this, leverage that rbd wants to call class methods in only two
cases: one is a generic method call wrapper (obj_request is standalone)
and the other is a copyup (obj_request is part of an img_request). So
make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
rbd_img_obj_copyup_callback() from it if obj_request is part of an
img_request, similar to how CEPH_OSD_OP_READ handler invokes
rbd_img_obj_request_read_callback().
Since rbd_img_obj_copyup_callback() is now being called from the OSD
request callback (only), it is renamed to rbd_osd_copyup_callback().
Cc: Alex Elder <elder@linaro.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2761713d35e370fd640b5781109f753066b746c4 upstream.
For write/discard obj_requests that involved a copyup method call, the
opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
rbd_img_obj_copyup_callback(). The latter frees copyup pages, sets
->xferred and delegates to rbd_img_obj_callback(), the "normal" image
object callback, for reporting to block layer and putting refs.
rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
which means obj_request is marked done in rbd_osd_trivial_callback(),
*before* ->callback is invoked and rbd_img_obj_copyup_callback() has
a chance to run. Marking obj_request done essentially means giving
rbd_img_obj_callback() a license to end it at any moment, so if another
obj_request from the same img_request is being completed concurrently,
rbd_img_obj_end_request() may very well be called on such prematurally
marked done request:
<obj_request-1/2 reply>
handle_reply()
rbd_osd_req_callback()
rbd_osd_trivial_callback()
rbd_obj_request_complete()
rbd_img_obj_copyup_callback()
rbd_img_obj_callback()
<obj_request-2/2 reply>
handle_reply()
rbd_osd_req_callback()
rbd_osd_trivial_callback()
for_each_obj_request(obj_request->img_request) {
rbd_img_obj_end_request(obj_request-1/2)
rbd_img_obj_end_request(obj_request-2/2) <--
}
Calling rbd_img_obj_end_request() on such a request leads to trouble,
in particular because its ->xfferred is 0. We report 0 to the block
layer with blk_update_request(), get back 1 for "this request has more
data in flight" and then trip on
rbd_assert(more ^ (which == img_request->obj_request_count));
with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
been called for both requests and lhs (more) being 1 because we haven't
got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
To fix this, leverage that rbd wants to call class methods in only two
cases: one is a generic method call wrapper (obj_request is standalone)
and the other is a copyup (obj_request is part of an img_request). So
make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
rbd_img_obj_copyup_callback() from it if obj_request is part of an
img_request, similar to how CEPH_OSD_OP_READ handler invokes
rbd_img_obj_request_read_callback().
Since rbd_img_obj_copyup_callback() is now being called from the OSD
request callback (only), it is renamed to rbd_osd_copyup_callback().
Cc: Alex Elder <elder@linaro.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer
commit f898c522f0e9ac9f3177d0762b76e2ab2d2cf9c0 upstream.
This patch removes a bogus BUG_ON in the ablkcipher path that
triggers when the destination buffer is different from the source
buffer and is scattered.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f898c522f0e9ac9f3177d0762b76e2ab2d2cf9c0 upstream.
This patch removes a bogus BUG_ON in the ablkcipher path that
triggers when the destination buffer is different from the source
buffer and is scattered.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xen/gntdevt: Fix race condition in gntdev_release()
commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.
While gntdev_release() is called the MMU notifier is still registered
and can traverse priv->maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.
While gntdev_release() is called the MMU notifier is still registered
and can traverse priv->maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.
While we're at it, add comments to help explain what's going on.
This isn't a great long-term fix. This code should probably be
changed to use something like set_memory_ro.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <dvrabel@cantab.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.
While we're at it, add comments to help explain what's going on.
This isn't a great long-term fix. This code should probably be
changed to use something like set_memory_ro.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <dvrabel@cantab.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ASoC: pcm1681: Fix setting de-emphasis sampling rate selection
commit fa8173a3ef0570affde7da352de202190b3786c2 upstream.
The de-emphasis sampling rate selection is controlled by BIT[3:4] of
PCM1681_DEEMPH_CONTROL register. Do proper left shift to set it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Marek Belisko <marek.belisko@streamunlimited.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fa8173a3ef0570affde7da352de202190b3786c2 upstream.
The de-emphasis sampling rate selection is controlled by BIT[3:4] of
PCM1681_DEEMPH_CONTROL register. Do proper left shift to set it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Marek Belisko <marek.belisko@streamunlimited.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sparc64: Fix userspace FPU register corruptions.
[ Upstream commit 44922150d87cef616fd183220d43d8fde4d41390 ]
If we have a series of events from userpsace, with %fprs=FPRS_FEF,
like follows:
ETRAP
ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP (kernel FPU restore with fpu_saved=0x4)
RTRAP
We will not restore the user registers that were clobbered by the FPU
using kernel code in the inner-most trap.
Traps allocate FPU save slots in the thread struct, and FPU using
sequences save the "dirty" FPU registers only.
This works at the initial trap level because all of the registers
get recorded into the top-level FPU save area, and we'll return
to userspace with the FPU disabled so that any FPU use by the user
will take an FPU disabled trap wherein we'll load the registers
back up properly.
But this is not how trap returns from kernel to kernel operate.
The simplest fix for this bug is to always save all FPU register state
for anything other than the top-most FPU save area.
Getting rid of the optimized inner-slot FPU saving code ends up
making VISEntryHalf degenerate into plain VISEntry.
Longer term we need to do something smarter to reinstate the partial
save optimizations. Perhaps the fundament error is having trap entry
and exit allocate FPU save slots and restore register state. Instead,
the VISEntry et al. calls should be doing that work.
This bug is about two decades old.
Reported-by: James Y Knight <jyknight@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 44922150d87cef616fd183220d43d8fde4d41390 ]
If we have a series of events from userpsace, with %fprs=FPRS_FEF,
like follows:
ETRAP
ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP (kernel FPU restore with fpu_saved=0x4)
RTRAP
We will not restore the user registers that were clobbered by the FPU
using kernel code in the inner-most trap.
Traps allocate FPU save slots in the thread struct, and FPU using
sequences save the "dirty" FPU registers only.
This works at the initial trap level because all of the registers
get recorded into the top-level FPU save area, and we'll return
to userspace with the FPU disabled so that any FPU use by the user
will take an FPU disabled trap wherein we'll load the registers
back up properly.
But this is not how trap returns from kernel to kernel operate.
The simplest fix for this bug is to always save all FPU register state
for anything other than the top-most FPU save area.
Getting rid of the optimized inner-slot FPU saving code ends up
making VISEntryHalf degenerate into plain VISEntry.
Longer term we need to do something smarter to reinstate the partial
save optimizations. Perhaps the fundament error is having trap entry
and exit allocate FPU save slots and restore register state. Instead,
the VISEntry et al. calls should be doing that work.
This bug is about two decades old.
Reported-by: James Y Knight <jyknight@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: sunxi: fix build for THUMB2_KERNEL
commit 1146b600044de64af0ef775025731eeef1fa2189 upstream.
Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:
headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
Since the generic secondary_startup function already does
the same thing in a safe way, we can just drop the private
sunxi implementation and jump straight to secondary_startup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1146b600044de64af0ef775025731eeef1fa2189 upstream.
Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:
headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
Since the generic secondary_startup function already does
the same thing in a safe way, we can just drop the private
sunxi implementation and jump straight to secondary_startup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
md: use kzalloc() when bitmap is disabled
commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
mdu_bitmap_file_t called "file".
5769 file = kmalloc(sizeof(*file), GFP_NOIO);
5770 if (!file)
5771 return -ENOMEM;
This structure is copied to user space at the end of the function.
5786 if (err == 0 &&
5787 copy_to_user(arg, file, sizeof(*file)))
5788 err = -EFAULT
But if bitmap is disabled only the first byte of "file" is initialized
with zero, so it's possible to read some bytes (up to 4095) of kernel
space memory from user space. This is an information leak.
5775 /* bitmap disabled, zero the first byte and copy out */
5776 if (!mddev->bitmap_info.file)
5777 file->pathname[0] = '\0';
Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
mdu_bitmap_file_t called "file".
5769 file = kmalloc(sizeof(*file), GFP_NOIO);
5770 if (!file)
5771 return -ENOMEM;
This structure is copied to user space at the end of the function.
5786 if (err == 0 &&
5787 copy_to_user(arg, file, sizeof(*file)))
5788 err = -EFAULT
But if bitmap is disabled only the first byte of "file" is initialized
with zero, so it's possible to read some bytes (up to 4095) of kernel
space memory from user space. This is an information leak.
5775 /* bitmap disabled, zero the first byte and copy out */
5776 if (!mddev->bitmap_info.file)
5777 file->pathname[0] = '\0';
Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ima: extend "mask" policy matching support
commit 4351c294b8c1028077280f761e158d167b592974 upstream.
The current "mask" policy option matches files opened as MAY_READ,
MAY_WRITE, MAY_APPEND or MAY_EXEC. This patch extends the "mask"
option to match files opened containing one of these modes. For
example, "mask=^MAY_READ" would match files opened read-write.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4351c294b8c1028077280f761e158d167b592974 upstream.
The current "mask" policy option matches files opened as MAY_READ,
MAY_WRITE, MAY_APPEND or MAY_EXEC. This patch extends the "mask"
option to match files opened containing one of these modes. For
example, "mask=^MAY_READ" would match files opened read-write.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ima: add support for new "euid" policy condition
commit 139069eff7388407f19794384c42a534d618ccd7 upstream.
The new "euid" policy condition measures files with the specified
effective uid (euid). In addition, for CAP_SETUID files it measures
files with the specified uid or suid.
Changelog:
- fixed checkpatch.pl warnings
- fixed avc denied {setuid} messages - based on Roberto's feedback
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 139069eff7388407f19794384c42a534d618ccd7 upstream.
The new "euid" policy condition measures files with the specified
effective uid (euid). In addition, for CAP_SETUID files it measures
files with the specified uid or suid.
Changelog:
- fixed checkpatch.pl warnings
- fixed avc denied {setuid} messages - based on Roberto's feedback
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Dr. Greg Wettstein <gw@idfusion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: sierra: add 1199:68AB device ID
commit 74472233233f577eaa0ca6d6e17d9017b6e53150 upstream.
Add support for the Sierra Wireless AR8550 device with
USB descriptor 0x1199, 0x68AB.
It is common with MC879x modules 1199:683c/683d which
also are composite devices with 7 interfaces (0..6)
and also MDM62xx based as the AR8550.
The major difference are only the interface attributes
02/02/01 on interfaces 3 and 4 on the AR8550. They are
vendor specific ff/ff/ff on MC879x modules.
lsusb reports:
Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1199 Sierra Wireless, Inc.
idProduct 0x68ab
bcdDevice 0.06
iManufacturer 3 Sierra Wireless, Incorporated
iProduct 2 AR8550
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 198
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 1 Sierra Configuration
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b EP 11 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Cc: Lars Melin <larsm17@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74472233233f577eaa0ca6d6e17d9017b6e53150 upstream.
Add support for the Sierra Wireless AR8550 device with
USB descriptor 0x1199, 0x68AB.
It is common with MC879x modules 1199:683c/683d which
also are composite devices with 7 interfaces (0..6)
and also MDM62xx based as the AR8550.
The major difference are only the interface attributes
02/02/01 on interfaces 3 and 4 on the AR8550. They are
vendor specific ff/ff/ff on MC879x modules.
lsusb reports:
Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1199 Sierra Wireless, Inc.
idProduct 0x68ab
bcdDevice 0.06
iManufacturer 3 Sierra Wireless, Incorporated
iProduct 2 AR8550
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 198
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 1 Sierra Configuration
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b EP 11 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Cc: Lars Melin <larsm17@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: fix off by one error in TRB DMA address boundary check
commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd upstream.
We need to check that a TRB is part of the current segment
before calculating its DMA address.
Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.
Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.
This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:
[ 106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[ 106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
The trb-end address is one outside the end-seg address.
Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd upstream.
We need to check that a TRB is part of the current segment
before calculating its DMA address.
Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.
Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.
This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:
[ 106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[ 106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
The trb-end address is one outside the end-seg address.
Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipr: Fix invalid array indexing for HRRQ
commit 3f1c0581310d5d94bd72740231507e763a6252a4 upstream.
Fixes another signed / unsigned array indexing bug in the ipr driver.
Currently, when hrrq_index wraps, it becomes a negative number. We
do the modulo, but still have a negative number, so we end up indexing
backwards in the array. Given where the hrrq array is located in memory,
we probably won't actually reference memory we don't own, but nonetheless
ipr is still looking at data within struct ipr_ioa_cfg and interpreting it as
struct ipr_hrr_queue data, so bad things could certainly happen.
Each ipr adapter has anywhere from 1 to 16 HRRQs. By default, we use 2 on new
adapters. Let's take an example:
Assume ioa_cfg->hrrq_index=0x7fffffffe and ioa_cfg->hrrq_num=4:
The atomic_add_return will then return -1. We mod this with 3 and get -2, add
one and get -1 for an array index.
On adapters which support more than a single HRRQ, we dedicate HRRQ to adapter
initialization and error interrupts so that we can optimize the other queues
for fast path I/O. So all normal I/O uses HRRQ 1-15. So we want to spread the
I/O requests across those HRRQs.
With the default module parameter settings, this bug won't hit, only when
someone sets the ipr.number_of_msix parameter to a value larger than 3 is when
bad things start to happen.
Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f1c0581310d5d94bd72740231507e763a6252a4 upstream.
Fixes another signed / unsigned array indexing bug in the ipr driver.
Currently, when hrrq_index wraps, it becomes a negative number. We
do the modulo, but still have a negative number, so we end up indexing
backwards in the array. Given where the hrrq array is located in memory,
we probably won't actually reference memory we don't own, but nonetheless
ipr is still looking at data within struct ipr_ioa_cfg and interpreting it as
struct ipr_hrr_queue data, so bad things could certainly happen.
Each ipr adapter has anywhere from 1 to 16 HRRQs. By default, we use 2 on new
adapters. Let's take an example:
Assume ioa_cfg->hrrq_index=0x7fffffffe and ioa_cfg->hrrq_num=4:
The atomic_add_return will then return -1. We mod this with 3 and get -2, add
one and get -1 for an array index.
On adapters which support more than a single HRRQ, we dedicate HRRQ to adapter
initialization and error interrupts so that we can optimize the other queues
for fast path I/O. So all normal I/O uses HRRQ 1-15. So we want to spread the
I/O requests across those HRRQs.
With the default module parameter settings, this bug won't hit, only when
someone sets the ipr.number_of_msix parameter to a value larger than 3 is when
bad things start to happen.
Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipr: Fix incorrect trace indexing
commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 upstream.
When ipr's internal driver trace was changed to an atomic, a signed/unsigned
bug slipped in which results in us indexing backwards in our memory buffer
writing on memory that does not belong to us. This patch fixes this by removing
the modulo and instead just mask off the low bits.
Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 upstream.
When ipr's internal driver trace was changed to an atomic, a signed/unsigned
bug slipped in which results in us indexing backwards in our memory buffer
writing on memory that does not belong to us. This patch fixes this by removing
the modulo and instead just mask off the low bits.
Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipr: Fix locking for unit attention handling
commit 36b8e180e1e929e00b351c3b72aab3147fc14116 upstream.
Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
a crash seen as the __devices list in the scsi host was changing as we were
iterating through it.
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 36b8e180e1e929e00b351c3b72aab3147fc14116 upstream.
Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
a crash seen as the __devices list in the scsi host was changing as we were
iterating through it.
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>