Add a verifier function callback capability to the buffer read
interfaces. This will be used by the callers to supply a function
that verifies the contents of the buffer when it is read from disk.
This patch does not provide callback functions, but simply modifies
the interfaces to allow them to be called.
The reason for adding this to the read interfaces is that it is very
difficult to tell fom the outside is a buffer was just read from
disk or whether we just pulled it out of cache. Supplying a callbck
allows the buffer cache to use it's internal knowledge of the buffer
to execute it only when the buffer is read from disk.
It is intended that the verifier functions will mark the buffer with
an EFSCORRUPTED error when verification fails. This allows the
reading context to distinguish a verification error from an IO
error, and potentially take further actions on the buffer (e.g.
attempt repair) based on the error reported.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Phil White <pwhite@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
In the previous commit, console write function (serial_console_write)
is changed to disable SCI interrupts while printing console strings.
This introduces possible race cases in the serial startup / shutdown
functions on SMP systems.
This patch fixes the sh-sci in the same way as commit 9ec1882df2
(tty: serial: imx: console write routing is unsafe on SMP, from
Xinyu Chen <xinyu.chen@freescale.com>, 2012-08-27) did.
There could be several consumers of the console,
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which opens /dev/console and writes with sys_write()
The shell goes into the normal UART open() and write() system calls,
while the other two go into the console operations. The open() call
invokes serial startup function (sci_startup), which will write to
the SCSCR register (to enable or disable SCI interrupts) without any
locking. This will conflict with the console serial function.
Add spinlock protections in sci_startup() and sci_shutdown() properly.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Symptom:
When entering the suspend with Android logcat running, printk() call
gets stuck and never returns. The issue can be observed at printk()s
on nonboot CPUs when going to offline with their interrupts disabled,
and never seen at boot CPU (core0 in our case).
Details:
serial_console_write() lacks of appropriate spinlock handling.
In SMP systems, as long as sci_transmit_chars() is being processed
at one CPU core, serial_console_write() can stuck at the other CPU
core(s), when it tries to access to the same serial port _without_
a proper locking. serial_console_write() waits for the transmit FIFO
getting empty, while sci_transmit_chars() writes data to the FIFO.
In general, peripheral interrupts are routed to boot CPU (core0) by
Linux ARM standard affinity settings. SCI(F) interrupts are handled
by core0, so sci_transmit_chars() is processed on core0 as well.
When logcat is running, it writes enormous log data to the kernel at
every moment, forever. So core0 can repeatedly continue to process
sci_transmit_chars() in its interrupt handler, which eventually makes
the other CPU core(s) stuck at serial_console_write().
Looking at serial/8250.c, this is a known console write lockup issue
with SMP kernels. Fix the sh-sci driver in the same way 8250.c does.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
About FIFO count, there are two variants of SCIFs which show
a) TX count in upper, RX count in lower byte of FDR register
b) TX count in TFDR register, RX count in RFDR register
Common SCIFB regmap in current source code is defined as "a".
At least 7372 and 73a0 HW manual say their SICFB are "b".
This patch alters the definition to "b", considering the current
one has come from a mistake. The reason is as follows.
The flag SCIFB sh-sci driver means it has 256 byte FIFO.
The count is from 0(empty) to 256(full), that makes 9-bit.
Because FDR is 16-bit register, it can not hold two 9-bits.
That's why, SCIFB can not be "a".
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Current mask 0xff to SCTFDR/RFDR damages SCIFB, because the
registers on SCIFB have 9-bit data (0 to 256).
This patch changes the mask according to port->fifosize.
Though I'm not sure if the mask is really needed (I don't know if
there are variants which have non-zero upper bits), it is safer.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Support prescaler 1/16 and 1/64, in addition to current 1 and 1/4.
Supporting below 2400bps was dropped long time ago in mainline.
Since then, setting lower rate has been resulting in erroneous
register value, without indicating any errors through API.
This patch adds more prescaler to support lower rates again.
This still doesn't check range, but we won't hit the case because
even 50bps at 48MHz clock is now supported.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit 1ba7622094 (serial: sh-sci: console Runtime PM support,
from Magnus Damm <damm@opensource.se>, 2011-08-03), tried to support
console runtime PM, but unfortunately it didn't work for us for some
reason. We did not investigated further at that time, instead would
like to propose a different approach.
In Linux tty/serial world, to get console PM work properly, a serial
client driver does not have to maintain .runtime_suspend()/..resume()
calls itself, but can leave console power power management handling to
the serial core driver.
This patch moves the sh-sci driver in that direction.
Notes:
* There is room to optimize console runtime PM more aggressively by
maintaining additional local runtime PM calls, but as a first step
having .pm() operation would suffice.
* We still have a couple of direct calls to sci_port_enable/..disable
left in the driver. We have to live with them, because they're out
of serial core's help.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This partially reverts commit 1ba7622094 (serial: sh-sci: console
Runtime PM support, from Magnus Damm <damm@opensource.se>, 2011-08-03).
The generic 'serial_core' can take care of console PM maintenance,
so all (or at least the first thing) we have to do to get console PM
work properly, is to implement uart_ops ->pm() operation in the sh-sci
serial client driver.
This patch partially reverts the commit above, but leaving sci_reset()
change in place, because sci_reset() is already part of another commit
(73c3d53f38 serial: sh-sci: Avoid FIFO clear for MCE toggle.).
A revised version of console PM support follows next.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 5a50a01bf0 (sh-sci / PM: Use power.irq_safe, from
Rafael J. Wysocki <rjw@sisk.pl>, 2011-08-24).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 048be431e4 (sh-sci / PM: Avoid deadlocking runtime
PM, from Rafael J. Wysocki <rjw@sisk.pl>, 2012-03-09).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_SUN method provides the slot unique-ID in the ACPI namespace. And The value
is written in Advanced Configuration and Power Interface Specification as
follows:
"The _SUN value is required to be unique among the slots ofthe same type.
It is also recommended that this number match the slot number printed on
the physical slot whenever possible."
So if we can know the value, we can identify the physical position of the
slot in the system.
The patch creates "sun" file in sysfs for identifying physical position
of the slot.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The code is checkpatch clean, and the logic and flow looks good to me,
so I don't think there's anything left to do here.
Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Cc: Jens Taprogge <jens.taprogge@taprogge.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
as CONFIG_HOTPLUG is always enabled now, just remove the #ifdef logic in
the ipack core for it if was disabled.
Cc:Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Cc: Jens Taprogge <jens.taprogge@taprogge.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
with the last detached port state file remaining, usbip reports error on
attaching. So clean up the state files on detaching.
Signed-off-by: Harvey Yang <harvey.huawei.yang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is a Chinese translated version of
Documentation/arm/kernel_user_helpers.txt
Signed-off-by: Fu Wei <tekkamanninja@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
inode->i_private is promised to be NULL on allocation, no need to set it
explicitly.
Signed-off-by: Yan Hong <clouds.yan@gmail.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Probably due to copy&paste, some stuff was simply forgotten.
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No power transitioning from D3 state up to a non-D0 state is allowed
so make acpi_device_set_power() fail and complain if such a transition
is attempted.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The old parameter "port" is useless for phy notify, as one usb
phy is only for one usb port. New parameter "speed" stands for
the device's speed which is on the port, this "speed" parameter
is needed at some platforms which will do some phy operations
according to device's speed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At commit 925aa46ba9, Richard Zhao
<richard.zhao@freescale.com> adds the phy notification callback
when port change occurs. In fact, this phy notification should
be added according to below rules:
1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during high speed host mode.
2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during the reset and speed negotiation period.
3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during host suspend/resume sequence.
Please refer: i.mx23RM(page: 413) for below rules.
http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf
Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not
need to follow the 3rd rule) need to follow above rules.
Current code set connect notification (HW_USBPHY_CTRL.ENHOSTDISCONDETECT)
at hub_port_connect_change, it conflicts with above the 2th rule.
The correct notification setting method should be:
1. Set connect notify after the second bus reset.
2. Set disconnect notify after disconnection.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As phy is working, re-init phy may cause unexpected results
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The real reason causes mx23 fail are:
- Calling mxs_phy_hw_init(mxs_phy) again at connection
- Error connect/disconnect nodity at hub.c
The coming patch will fix above two problems, Mike Thompson
tested his hardware works OK after commented out this delay
setting.
This reverts commit 363366cf61.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some devices (ex Nokia C7) simply don't respond at all when data is sent
to some of their USB interfaces. The data gets stuck in the TTYs queue
and sits there until close(2), which them blocks because closing_wait
defaults to 30 seconds (even though the fd is O_NONBLOCK). This is
rarely desired. Implement the standard mechanism to adjust closing_wait
and let applications handle it how they want to.
See also 02303f7337 for usb_wwan.c.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Aleksander Morgado <aleksander@gnu.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch ignores auxiliary HP Lights-Out (iLO) management controllers.
All HP iLO controllers that have had the PCI subsystem device ID set to 0x1979
by the BIOS are ignored. Also changes default number of channels to 16 and
bumps the version of the module from 1.3 to 1.4.
Signed-off-by: Mark Rusk <mark.rusk@hp.com>
----
drivers/misc/hpilo.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need to include MFD_CORE if this option is enabled, otherwise we get
build errors.
Cc: Wei WANG <wei_wang@realsil.com.cn>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Realtek PCI-E Memstick card host driver is used to access Memstick
card, with the help of Realtek PCI-E card reader MFD driver.
Signed-off-by: Wei WANG <wei_wang@realsil.com.cn>
Acked-by: Alex Dubov <oakad@yahoo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Realtek PCI-E SD/MMC card host driver is used to access SD/MMC card,
with the help of Realtek PCI-E card reader MFD driver.
Signed-off-by: Wei WANG <wei_wang@realsil.com.cn>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If uio_pdrv[_genirq] is used, the uio maps have currently no name set.
This patch sets the uio_mem name to the name of the memory resource.
Signed-off-by: Manuel Traut <manut@linutronix.de>
Reported-by: Stefan Staedtler <stefan.staedtler@siemens.com>
Tested-by: Stefan Staedtler <stefan.staedtler@siemens.com>
Signed-off-by: "Hans J. Koch" <hjk@hansjkoch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
convert at91sam9g20ek with wm8731 to device tree support
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unneeded code with the new method of dai and pcm register
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
change the method for register dai and pcm
- let the atmel-ssc-dai no longer as a standalone platform device
- remap ssc and then register dai directly
- register pcm from dai directly
- modify the code which related with this change
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
To be sure, the TTY buffers (and later some stuff) are gone along with
the tty_port, we have to call tty_port_destroy at tear-down places.
This is mostly where the structure containing a tty_port is freed.
This patch does exactly that -- put tty_port_destroy at those places.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
This one is special as we need more work to be done. Previously,
the tty_port was initialized at module load time, but to be able to
destroy the port and init it again, we now do the initialization in
probe and destroy in remove. I.e. at more appropriate places for that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue.
Those using refcounting are safe now, but for those which do not we
introduce a function to be called right before the tty_port is freed
by the drivers.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
Here it is enough to switch to refcounting in tty_port.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
Here it is enough to switch to refcounting in tty_port.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty from struct sdio_uart_port is unused. Proper refcounted tty in
tty_port->tty is used instead. So remove the member from that
structure.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
Here it is enough to switch to refcounting in tty_port.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit "TTY: move tty buffers to tty_port", the tty buffers are
not freed in some drivers. This is because tty_port_destructor is not
called whenever a tty_port is freed. This was an assumption I counted
with but was unfortunately untrue. So fix the drivers to fulfil this
assumption.
PTY is one of those, here we just need to use tty_port_put instead of
kfree. (Assuming tty_port_destructor does not need port->ops to be set
which we change here too.)
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Do not access unsafe port->tty pointer when we have a safe tty
already. Use the safe one.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With hotpluggable and memoryless nodes, it's possible that node 0 will
not be online, so use the first online node's zonelist rather than
hardcoding node 0 to pass a zonelist with all zones to the oom killer.
Signed-off-by: David Rientjes <rientjes@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We had introduced acpi_hotmem_initialized to avoid strange add_memory fail
message. But the memory device may not be used by the kernel, and the
device should be bound when the driver is being loaded. Remove
acpi_hotmem_initialized to allow that the device can be bound when the
driver is being loaded.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch performs a small cleanup tty/Serial/Kconfig file by removing
unneeded ARCH dependencies. This dependencies already included in
board/type symbols.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We eject the memory device even if it is in use. It is very dangerous,
and it will cause the kernel to be panicked.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If acpi_memory_enable_device() fails, acpi_memory_enable_device() will
return a non-zero value, which means we fail to bind the memory device to
this driver. So we should free memory device before
acpi_memory_device_add() returns.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
