The midlayer logging already prints the cdb details if the logging
level is high enough, no need to duplicate this in the ch driver.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: James Bottomley <JBottomley@Parallels.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
We should only try to evaluate the cdb if this is an ATAPI
device, for any other device the 'cdb' field and the cdb_len
has no meaning.
Fixes: cbba5b0ee4
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Tejun Heo <tj@kernel.org>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Debugging eMMC on upstream kernels it has been noticed that when the
targetpack configures MMC0 clock to 200Mhz (required to switch to
HS200) then everything works OK. However if the kernel sets the
clock rate using clk_set_rate, then the eMMC card initialisation
fails with timeouts. Lower clock speeds (the default being 50Mhz)
work ok, but they we fail to get good eMMC transfer rates.
Looking through the vendor kernel clock driver reveals Giuseppe
had already fixed this issue, but the patch hasn't made its way
upstream.
The issue is fixed by changing the logic to manage the pdiv and
fdiv divisors used for setting the rate inside the flexgen driver code.
Pdiv is mainly targeted for low freq results, while fdiv should be
used for divs =< 64. The other way can lead to 'duty cycle'
issues.
I have changed the original patch to keep the original behaviour
in cases where the div is >64 which matches the original comment
and patch description more closely. Although no clocks appear to hit
this case currently when booting an upstream kernel.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Freescale introduced new ARM-based socs which using the compatible
clock IP block with PowerPC-based socs'. So this driver can be used
on both platforms.
Updated relevant descriptions and renamed this driver to better
represent its meaning and keep the function of driver untouched.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
redefine variable clocks_per_pll as a struct member
If there are multiple PLL clock nodes, this variable will
get overwritten. Redefining it as a struct member can avoid that.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The clocks on ti81xx are not compatible with omap3. On dm816x
the clock source is a FAPLL (Flying Adder PLL), and on dm814x
there seems to be an APLL (All Digital PLL).
Let's fix up things for dm816x in preparation for adding the
FAPLL support. As we already have a dummy ti81xx_dt_clk_init()
in place, let's use that for now to avoid adding a dependency
to the omap patches.
Later on if somebody adds dm814x support we can split the
ti81xx_dt_clk_init() clock init function as needed.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
On dm816x the clocks are sourced from a FAPLL (Flying Adder PLL)
that does not seem to be used on the other omap variants.
There are four instances of the FAPLL on dm816x that each have three
to seven child synthesizers.
I've set up the FAPLL as a single fapll.c driver. Later on we could
potentially have the PLL code generic. To do that, we would have to
consider the following:
1. Setting the PLL to bypass mode also sets the child synthesizers
into bypass mode. As the bypass rate can also be generated by
the PLL in regular mode, there's no way for the child synthesizers
to detect the bypass mode based on the parent clock rate.
2. The PLL registers control the power for each of the child
syntheriser.
Note that the clocks are currently still missing the set_rate
implementation so things are still running based on the bootloader
values. That's OK for now as most of the outputs have dividers and
those can be set using the existing TI component clock code.
I have verified that the extclk rates are correct for a few clocks,
so adding the set_rate support should be fairly trivial later on.
This code is partially based on the TI81XX-LINUX-PSP-04.04.00.02
patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
We don't need to fetch the parent index for clocks if they only
have one parent. Doing this also avoid an unnecessary allocation
for the parent cache.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
should be no higher than 15, however the corresponding check is obviously off-
by-one.
Fixes: 045779942c ("clk: gate: add CLK_GATE_HIWORD_MASK")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
In order to fix the following section mismatch warning:
WARNING: drivers/clk/built-in.o(.data+0xe4): Section mismatch in reference from the variable ppc_corenet_clk_driver to the function .init.text:ppc_corenet_clk_probe()
The variable ppc_corenet_clk_driver references
the function __init ppc_corenet_clk_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
WARNING: drivers/clk/built-in.o(.data+0x10c): Section mismatch in reference from the variable ppc_corenet_clk_driver to the variable .init.rodata:ppc_clk_ids
The variable ppc_corenet_clk_driver references
the variable __initconst ppc_clk_ids
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
We can't just add the __init annotation to ppc_corenet_clk_driver or
remove the __init from ppc_corenet_clk_probe() and ppc_clk_ids.
So choose to use CLK_OF_DECLARE to scan and init the clock devices.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Acked-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The gic_send_sgi() function used hardcoded bit shift values to
generate the ICC_SGI1R_EL1 register value.
Replace this with symbolic names to allow reusing them later.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
On the A80 SoC, the 4 mmc controllers each have a separate register
controlling their register access clocks and reset controls. These
registers in turn share a ahb clock gate and reset control.
This patch adds a platform device driver for these controls. It
requires both clocks and reset controls to be available, so using
CLK_OF_DECLARE might not be the best way.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tools like hwclock attempt to enable the RTC update interrupt (UIE) to
maximize the accuracy of the reported time value. The EFI rtc does not
have interrupt capability so this is a pointless exercise to begin with,
but the generic RTC framework ends up issuing a SetWakeupTime() Runtime
Services call before drawing that conclusion on its own.
Instead, we can mark UIE as unsupported at driver probe time. The net
result is the same, but without the spurious SetWakeupTime() call.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Add new driver for Maxim 77693 switch-mode charger (part of max77693
MFD driver) providing power supply class information to userspace.
The charger has +20V tolerant input. Current input can be set from 0 to
2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
the system (when supplying additional current from battery to system).
The driver is configured through DTS (battery and system related
settings) and sysfs entries (timers and top-off charging threshold).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The driver mismatched 'num_supplicants' with 'num_supplies' of
power_supply structure.
It provided list of supplicants (power_supply.supplied_to) but did
not set the number of supplicants. Instead it set the num_supplies which
is used when iterating over number of supplies (power_supply.supplied_from).
As a result the list of supplicants was ignored by core because its size
was 0.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Teach collie_battery driver to communicate to the kernel that it can
generate wakeup events. Handle enabling/disabling wakeup on battery full
event in suspend/resume callbacks.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to
generate the wakeup event (and thus resume should call disable_irq_wake).
Currently gpio-charger driver has this logic inverted. Correct that thus
correcting enable/disable_irq_wake() calls balance.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This patch adds device driver of Richtek PMIC.
The driver support battery fuel gauge. Fuel gauge calculates and determines the
battery state of charge (SOC) according to battery open circuit voltage (OCV).
Also, this driver provides battery average voltage, voltage and battery present
property.
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Currently the ltc2952 supports only one button sequence to initiate
powerdown. This is not always desirable, as even prolonged button
presses can happen in use.
Allow ltc2952 users to pick their own power down sequence, by making the
trigger input optional. Since this still means that the ltc2952 may
power down the platform if the power button is pressed for about 5
seconds, we still need to make sure to start the watchdog toggle to
prolong the system power for as long as we need it.
This will still allow the system to control power using the kill signal.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In ltc2952_poweroff_handler it is theoretically possible that the timer
fails to start on first pass (button press), but succeeds in starting on
the second (button release). This will cause the button press to be
misinterpreted, and will incorrectly shut down the system. Because a
picture says more than a thousand words:
Expected behavior:
tmr: ++++++++++
btn: -----__________-----
Faulty behavior:
tmr: +++++
btn: -----__________-----
Legend:
+ timer runs
_ button pressed
- button depressed
To prevent this from happening, check the value of the gpio before
starting the timer. If the button is active, we should start the timer,
else we should stop it.
The situation described can now still occur if the polarity of the input
pin is set incorrectly, but that at least is predictable behavior and
can be detected during the first tests.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Disable the timers when ltc2952_poweroff is removed. We don't want to
risk calling functions on data that no longer exist.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The function pointers for the timers and pm_power_off are assigned with
C++ style
foo = &func;
Let's change it instead to the more C style
foo = func;
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
ltc2952_poweroff_handler uses gotos to return from the function. Since
we don't do cleanups exiting this function, just return IRQ_HANDLED on
the spot and be done with it.
While at it, remove the variable 'ret'. It was never used very much.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Documentation/SubmittingDrivers suggests these be implemented even when
they do nothing. On the other hand, the platform code calls these
functions 'legacy'. Suspend and resume operations should go into a
pm_ops structure, pointed at by the driver's pm field. This approach
would lead to a lot of boiler plate, while achieving nothing. Drop the
functions instead.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
As per Documentation/CodingStyle ch.4, we should keep global variables
to a mininum. Move the panic state into the driver data, regardless of
whether panic is a system state or not.
This removes the need for the custom _init and _exit functions, so
replace them with a call to the module_platform_driver() macro.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Documentation/CodingStyle ch.4 mentions in a side node that global
variables should only be used if you really need them. Reduce the use of
the global instance of ltc2952_poweroff so we may eventually remove it
entirely.
While at it, rename ltc2952_poweroff_data to ltc2952_poweroff, just to
save that little bit of typing.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The three gpio's used by this driver are stored in an array of pointers.
This doesn't add much besides cleanups in a loop. In fact, it makes most
of the usage sites harder to read. Unroll the loop, and live with the
fact that cleanups become slightly larger.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Make use of the fact that we allocated resources can be automatically
deallocated. This reduces cleanup code and chance of errors. It also
removes the need for the virq member of the ltc2952_poweroff_data
struct.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Make use of the fact that the allocated resources can be automatically
deallocated. This reduces cleanup code and chance of leaks.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In order to be able to move the stats increment from can_bus_off() into
can_change_state(), the increment had to be moved back into code that was using
can_bus_off() but not can_change_state().
As a side-effect, this patch fixes the following bugs:
* Redundant call to can_bus_off() in c_can.
* Bus-off counted twice in xilinx_can.
Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.
Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.
Cc: <stable@vger.kernel.org> # v3.16+
Fixes: 730876be25 ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
[Lee: Removed newly unused variable]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
STATUS register can be modified by the HW, so we
should bypass cache because of that.
In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Allow multiple DA9052 regulators be registered by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when multiple regulators
are registered:
[ 0.128855] da9052-regulator da9052-regulator: invalid regulator ID specified
[ 0.128973] da9052-regulator: probe of da9052-regulator failed with error -22
[ 0.129148] ------------[ cut here ]------------
[ 0.129200] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x7c()
[ 0.129233] sysfs: cannot create duplicate filename '/devices/platform/soc/60000000.aips/63fc8000.i2c/i2c-0/0-0048/da9052-regulator
...
[ 0.132891] ------------[ cut here ]------------
[ 0.132924] WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 kobject_add_internal+0x24c/0x2cc()
[ 0.132957] kobject_add_internal failed for da9052-regulator with -EEXIST, don't try to register things with the same name in the same directory.
...
[ 0.137000] da9052 0-0048: mfd_add_devices failed: -17
[ 0.138486] da9052: probe of 0-0048 failed with error -17
Based on the fix done by Johan Hovold at commit b668422872 ("mfd:
viperboard: Fix platform-device id collision").
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
