| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The ftm_clockevent_init passes the value of "~0UL" into a function
that takes a 32-bit argument, which drops the upper 32 bits, as
gcc warns about on ARM64:
clocksource/fsl_ftm_timer.c: In function 'ftm_clockevent_init':
clocksource/fsl_ftm_timer.c:206:13: warning: large integer implicitly truncated to unsigned type [-Woverflow]
This was obviously unintended behavior, and is easily avoided by
using '~0u' as the integer literal, because that is 32-bit wide
on all architectures.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: [email protected]
Cc: Xiubo Li <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Stefan Agner <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Link: http://lkml.kernel.org/r/3990834.xnjhm37Grs@wuerfel
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Currently it's assumed that firmware exports only the class of sensors
supported by the driver. However with newer firmware or SCPI protocol
revision, support for newer classes of sensors can be present.
The driver fails to probe with the following warning if an unsupported
class of sensor is encountered in the firmware.
sysfs: cannot create duplicate filename
'/devices/platform/scpi/scpi:sensors/hwmon/hwmon0/'
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:31
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u12:0 Not tainted 4.3.0-rc7 #137
Hardware name: ARM Juno development board (r0) (DT)
Workqueue: deferwq deferred_probe_work_func
PC is at sysfs_warn_dup+0x54/0x78
LR is at sysfs_warn_dup+0x54/0x78
This patch fixes the above issue by skipping through the unsupported
class of SCPI sensors.
Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors")
Fixes: ea98b29a05e9 ("hwmon: Support sensors exported via ARM SCP interface")
Cc: Guenter Roeck <[email protected]>
Reviewed-by: Punit Agrawal <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
|
|
The newly added scpi thermal support is broken when the scpi driver
is built-in but the thermal driver is a loadable module:
drivers/built-in.o: In function `scpi_hwmon_probe':
(.text+0x444d70): undefined reference to `thermal_zone_of_sensor_unregister'
(.text+0x444d94): undefined reference to `thermal_zone_of_sensor_register'
drivers/built-in.o: In function `scpi_hwmon_remove':
(text+0x444e6c): undefined reference to `thermal_zone_of_sensor_unregister'
This uses the same Kconfig trick that we have in a couple of other
drivers already to ensure we can only select the driver in valid
configurations when either THERMAL_OF is disabled, or when with a
dependency on CONFIG_THERMAL that can force SCPI to be a loadable
module in the case I was hitting.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors")
Signed-off-by: Guenter Roeck <[email protected]>
|
|
Similar to XFS warn when mounting DAX while it is still considered under
development. Also, aspects of the DAX implementation, for example
synchronization against multiple faults and faults causing block
allocation, depend on the correct implementation in the filesystem. The
maturity of a given DAX implementation is filesystem specific.
Cc: <[email protected]>
Cc: "Theodore Ts'o" <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: [email protected]
Cc: Kirill A. Shutemov <[email protected]>
Reported-by: Dave Chinner <[email protected]>
Acked-by: Jan Kara <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
The DEVICE_HWI type was added under the faulty assumption that Huawei
devices based on Qualcomm chipsets and firmware use the static USB
interface numbering known from Gobi devices. But this model does
not apply to Huawei devices like the HP branded lt4112 (Huawei me906e).
Huawei firmwares will dynamically assign interface numbers. Functions
are renumbered when the firmware is reconfigured.
Fix by changing the DEVICE_HWI type to use a simplified version
of Huawei's subclass + protocol scheme: Blacklisting known network
interface combinations and assuming the rest are serial.
Reported-and-tested-by: Muri Nicanor <[email protected]>
Tested-by: Martin Hauke <[email protected]>
Cc: <[email protected]>
Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem")
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
|
|
Shmobile is all multiplatform these days, so get rid of the reference to
CONFIG_ARCH_SHMOBILE_MULTI.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
|
|
otg_dev->extcon was referenced before otg_dev was initialized. Fix.
Cc: <[email protected]> # v4.3
Fixes: a2fd2423240f ("usb: phy: omap-otg: Replace deprecated API of extcon")
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Aaro Koskinen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
There is a bit of a mess in the order of arguments to the ulpi write
callback. There is
int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
in drivers/usb/common/ulpi.c;
struct usb_phy_io_ops {
...
int (*write)(struct usb_phy *x, u32 val, u32 reg);
}
in include/linux/usb/phy.h.
The callback registered by the musb driver has to comply to the latter,
but up to now had "offset" first which effectively made the function
broken for correct users. So flip the order and while at it also
switch to the parameter names of struct usb_phy_io_ops's write.
Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
PCI IDs for Broxton based platforms.
Signed-off-by: Heikki Krogerus <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Change-Id: I93a861cd6707f7d91672b9e19757cc50008cd7a2
Signed-off-by: Chunming Zhou <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
We need to clear parser.ibs and num_ibs before amd_sched_fence_create,
otherwise the IB could be freed twice if fence creates fails.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Chunming Zhou <[email protected]>
|
|
Before this patch the scheduler fence was created when we push the job
into the queue, so we could only get the fence after pushing it.
The mutex now was necessary to prevent the thread pushing the jobs to
the hardware from running faster than the thread pushing the jobs into
the queue.
Otherwise the thread pushing jobs into the queue would have accessed
possible freed up memory when it tries to get a reference to the fence.
So what you get in the end is thread A:
mutex_lock(&job->lock);
...
Kick of thread B.
...
mutex_unlock(&job->lock);
And thread B:
mutex_lock(&job->lock);
....
mutex_unlock(&job->lock);
kfree(job);
I'm actually not sure if I'm still up to date on this, but this usage
pattern used to be not allowed with mutexes. See here as well
https://lwn.net/Articles/575460/.
v2: remove unrelated changes, fix missing owner
v3: rebased, add more commit message
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
The code was correct, but getting two references when the ownership
is linearly moved on is a bit awkward and just overhead.
Signed: Christian König <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
OGL needs these tracepoints to investigate performance issue.
Change-Id: I5e58187d061253f7d665dfce8e4e163ba91d3e2b
Signed-off-by: Chunming Zhou <[email protected]>
|
|
Change-Id: I925c15015390113f7e27746ec5751eaa6a92c2a7
Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
Set reversed bit to enable/disable thermal interrupt.
Signed-off-by: Rex Zhu <[email protected]>
Reviewed-by: Jammy Zhou <[email protected]>
|
|
The amdgpu driver has a debugfs interface that shows the amount of
VRAM in use, but the newly added code causes a build error on
all 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1076:17: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=]
This fixes the format string to use "%llu" for printing 64-bit
numbers, which works everywhere, as long as we also cast to 'u64'.
Unlike atomic64_t, u64 is defined as 'unsigned long long' on
all architectures.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: a2ef8a974931 ("drm/amdgpu: add vram usage into debugfs")
Signed-off-by: Alex Deucher <[email protected]>
|
|
There was a typo in the original.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92865
Signed-off-by: Maxim Sheviakov <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
The VM default page (used when a VM translation fails) is allocated in
system memory. The VM is misconfigured to interpret the physical address
as referencing a VRAM physical page.
Route default page accesses to system memory.
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Jay Cornwall <[email protected]>
Cc: <[email protected]> # v4.2+
Signed-off-by: Alex Deucher <[email protected]>
|
|
Avoids spew on resume for systems where sysfs may
fail even on init.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=106851
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
No need any more to allocate that structure dynamically, just put it on the
stack. This is a start to cleanup some of the scheduler fallouts.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Junwei Zhang <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
Fixing a memory leak when the scheduler is enabled.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Junwei Zhang <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
Change-Id: I45bb8ff10ef05dc3b15e31a77fbcf31117705f11
Signed-off-by: Chunming Zhou <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
Change-Id: I5ad8dd156ccf27a6f18004aa0a215a0925b6e67b
Signed-off-by: Chunming Zhou <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
Change-Id: If44b8057741c78208f1976f60f31b535c944d0bd
Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Jammy Zhou <[email protected]>
|
|
Just cleanup the function parameters.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Chunming Zhou <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
v2: remove superfluous check
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (v1)
Reviewed-by: Chunming Zhou <[email protected]>
|
|
Less overhead than a work item and also adds proper cleanup handling.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Chunming Zhou <[email protected]>
Acked-by: Alex Deucher <[email protected]>
|
|
Mostly unused and replaced by the common trace points.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Chunming Zhou <[email protected]>
Acked-by: Alex Deucher <[email protected]>
|
|
Change-Id: I6d138306a878450e5bf8a77a2f1aacc380a39fe5
Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
No use bothering users about this for whom we disable write-combining for
other reasons anyway.
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
They reportedly cause random GPU hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
Reviewed-by: Christian König <[email protected]>
Cc: [email protected]
Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
After Damien's D3 fix I started to get runtime suspend residency for the
first time and that revealed a breakage on the set_caching IOCTL path
that accesses the HW but doesn't take an RPM ref. Fix this up.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Cc: [email protected]
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jani Nikula <[email protected]>
|
|
When we set and later readback a frequency value through
sysfs interface, igt/pm_rpm assumes that we get same value back
if it matches hw granularity.
On bxt we have found out that this is not always the case.
Currently frequency - hw ratio - frequency conversions round down,
with few exceptions on platforms that have more specific conversions.
On bxt the supported range can be for example from 100Mhz to 650Mhz.
Midpoint is then calculated by test to be 375 which pm_rps uses to find a
closest hw supported frequency. That is 366 (ratio 22),
which it then writes back. But as the rounding down kicks in,
driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.
Fix this by rounding to closest instead of rounding down in
freq-ratio-freq conversions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
Testcase: igt/pm_rps/basic-api
Tested-by: Bob Paauwe <[email protected]>
Cc: Bob Paauwe <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Reviewed-by: Bob Paauwe <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jani Nikula <[email protected]>
|
|
The Honeywell HGI80 is a wireless interface to the evohome connected
thermostat. It uses a TI 3410 USB-serial port.
Signed-off-by: David Woodhouse <[email protected]>
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
|
|
Also known as Verizon U620L.
The device is modeswitched from 1410:9020 to 1410:9022 by selecting the
4th USB configuration:
$ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4
This configuration provides a ECM interface as well as TTYs ('Enterprise
Mode' according to the U620 Linux integration guide).
Signed-off-by: Aleksander Morgado <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
|
|
It seems like this device has same vendor and product IDs as G2K
devices, but it has different number of interfaces(4 vs 5) and also
different interface layout which makes it currently unusable:
usbcore: registered new interface driver qcserial
usbserial: USB Serial support registered for Qualcomm USB modem
usb 2-1.2: unknown number of interfaces: 5
lsusb output:
Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05c6 Qualcomm, Inc.
idProduct 0x9215 Acer Gobi 2000 Wireless Modem
bcdDevice 2.32
iManufacturer 1 Quectel
iProduct 2 Quectel LTE Module
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 209
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Signed-off-by: Petr Štetiar <[email protected]>
Cc: stable <[email protected]>
[johan: rename define and add comment ]
Signed-off-by: Johan Hovold <[email protected]>
|
|
Unsurprisingly macbooks have backlights, just the VBT doesn't seem to
know it in this case.
Reported-and-tested-by: Daniel Nicoletti <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325
Fixes: c675949ec58c ("drm/i915: do not setup backlight if not available according to VBT")
Cc: [email protected] # v3.15+
Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Let's set crtc_y to 0 instead of setting src_y twice.
Multiple assignments in one statement is a good way to hide bugs.
Please don't do that.
Cc: Maarten Lankhorst <[email protected]>
Fixes: be5651f2d581 ("drm/i915: Update missing properties in find_initial_plane_obj")
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jani Nikula <[email protected]>
|
|
In order to allow panic actions to be processed, the ipmi watchdog
driver sets a new timeout value on panic. The 255s timeout
was designed to allow kdump and others actions on panic, as in
http://lkml.iu.edu/hypermail/linux/kernel/0711.3/0258.html
This is counter-intuitive for a end-user who sets watchdog timeout
value to something like 30s and who expects BMC to reset the system
within 30s of a panic.
This commit allows user to configure the timeout on panic.
Signed-off-by: Jean-Yves Faye <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
|
|
There is no known user, therefore remove the code.
Acked-by: Rob Van Der Heij <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Passes mlock2-tests test case in 64 bit and compat mode.
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
./arch/mips/include/asm/page.h:204:13: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
The default value of ARCH_PFN_OFFSET is 0 thus triggering this warning
for all platforms using the default value.
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Remove dead code, since this could only happen on a 31 bit machine
where the kernel wouldn't IPL.
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
commit 1f6b83e5e4d3 ("s390: avoid z13 cache aliasing") checks for the
machine type to optimize address space randomization and zero page
allocation to avoid cache aliases.
This check might fail under a hypervisor with migration support.
z/VMs "Single System Image and Live Guest Relocation" facility will
"fake" the machine type of the oldest system in the group. For example
in a group of zEC12 and Z13 the guest appears to run on a zEC12
(architecture fencing within the relocation domain)
Remove the machine type detection and always use cache aliasing
rules that are known to work for all machines. These are the z13
aliasing rules.
Suggested-by: Christian Borntraeger <[email protected]>
Reviewed-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
The iommu-dma layer does its own size-alignment for coherent DMA
allocations based on IOMMU page sizes, but we still need to consider
CPU page sizes for the cases where a non-cacheable CPU mapping is
created. Whilst everything on the alloc/map path seems to implicitly
align things enough to make it work, some functions used by the
corresponding unmap/free path do not, which leads to problems freeing
odd-sized allocations. Either way it's something we really should be
handling explicitly, so do that to make both paths suitably robust.
Reported-by: Yong Wu <[email protected]>
Signed-off-by: Robin Murphy <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
|
|
The selftest passes on 64-bit LE and 32-bit BE.
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Fix the following "maybe used uninitialized" warnings by
initializing the variables to keep the compiler quiet.
There is no "used uninitialized" in this case.
CC [M] drivers/hwmon/applesmc.o
drivers/hwmon/applesmc.c: In function ‘applesmc_init_smcreg’:
drivers/hwmon/applesmc.c:595:43: warning: ‘right_light_sensor’
may be used uninitialized in this function [-Wmaybe-uninitialized]
s->num_light_sensors = left_light_sensor + right_light_sensor;
^
drivers/hwmon/applesmc.c:540:26: note: ‘right_light_sensor’ was
declared here
bool left_light_sensor, right_light_sensor;
^
drivers/hwmon/applesmc.c:595:43: warning: ‘left_light_sensor’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
s->num_light_sensors = left_light_sensor + right_light_sensor;
^
drivers/hwmon/applesmc.c:540:7: note: ‘left_light_sensor’ was
declared here
bool left_light_sensor, right_light_sensor;
^
Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
|
|
Since a0de56c81fcf ("hwmon: (ina2xx) convert driver to using regmap")
the driver requires REGMAP_I2C to build. Select it by default
in Kconfig.
Reported-by: Guo Chunrong <[email protected]>
Cc: Marc Titinger <[email protected]>
Signed-off-by: Li Yang <[email protected]>
Fixes: a0de56c81fcf ("hwmon: (ina2xx) convert driver to using regmap")
Signed-off-by: Guenter Roeck <[email protected]>
|