| Age | Commit message (Collapse) | Author |
|---|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from sc520 driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from s3c24xx driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from qoirq driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from pxa driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from ppc_cbe driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from powernow driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from p4-clockmod driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from mediatek driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from longhaul driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from ia64-acpi driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from elanfreq driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from e_powersaver driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from cpufreq-dt driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from brcmstb driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from arm_big_little driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table in the acpi-cpufreq driver.
The driver needs to crosscheck if the max frequency corresponds to the
P-state 0 or not and the same is done from the ->ready() callback now.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The cpufreq table is already validated by the cpufreq core and none of
the users of cpufreq_generic_init() have any dependency on it to
validate the table as well.
Don't validate the cpufreq table anymore from cpufreq_generic_init().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This is a preparatory commit to make policy->suspend_freq independent of
validation of the cpufreq table, as a later commit would update
cpufreq_generic_init() to not validate the cpufreq table any longer.
The driver already assumes the order in which the frequency table is
sorted and we can get the max frequency easily.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
GPMI driver timings derivation looks very empirical and does not use
the known timings that the core wants to use with the NAND chip, by
using local defined constants that have no special meaning from the
outside world.
Simplify the way all of this is computed and use the NAND core's SDR
timings.
Integrity of the reads/writes has been checked with nandbiterrs, speed
improvements with flash_speed on a Freescale i.MX6 DualLite/Solo SABRE
Automotive Board. Measures are below, variations of less than 150kiB/s
between tests are common and then not significant. Speeds using mode 5
are the same, while speeds using mode 0 are quite improved (+40/50%
from non-optimal computation).
Forcing timings mode 0:
=======================
Before this patch:
------------------
eraseblock write speed is 2298 KiB/s
eraseblock read speed is 3636 KiB/s
page write speed is 2136 KiB/s
page read speed is 3316 KiB/s
2 page write speed is 2199 KiB/s
2 page read speed is 3468 KiB/s
After this patch:
-----------------
eraseblock write speed is 3232 KiB/s
eraseblock read speed is 5663 KiB/s
page write speed is 2915 KiB/s
page read speed is 4904 KiB/s
2 page write speed is 3084 KiB/s
2 page read speed is 5267 KiB/s
Forcing timings mode 5:
=======================
Before this patch:
------------------
eraseblock write speed is 4338 KiB/s
eraseblock read speed is 14883 KiB/s
page write speed is 3786 KiB/s
page read speed is 12800 KiB/s
2 page write speed is 4076 KiB/s
2 page read speed is 14065 KiB/s
After this patch:
-----------------
eraseblock write speed is 4309 KiB/s
eraseblock read speed is 14712 KiB/s
page write speed is 3764 KiB/s
page read speed is 12673 KiB/s
2 page write speed is 4076 KiB/s
2 page read speed is 14065 KiB/s
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
Until now the GPMI driver had its own timings logic while the core
already handles that and request the NAND controller drivers to support
the ->setup_data_interface() hook. Implement that hook by reusing the
already existing function. No real glue is necessary between core timing
delays and GPMI registers because the driver already translates the
ONFI timing modes into register values.
Make use of the core's tREA, tRLOH and tRHOH values that allow computing
more precise timings for mode [0-3] and get significantly better values
(+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.
Now that there is a small nand_parameters structure that hold all needed
ONFI parameters, remove the ONFI page from the nand_chip structure by
just allocating it during the identification phase and removing it right
after.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.
Now that there is a small nand_parameters structure that can held
generic parameters, remove the JEDEC page from the nand_chip structure
by just allocating it during the identification phase and removing it
right after.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
The MX30LF2G18AC chip declares in its parameter page supporting
SET/GET_FEATURES but when it comes to timings, experience shows that it
is not the case.
Unflag this feature for this particular chip in the nand_parameters
structure to avoid unnecessary errors and downturns.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
If SET/GET_FEATURES is available (from the parameter page), use a
bitmap to declare what feature is actually supported.
Initialize the bitmap in the core to support timing changes (only
feature used by the core), also add support for Micron specific features
used in Micron initialization code (in the init routine).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.
ONFI-related parameters that will be used outside from the
identification function are stored in a separate onfi_parameters
structure embedded in nand_parameters, this small structure that
already hold generic parameters.
For now, the onfi_parameters structure is allocated statically. However,
after some deep rework in the NAND framework, it will be possible to do
dynamic allocations from the NAND identification phase, and this
strcuture will then be dynamically allocated when needed.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
If we can not get the HDMI DDC clock, we still need to free some
resources before returning.
Fixes: 939d749ad664 ("drm/sun4i: hdmi: Add support for controller hardware variants")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5e0084af4ad57e9eea3bca5bd8e2e95970cd6714.1521413031.git.christophe.jaillet@wanadoo.fr
|
|
If we can not allocate the HDMI encoder regmap, we still need to free some
resources before returning.
Fixes: 4b1c924b1fc1 ("drm/sun4i: hdmi: create a regmap for later use")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14c42391e1b562c7495bda6ad6fa1d24ec8dc052.1521413031.git.christophe.jaillet@wanadoo.fr
|
|
We want the serial/tty fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The commit "regulatory: add NUL to request alpha2" increases the length of
alpha2 to 3. This causes a regression on brcmfmac, because
brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete
array. So fix this accordingly.
Fixes: 657308f73e67 ("regulatory: add NUL to request alpha2")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
A built-in scpi cpufreq driver cannot link against a modular
thermal framework:
drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_ready':
scpi-cpufreq.c:(.text+0x4c): undefined reference to `of_cpufreq_cooling_register'
drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_exit':
scpi-cpufreq.c:(.text+0x9c): undefined reference to `cpufreq_cooling_unregister'
This adds a Kconfig dependency that makes sure this configuration
is not possible, while allowing all configurations that can work.
Note that disabling CPU_THERMAL means we don't care about the
THERMAL dependency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Kmemleak reported the below leak. When cppc_cpufreq_init went into
failure path, the cpu mask is not freed. After fix, this report is
gone. And to avaoid potential NULL pointer reference, check the cpu
value first.
unreferenced object 0xffff800fd5ea4880 (size 128):
comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s)
hex dump (first 32 bytes):
00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffff0000082c4ae4>] __kmalloc_node+0x278/0x634
[<ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60
[<ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c
[<ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c
[<ffff000008083828>] do_one_initcall+0xec/0x15c
[<ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4
[<ffff0000089099b0>] kernel_init+0x18/0x10c
[<ffff000008084d50>] ret_from_fork+0x10/0x18
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.
To prepare to the removal of such huge structure, a small NAND parameter
structure is allocated statically and contains only very few members
that are generic to all chips and actually used elsewhere in the code.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
Just like many other Samsung models, the 670Z5E needs to use the acpi-video
backlight interface rather then the native one for backlight control to
work, add a quirk for this.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1557060
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Introduce a driver for the ACPI Time and Alarm Device (TAD) based on
Section 9.18 of ACPI 6.2.
This driver only supports the system wakeup capabilities of the TAD
which are mandatory. Support for the RTC capabilities of the TAD
will be added to it in the future.
This driver is entirely sysfs-based. It provides attributes (under
the TAD platform device) to allow user space to manage the AC and DC
wakeup timers of the TAD: set and read their values, set and check
their expire timer wake policies, check and clear their status and
check the capabilities of the TAD reported by AML. The DC timer
attributes are only present if the TAD supports a separate DC alarm
timer.
The wakeup events handling and power management of the TAD is
expected to be taken care of by the ACPI PM domain attached to its
platform device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
In current design of ACPI container offline, Kernel emits
KOBJ_CHANGE uevent to user space to indidate that the ejection of
the container was triggered by platform. (caa73ea15 patch)
A pure KOBJ_CHANGE uevent is not enough for user space to identify
the purpose. For example, a "udevadm trigger" command can also
be used to emit change event to all udev rules. A udev rule can not
identify that the event is from kernel for offline or from udevadm
for other purpose. Then the offline action in udev rule may also be
triggered by udevadm tool.
So, similar to the change uevent of dock, kernel sends the
KOBJ_CHANGE uevent with a offline environmental data to indicate
purpose. It's useful by udev rule for using ENV{EVENT} filter.
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_dev_pm_get_state() is used to determine the range of allowable
device power states when going into S3 suspend. This is implemented
by executing the _S3D and _S3W ACPI methods.
Linux follows the ACPI spec behaviour in that when _S3D is implemented
and _S3W is not, Linux will not go into a power state deeper than the one
returned by _S3D for a wakeup-enabled device.
However, this same logic is being applied to the case when neither
_S3D nor _S3W are present, and the result is that this function
decides that the device must stay in D0 (fully on) state.
This is breaking USB wakeups on Asus V222GA and Acer XC-830. _S3D and
_S3W are not present, so the USB controller is left in the D0 running
state during S3, and hence it is unable to generate a PME# wake event.
The ACPI spec is unclear on which power states are permissable for
wakeup-enabled devices when both _S3D and _S3W are missing.
However, USB wakeups work fine on these platforms under Windows, where
device manager shows that they are using D3 device state for the USB
controller in S3.
I assume that the "max = min" clamping done by the code here is
specifically written for the _S3D but no _S3W case. By making the
code true to those conditions, avoiding them on these platforms,
the controller will be put into D3 state and USB wakeups start working.
Additionally I feel that this change makes the code more directly
mirror the wording of the ACPI spec and it's associated lack of clarity.
Thanks to Mathias Nyman for pointing us in the right direction.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=Bv1XhXV_gY3bziOo_NPKA@mail.gmail.com
https://phabricator.endlessm.com/T21410
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Trying quirks in usbcore needs to rebuild the driver or the entire
kernel if it's builtin. It can save a lot of time if usbcore has similar
ability like "usbhid.quirks=" and "usb-storage.quirks=".
Rename the original quirk detection function to "static" as we introduce
this new "dynamic" function.
Now users can use "usbcore.quirks=" as short term workaround before the
next kernel release. Also, the quirk parameter can XOR the builtin
quirks for debugging purpose.
This is inspired by usbhid and usb-storage.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The maximum bytes per interval for USB SuperSpeed Plus can be set by
isoc endpoint companion descriptor when it is above 48K. If the
descriptor is provided, then use its value.
USB 3.1 spec 9.6.8
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next
Kishon writes:
phy: for 4.17
*) Add USB PHY driver for MDM6600 on Droid
*) Add USB PHY driver for STM32 USB PHY Controller
*) Add inno-usb2-phy driver for hi3798cv200 SoC
*) Add combo phy driver (SATA/USB/PCIE) for HiSilicon STB SoCs
*) Add USB3 PHY driver for Meson GXL and GXM
*) Add support for R8A77965 Gen3 USB 2.0 PHY in phy-rcar-gen3-usb2 driver
*) Add support for qualcomm QUSB2 V2 and QMP V3 USB3 PHY in phy-qcom-qusb2
and phy-qcom-qmp PHY driver respectively
*) Add support for runtime PM in phy-qcom-qusb2 and phy-qcom-qmp PHY drivers
*) Add support for Allwinner R40 USB PHY in sun4i-usb PHY driver
*) Add support in rockchip-typec PHY driver to make extcon optional and
fallback to working in host mode if extcon is missing
*) Add support in rockchip-typec PHY driver to mux PHYs connected to DP
*) Add support to configure slew rate parameters in phy-mtk-tphy PHY driver
*) Add workaround for missing Vbus det interrupts on Allwinner A23/A33
*) Add USB speed related PHY modes in phy core
*) Fix PHY 'structure' documentation
*) Force rockchip-typec PHY to USB2 if DP-only mode is used
*) Fix phy-qcom-qusb2 and phy-qcom-qmp PHY drivers to follow PHY reset and
initialization sequence as per hardware programming manual
*) Fix Marvell BG2CD SoC USB failure in phy-berlin-usb driver
*) Minor fixes in lpc18xx-usb-otg, xusb-tegra210 and phy-rockchip-emmc PHY
drivers
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
intel_{alloc,free}_coherent()
Use the dma_direct_*() helpers and clean up the code flow.
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20180319103826.12853-9-hch@lst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
This cleans up the code a lot by removing duplicate logic.
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Joerg Roedel <jroedel@suse.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20180319103826.12853-8-hch@lst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The generic DMA-direct (CONFIG_DMA_DIRECT_OPS=y) implementation is now
functionally equivalent to the x86 nommu dma_map implementation, so
switch over to using it.
That includes switching from using x86_dma_supported in various IOMMU
drivers to use dma_direct_supported instead, which provides the same
functionality.
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20180319103826.12853-4-hch@lst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
These days all devices (including the ISA fallback device) have a coherent
DMA mask set, so remove the workaround.
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20180319103826.12853-3-hch@lst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
ceased to unregister SPI buses with fixed bus numbers. Moreover this is
visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register
the same SPI controller.
rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y):
[ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1]
modprobe spi_pxa2xx_platform:
[ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1'
[ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21
[ 37.902384] Call Trace:
...
[ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory.
[ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0
...
[ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master
[ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17
Fix this by not returning immediately from spi_unregister_controller() if
idr_find() doesn't find controller with given ID/bus number. It finds
only those controllers that were registered with dynamic SPI bus
numbers. Only conditional cleanup between dynamic and fixed bus numbers
is to remove allocated IDR.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
After a nand_reset_data_interface(), both the NAND chip and the NAND
controller use timing mode 0. The previously defined data interface for
this chip has been saved and is supposed to be restored after that.
However, if the saved data interface also refers to timing mode 0, there
is no need to re-apply them again.
Also, as nand_setup_data_interface() uses ->set/get_features(), it could
lead to issues when doing the reset at probe time as the parameter page
is not available yet to know if these functions are supported or not.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
Choosing ONFI timings when ->set/get_features() calls are supported
by the NAND chip is a matter of reading the chip's ONFI parameter page
and telling the chip the chosen mode (between all of the supported ones)
with ->set_feature().
Add a check on whether the chip "acked" the timing mode or not.
This can be a problem for NAND chips that do not follow entirely the
ONFI specification. These chips actually support other modes than
"mode 0", but either:
1/ do not update the timing mode register once a timing mode has been
selected.
or
2/ do not support the TIMING_MODE featured and thus do not require users
to change the timing mode at all.
These issues will be addressed in another patch that will add the
feature to overwrite NAND chips features within the parameter page, from
the NAND chip driver.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
After a ->set_features(TIMINGS), the chip is supposed to be working at a
new speed. In order for all the transactions to be perperly handled, the
NAND controller should also be configured to this same speed. Calling
->setup_data_interface() is not enough and the chip should be
de-asserted/re-asserted through calls to ->select_chip().
Prepare the next change in nand_setup_data_interface() where timings
will be checked after being applied. Because assertions of the CS pin
will be needed from within this function, move the calls to
->select_chip() inside nand_setup_data_interface() for later
consistency.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
All the calls to the chip's hooks ->get/set_features() go through
the core's wrappers nand_get/set_features() that already do the
necessary checks about feature support. Remove these
checks from the mxc's functions.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
|
Usually, the source of the error when setting/getting features does not
matter (if the controller does not support sending the command or if
the chip does not support the operation).
When it comes to timings, if the controller fails it is an error while
if the chip does not support the operation, it can be silently supposed
that it already works with the maximum supported timings.
Introduce some logic in nand_setup_data_interface() to handle that
difference.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
|
