Inline cdrom_end_request() into cdrom_newpc_intr()
and ide_cd_do_request().
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Move cdrom_end_request() calls from cdrom_decode_status()
and ide_cd_check_ireason() to cdrom_newpc_intr().
* Unify cdrom_newpc_intr() exit paths.
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Move setting REQ_FAILED flag out from 'end_request' exit path in
cdrom_newpc_intr() and also rename 'end_request' to 'out_end'.
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Move cdrom_end_request() calls from cdrom_start_rw()
and ide_cd_prepare_rw_request() to ide_cd_do_request().
* Unify ide_cd_do_request() exit paths.
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
It makes no sense to check for BSY bit being set as earlier OK_STAT()
check in cdrom_end_request() makes sure that BSY bit is cleared.
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use ide_end_rq() also for failed non-fs requests on completion
of REQUEST SENSE requests + use blk_rq_bytes() while at it.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use PageHighMem() instead of ifdefs in ide_pio_bytes()
(=> local IRQs won't be disabled when not necessary).
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Add support for arbitrary transfer lengths to ide_pio_bytes()
and then inline ide_pio_multi() into ide_pio_datablock().
There should be no functional changes caused by this patch.
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Apparently¹, some ATAPI devices want to see the packet command first
before enabling DMA otherwise they simply hang indefinitely. Reorder the
two steps and start DMA only after having issued the command first.
[1] http://marc.info/?l=linux-kernel&m=123835520317235&w=2
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
Reported-by: Michael Roth <mroth@nessie.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix some incorrect IDE_FTFLAG_* changes which slipped in commit
"ide: add "flagged" taskfile flags to struct ide_taskfile (v2)"
(commit 19710d25d5) few days ago.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
On m68k:
| drivers/ide/ide-atapi.c: In function 'ide_io_buffers':
| drivers/ide/ide-atapi.c:87: error: implicit declaration of function 'sg_page'
| drivers/ide/ide-atapi.c:87: warning: passing argument 1 of 'PageHighMem' makes pointer from integer without a cast
| drivers/ide/ide-atapi.c:91: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast
| drivers/ide/ide-atapi.c:96: error: implicit declaration of function 'sg_virt'
| drivers/ide/ide-atapi.c:96: warning: assignment makes pointer from integer without a cast
| drivers/ide/ide-atapi.c:107: error: implicit declaration of function 'sg_next'
| drivers/ide/ide-atapi.c:107: warning: assignment makes pointer from integer without a cast
[bart: Dmitri Vorobiev submitted similar patch fixing MIPS]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dmitri Vorobiev <dmitri.vorobiev@movial.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Unfortunately, I missed a catch when reviewing the patch committed as
201bffa4. Here is the fix to the currently broken handling of sleeping
devices. In particular, this is required to get the disk shock
protection code working again.
Reported-by: Christian Thaeter <ct@pipapo.org>
Cc: stable@kernel.org
Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Start a new device recognition if someone writes to sysfs online attribute
of a boxed ccw device. The current test will fail, since cu_type != 0
for devices which were recognized before.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Return -EAGAIN on writes to sysfs online attribute if the corresponding
ccw device is in transient state.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
If a ccw device did not respond in time during internal io, we set it
into boxed state. With this patch we have the following behaviour:
* the ccw driver will get a notification if the device was online and
goes into the boxed state
* if the device was disconnected and got boxed nothing special is to be
done (it will be handled in reprobing later)
* if the device got boxed while initial sensing it will be unregistered
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Introduce ccw_device_schedule_sch_unregister as a wrapper for queuing
ccw_device_call_sch_unregister on the slow_path_wq. This wrapper
will be used in the next patch.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Wake up even on failed device recognition, since this may be triggered
from a user trying to force a device online. With this patch a write
to the online sysfs attribute will not block for ever but return with
-EAGAIN in this case.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
With "cpumask: update irq_desc to use cpumask_var_t"
we get this build failure on s390:
CC drivers/char/sysrq.o
In file included from drivers/char/sysrq.c:38:
include/linux/irq.h: In function 'init_alloc_desc_masks':
include/linux/irq.h:442: error: dereferencing pointer to incomplete type
drivers/char/sysrq.c should include interrupt.h instead of irq.h.
Cc: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
At present it is not possible for machine constraints to disable
regulators which have been left on when the system starts, for example
as a result of fixed default configurations in hardware. This means that
power may be wasted by these regulators if they are not in use.
Provide intial support for this with a late_initcall which will disable
any unused regulators if the machine has enabled this feature by calling
regulator_has_full_constraints(). If this has not been called then print
a warning to encourage users to fully specify their constraints so that
we can change this to be the default behaviour in future.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Don't set use_count for regulators that are enabled at boot since this
stops the supply being disabled by well-behaved consumers which do
balanced enables and disabled. Any consumers which don't do disables
which are not matched by enables are unable to share regulators - shared
regulators are the common case so the API should facilitate them.
Consumers that want to disable regulators that are enabled when they
start have two options:
- Do a regulator_enable() prior to the disable to bring the use count
in sync with the hardware state; this will ensure that if the
regulator was enabled by another driver then this consumer will play
nicely with it.
- Use regulator_force_disable(); this explicitly bypasses any checks
done by the core and documents the inability of the driver to share
the supply.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Add VPLL2 to the set of twl4030-family regulators exposed for
use by various drivers. It's commonly used to power the digital
video outputs (e.g. LCD or DVI displays) on OMAP3 systems.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Fix some refcounting issues in the regulator framework, supporting
regulator_disable() for regulators that were enabled at boot time
via machine constraints:
- Update those regulators' usecounts after enabling, so they
can cleanly be disabled at that level.
- Remove the problematic per-consumer usecount, so there's
only one level of enable/disable.
Buggy consumers could notice different bug symptoms. The main
example would be refcounting bugs; also, any (out-of-tree) users
of the experimental regulator_set_optimum_mode() stuff which
don't call it when they're done using a regulator.
This is a net minor codeshrink.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The consumer can print a message if required, some consumers may have
optional regulators and wish to downgrade the logging for them or ignore
their absence.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Rather than incrementing the reference count for boot_on regulators
(which prevents them being disabled later on) simply force the
regulator to be enabled when applying the constraints. Previously
boot_on was essentially equivalent to always_on.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Implement the recently added voltage step listing API for the WM835x
DCDCs and LDOs. DCDCs can use values up to 0x66, LDOs can use the full
range of values in the mask. Both masks are the lower bits of the
register.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The VAUX4 voltage table scrolls onto a second page in many versions
of the TWL4030 family manuals. This doesn't mean we should ignore
those values! Some boards use the (fully supported) 2.8V setting.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Specifying voltage constraints is optional (and only needed if the
consumer is allowed to change the voltage) so don't complain unless
a voltage has been specified.
Also avoid surprises with a dangling else while we're here.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Support most of the LDO regulators in the twl4030 family chips.
In the case of LDOs supporting MMC/SD, the voltage controls are
used; but in most other cases, the regulator framework is only
used to enable/disable a supplies, conserving power when a given
voltage rail is not needed.
The drivers/mfd/twl4030-core.c code already sets up the various
regulators according to board-specific configuration, and knows
that some chips don't provide the full set of voltage rails.
The omitted regulators are intended to be under hardware control,
such as during the hardware-mediated system powerup, powerdown,
and suspend states. Unless/until software hooks are known to
be safe, they won't be exported here.
These regulators implement the new get_status() operation, but
can't realistically implement get_mode(); the status output is
effectively the result of a vote, with the relevant hardware
inputs not exposed.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Add a basic mechanism for regulators to report the discrete
voltages they support: list_voltage() enumerates them using
selectors numbered from 0 to an upper bound.
Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on this board.)
Export those voltages to the regulator consumer interface, so for
example regulator hooked up to an MMC/SD/SDIO slot can report the
actual voltage options available to cards connected there.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The WM835x regulators need a different register checking for force
mode on each DCDC. Previously the force mode status for DCDC1 was
checked.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Update the documentation to suggest the use of datasheet names for
the supplies requested by regulator consumers. Doing this makes it
easier to tie the design for a given platform up with the requirements
of the driver for a consumer.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Currently regulator_unregister does not clear regulator <--> consumer
mapping.
This patch introduces unset_regulator_supplies that clear the map.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers
to take the struct regulator_dev lock themselves which requires that the
struct be visible to them. Band aid this by making the struct visible.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This allows users to enable or disable support for these regulators at
build time as they can for other regulators rather than having platforms
force the regulators to be built in.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Rather than having the regulator init data read from the platform_data
member of the struct device that is registered for the regulator make
the init data an explict argument passed in when registering. This
allows drivers to use the platform data for their own purposes if they
wish.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Regulator: Push lock out of _notifier_call_chain and into caller functions
(side effect of fixing deadlock in regulator_force_disable)
+ Add a voltage changed event.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
