| Age | Commit message (Collapse) | Author |
|---|
|
slp_s0 counter value displayed via debugfs interface is calculated by
multiplying the granularity for crystal oscillator tick as 100us with
the value read from using slp_s0 offset. But the granularity of the tick
varies from platform to platform and it needs to be fixed.
Hence, specify granularity of the tick for each platform, so that the
value of the slp_s0 counter is accurate.
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201006224702.12697-4-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
TigerLake's LPM power gating status register has errors in the bit-to-name
mapping as well as with the marked reserved bits according to the actual
implementation. Hence, update the right bit-to-name mapping and the
reserved bits in accordance with actual implementation.
Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: David E. Box <david.e.box@intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201006224702.12697-3-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
TigerLake Lower Power Mode (LPM) registers are grouped by functionality
but were given simple enumerated names in the code (lpm0, lpm1, ...).
Instead, give the register blocks names that describe their usage.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201006224702.12697-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
We want to use the dev_* functions here rather than the pr_* variants.
Switch to using dev_warn() which mirrors what we do on other asics.
Fixes the following build errors on ARC:
../drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c: In function 'navi10_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c: In function 'sienna_cichlid_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
Reported-by: kernel test robot <lkp@intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Evan Quan <evan.quan@amd.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit c1cf79ca5ced46 ("drm/amdgpu: use IP discovery table for renoir")
introduced a NULL pointer dereference when booting with
amdgpu.discovery=0, because it removed the call of vega10_reg_base_init()
for that case.
Fix this by calling that funcion if amdgpu_discovery == 0 in addition to
the case that amdgpu_discovery_reg_base_init() failed.
Fixes: c1cf79ca5ced46 ("drm/amdgpu: use IP discovery table for renoir")
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DPAA2 (Data Path Acceleration Architecture) consists in
mechanisms for processing Ethernet packets, queue management,
accelerators, etc.
The Management Complex (mc) is a hardware entity that manages the DPAA2
hardware resources. It provides an object-based abstraction for software
drivers to use the DPAA2 hardware. The MC mediates operations such as
create, discover, destroy of DPAA2 objects.
The MC provides memory-mapped I/O command interfaces (MC portals) which
DPAA2 software drivers use to operate on DPAA2 objects.
A DPRC is a container object that holds other types of DPAA2 objects.
Each object in the DPRC is a Linux device and bound to a driver.
The MC-bus driver is a platform driver (different from PCI or platform
bus). The DPRC driver does runtime management of a bus instance. It
performs the initial scan of the DPRC and handles changes in the DPRC
configuration (adding/removing objects).
All objects inside a container share the same hardware isolation
context, meaning that only an entire DPRC can be assigned to
a virtual machine.
When a container is assigned to a virtual machine, all the objects
within that container are assigned to that virtual machine.
The DPRC container assigned to the virtual machine is not allowed
to change contents (add/remove objects) by the guest. The restriction
is set by the host and enforced by the mc hardware.
The DPAA2 objects can be directly assigned to the guest. However
the MC portals (the memory mapped command interface to the MC) need
to be emulated because there are commands that configure the
interrupts and the isolation IDs which are virtual in the guest.
Example:
echo vfio-fsl-mc > /sys/bus/fsl-mc/devices/dprc.2/driver_override
echo dprc.2 > /sys/bus/fsl-mc/drivers/vfio-fsl-mc/bind
The dprc.2 is bound to the VFIO driver and all the objects within
dprc.2 are going to be bound to the VFIO driver.
This patch adds the infrastructure for VFIO support for fsl-mc
devices. Subsequent patches will add support for binding and secure
assigning these devices using VFIO.
More details about the DPAA2 objects can be found here:
Documentation/networking/device_drivers/freescale/dpaa2/overview.rst
Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
This reverts commit 37054fc81443 ("gpu/drm: ingenic: Add option to mmap
GEM buffers cached")
At the very moment this commit was created, the DMA API it relied on was
modified in the DMA tree, which caused the driver to break in
linux-next.
Revert it for now, and it will be resubmitted later to work with the new
DMA API.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201004141758.1013317-1-paul@crapouillou.net
|
|
Introduce a way to specify additional debug flags with an crpyto
request to be able to trigger certain failures within the zcrypt
device drivers and/or ap core code.
This failure injection possibility is only enabled with a kernel debug
build CONFIG_ZCRYPT_DEBUG) and should never be available on a regular
kernel running in production environment.
Details:
* The ioctl(ICARSAMODEXPO) get's a struct ica_rsa_modexpo. If the
leftmost bit of the 32 bit unsigned int inputdatalength field is
set, the uppermost 16 bits are separated and used as debug flag
value. The process is checked to have the CAP_SYS_ADMIN capability
enabled or EPERM is returned.
* The ioctl(ICARSACRT) get's a struct ica_rsa_modexpo_crt. If the
leftmost bit of the 32 bit unsigned int inputdatalength field is set,
the uppermost 16 bits are separated and used als debug flag
value. The process is checked to have the CAP_SYS_ADMIN capability
enabled or EPERM is returned.
* The ioctl(ZSECSENDCPRB) used to send CCA CPRBs get's a struct
ica_xcRB. If the leftmost bit of the 32 bit unsigned int status
field is set, the uppermost 16 bits of this field are used as debug
flag value. The process is checked to have the CAP_SYS_ADMIN
capability enabled or EPERM is returned.
* The ioctl(ZSENDEP11CPRB) used to send EP11 CPRBs get's a struct
ep11_urb. If the leftmost bit of the 64 bit unsigned int req_len
field is set, the uppermost 16 bits of this field are used as debug
flag value. The process is checked to have the CAP_SYS_ADMIN
capability enabled or EPERM is returned.
So it is possible to send an additional 16 bit value to the zcrypt API
to be used to carry a failure injection command which may trigger
special behavior within the zcrypt API and layers below. This 16 bit
value is for the rest of the test referred as 'fi command' for Failure
Injection.
The lower 8 bits of the fi command construct a numerical argument in
the range of 1-255 and is the 'fi action' to be performed with the
request or the resulting reply:
* 0x00 (all requests): No failure injection action but flags may be
provided which may affect the processing of the request or reply.
* 0x01 (only CCA CPRBs): The CPRB's agent_ID field is set to
'FF'. This results in an reply code 0x90 (Transport-Protocol
Failure).
* 0x02 (only CCA CPRBs): After the APQN to send to has been chosen,
the domain field within the CPRB is overwritten with value 99 to
enforce an reply with RY 0x8A.
* 0x03 (all requests): At NQAP invocation the invalid qid value 0xFF00
is used causing an response code of 0x01 (AP queue not valid).
The upper 8 bits of the fi command may carry bit flags which may
influence the processing of an request or response:
* 0x01: No retry. If this bit is set, the usual loop in the zcrypt API
which retries an CPRB up to 10 times when the lower layers return
with EAGAIN is abandoned after the first attempt to send the CPRB.
* 0x02: Toggle special. Toggles the special bit on this request. This
should result in an reply code RY~0x41 and result in an ioctl
failure with errno EINVAL.
This failure injection possibilities may get some further extensions
in the future. As of now this is a starting point for Continuous Test
and Integration to trigger some failures and watch for the reaction of
the ap bus and zcrypt device driver code.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Move the creating and disposal of the struct ap_message one
level up the call chain. The ap message was constructed in the
calling functions in msgtype50 and msgtype6 but only for the
ica rsa messages. For CCA and EP11 CPRBs the ap message struct
is created in the zcrypt api functions.
This patch moves the construction of the ap message struct into
the functions zcrypt_rsa_modexpo and zcrypt_rsa_crt. So now all
the 4 zcrypt api functions zcrypt_rsa_modexpo, zcrypt_rsa_crt,
zcrypt_send_cprb and zcrypt_send_ep11_cprb appear and act
similar.
There are no functional changes coming with this patch.
However, the availability of the ap_message struct has
advantages which will be needed by a follow up patch.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Revisit the ap queue error handling: Based on discussions and
evaluatios with the firmware folk here is now a rework of the response
code handling for all the AP instructions. The idea is to distinguish
between failures because of some kind of invalid request where a retry
does not make any sense and a failure where another attempt to send
the very same request may succeed. The first case is handled by
returning EINVAL to the userspace application. The second case results
in retries within the zcrypt API controlled by a per message retry
counter.
Revisit the zcrpyt error handling: Similar here, based on discussions
with the firmware people here comes a rework of the handling of all
the reply codes. Main point here is that there are only very few
cases left, where a zcrypt device queue is switched to offline. It
should never be the case that an AP reply message is 'unknown' to the
device driver as it indicates a total mismatch between device driver
and crypto card firmware. In all other cases, the code distinguishes
between failure because of invalid message (see above - EINVAL) or
failures of the infrastructure (see above - EAGAIN).
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Support SCLP AP adapter config and deconfig operations:
The sysfs deconfig attribute /sys/devices/ap/cardxx/deconfig
for each AP card is now read-write. Writing in a '1' triggers
a synchronous SCLP request to configure the adapter, writing
in a '0' sends a synchronous SCLP deconfigure request.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Add support for AP bus adapter config and deconfig to the sclp
core code. The code is statically build into the kernel when
ZCRYPT is configured either as module or with static support.
This is the base functionality for having configure/deconfigure
support in the AP bus and card code. Another patch will exploit
this soon.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Suggested-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
This patch adds a new config state to the ap card and queue
devices. This state reflects the response code
0x03 "AP deconfigured" on TQAP invocation and is tracked with
every ap bus scan.
Together with this new state now a card/queue device which
is 'deconfigured' is not disposed any more. However, for backward
compatibility the online state now needs to take this state into
account. So a card/queue is offline when the device is not configured.
Furthermore a device can't get switched from offline to online state
when not configured.
The config state is shown in sysfs at
/sys/devices/ap/cardxx/config
for the card and
/sys/devices/ap/cardxx/xx.yyyy/config
for each queue within each card.
It is a read-only attribute reflecting the negation of the
'AP deconfig' state as it is noted in the AP documents.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
On AP instruction failures the last response code is now
kept in the struct ap_queue. There is also a new sysfs
attribute showing this field (enabled only on debug kernels).
Also slight rework of the AP_DBF macros to get some more
content into one debug feature message line.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
The state machine for each ap queue covered a mixture of
device states and state machine (firmware queue state) states.
This patch splits the device states and the state machine
states into two different enums and variables. The major
state is the device state with currently these values:
AP_DEV_STATE_UNINITIATED - fresh and virgin, not touched
AP_DEV_STATE_OPERATING - queue dev is working normal
AP_DEV_STATE_SHUTDOWN - remove/unbind/shutdown in progress
AP_DEV_STATE_ERROR - device is in error state
only when the device state is > UNINITIATED the state machine
is run. The state machine represents the states of the firmware
queue:
AP_SM_STATE_RESET_START - starting point, reset (RAPQ) ap queue
AP_SM_STATE_RESET_WAIT - reset triggered, waiting to be finished
if irqs enabled, set up irq (AQIC)
AP_SM_STATE_SETIRQ_WAIT - enable irq triggered, waiting to be
finished, then go to IDLE
AP_SM_STATE_IDLE - queue is operational but empty
AP_SM_STATE_WORKING - queue is operational, requests are stored
and replies may wait for getting fetched
AP_SM_STATE_QUEUE_FULL - firmware queue is full, so only replies
can get fetched
For debugging each ap queue shows a sysfs attribute 'states' which
displays the device and state machine state and is only available
when the kernel is build with CONFIG_ZCRYPT_DEBUG enabled.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Introduce a new config switch CONFIG_ZCRYPT_DEBUG which
will be used to enable some features for debugging the
zcrypt device driver and ap bus system:
Another patch will use this for displaying ap card and
ap queue state information via sysfs attribute.
A furher patch will use this to enable some special
treatment for some fields of an crypto request to be able
to inject failures and so help debugging with regards
to handling of failures.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Introduce a new internal struct zcrypt_track with an retry counter
field and a last return code field. Fill and update these fields at
certain points during processing of an request/reply. This tracking
info is then used to
- avoid trying to resend the message forever. Now each message is
tried to be send TRACK_AGAIN_MAX (currently 10) times and then the
ioctl returns to userspace with errno EAGAIN.
- avoid trying to resend the message on the very same card/domain. If
possible (more than one APQN with same quality) don't use the very
same qid as the previous attempt when again scheduling the request.
This is done by adding penalty weight values when the dispatching
takes place. There is a penalty TRACK_AGAIN_CARD_WEIGHT_PENALTY for
using the same card as previously and another penalty define
TRACK_AGAIN_QUEUE_WEIGHT_PENALTY to be considered when the same qid
as the previous sent attempt is calculated. Both values make it
harder to choose the very same card/domain but not impossible. For
example when only one APQN is available a resend can only address the
very same APQN.
There are some more ideas for the future to extend the use of this
tracking information. For example the last response code at NQAP and
DQAP could be stored there, giving the possibility to extended tracing
and debugging about requests failing to get processed properly.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
There is nothing to prevent the CPU or the compiler from reordering
the writes to stats->reset_time and stats->reset_pending in
store_reset(), in which case the readers of stats->reset_time may see
a stale value. Moreover, on 32-bit arches the write to reset_time
cannot be completed in one go, so the readers of it may see a
partially updated value in that case.
To prevent that from happening, add a write memory barrier between
the writes to stats->reset_time and stats->reset_pending in
store_reset() and corresponding read memory barrier in the
readers of stats->reset_time.
Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
HP Spectre notebooks (and probably other model as well)
support up to 4 thermal policy:
- HP Recommended
- Performance
- Cool
- Quiet
at least on HP Spectre x360 Convertible 15-df0xxx the firmware sets the
thermal policy to default but hardcode the odvp0 variable to 1, this causes
thermald to choose the wrong DPTF profile witch result in low performance
when notebook is on AC, calling thermal policy write command allow firmware
to correctly set the odvp0 variable.
Signed-off-by: Elia Devito <eliadevito@gmail.com>
Link: https://lore.kernel.org/r/20201004211305.11628-1-eliadevito@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Some of the pins were not exposed in the initial driver or kept as
reserved. Exposing all of them now.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20201007111220.744348-1-Shyam-sundar.S-k@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Fix to return negative error code -ENOMEM from the error handling
case instead of 0.
Fixes: 603f2bee2c54 ("i3c: master: Add driver for Cadence IP")
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-i3c/20200911033350.23904-1-jingxiangfeng@huawei.com
|
|
The device can be connected on SPI or on SDIO. The original file
described the two options separately. So, most of the file had to be
rewritten in order to match with the Yaml requirements.
Some device requirements are still written in the comments since they
cannot been expressed with the current scheme (e.g. reg must be set to 1
with SDIO, interrupt is mandatory with SPI, reset-gpio in SPI is
replaced by mmc-pwrseq in SDIO, etc...).
The examples provided have also been reworked in order to make
dt_binding_check happy.
Finally, also fix typo in the name of the file (siliabs instead of
silabs)
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Most of the files have been modified in 2020, so update the copyright
notices.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The device is in charge of respecting the QoS constraints. The driver
have to ensure that all the queues contain data and the device choose
the right queue to send.
The things starts to be more difficult when the bandwidth of the bus is
lower than the bandwidth of the WiFi. The device quickly sends the
frames of the highest priority queue. Then, it starts to send frames
from a lower priority queue. Though, there are still some high priority
frames waiting in the driver.
To work around this problem, this patch add some priorities to each
queue. The weigh of the queue was (roughly) calculated experimentally by
checking the speed ratio of each queue when the bus does not limit the
traffic:
- Be/Bk -> 20Mbps/10Mbps
- Vi/Be -> 36Mbps/180Kbps
- Vo/Be -> 35Mbps/600Kbps
- Vi/Vo -> 24Mbps/12Mbps
So, if we fix the weigh of the Background to 1, the weight of Best
Effort should be 2. The weight of Video should be 116. However, since
there is only 32 queues, it make no sense to use a value greater than
64[1]. And finally, the weight of the Voice is set to 128.
[1] Because of this approximation, with very slow bus, we can still
observe frame starvation when we measure the speed ratio of Vi/Be. It is
around 35Mbps/1Mbps (instead of 36Mbps/180Kbps). However, it is still in
accepted error range.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Firmwares with API < 3.6 do not forward DELBA requests. Thus, when a
Block Ack session is restarted, the reordering buffer is not flushed and
the received sequence number is not contiguous. Therefore, mac80211
starts to wait some missing frames that it will never receive.
This patch disables the reordering buffer for old firmware. It is
harmless when the network is unencrypted. When the network is encrypted,
the non-contiguous frames will be thrown away by the TKIP/CCMP replay
protection. So, the user will observe some packet loss with UDP and
performance drop with TCP.
Fixes: e5da5fbd7741 ("staging: wfx: fix CCMP/TKIP replay protection")
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit e8d607ce0c81 ("staging: wfx: drop 'secure link' feature") had
removed the 'secure link' feature. However, a few lines of codes were
yet here.
Fixes: e8d607ce0c81 ("staging: wfx: drop 'secure link' feature")
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
As expected, when the device detect a MMIC error, it returns a specific
status. However, it also strip IV from the frame (don't ask me why).
So, with the current code, mac80211 detects a corrupted frame and it
drops it before it handle the MMIC error. The expected behavior would be
to detect MMIC error then to renegotiate the EAP session.
So, this patch correctly informs mac80211 that IV is not available. So,
mac80211 correctly takes into account the MMIC error.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20201007101943.749898-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since commit 141f15c66d94 ("leds: pwm: remove header") that platform
interface is not usable from outside and there seems to be no in tree
user anymore. All in-tree users of the leds-pwm driver seem to use DT
currently. Getting rid of the old platform interface allows the
leds-pwm driver to switch over from 'devm_led_classdev_register()' to
'devm_led_classdev_register_ext()'.
Signed-off-by: Alexander Dahl <post@lespocky.de>
Cc: Denis Osterland-Heim <denis.osterland@diehl.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <apais@linux.microsoft.com>
Link: https://lore.kernel.org/r/20201006050458.221329-2-allen.lkml@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <apais@linux.microsoft.com>
Link: https://lore.kernel.org/r/20201006050458.221329-1-allen.lkml@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
'arm/qcom', 'arm/smmu', 'ppc/pamu', 'x86/amd', 'x86/vt-d' and 'core' into next
|
|
Instead of bailing out completely, such a unit can still be used for
interrupt remapping.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/linux-iommu/549928db2de6532117f36c9c810373c14cf76f51.camel@infradead.org/
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
The Toshiba Visconti TMPV7700 series pin controller is only present on
Visconti SoCs. Hence add a dependency on ARCH_VISCONTI, to prevent
asking the user about this driver when configuring a kernel without
Visconti platform support.
Fixes: a68a7844264e4fb9 ("pinctrl: visconti: Add Toshiba Visconti SoCs pinctrl support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Link: https://lore.kernel.org/r/20201005125049.26926-1-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The pca953x driver never checks the result of irq_find_mapping(),
which returns 0 when no mapping is found. When a spurious interrupt
is delivered (which can happen under obscure circumstances), the
kernel explodes as it still tries to handle the error code as
a real interrupt.
Handle this particular case and warn on spurious interrupts.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201005140217.1390851-1-maz@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
It appears that UML (arch/um) has no compat.h header defined and hence
can't compile a recently provided piece of code in GPIO library.
Disable compat ->read() code in UML case to avoid compilation errors.
While at it, use pattern which is already being used in the kernel elsewhere.
Fixes: 5ad284ab3a01 ("gpiolib: Fix line event handling in syscall compatible mode")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20201005131044.87276-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Add CQHCI initialization and implement CQHCI operations for GL9763E.
Use bit19 of the register (0x888) to decide whether to disable command
queuing. If the bit is set, the command queuing will be disabled.
Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw>
Link: https://lore.kernel.org/r/20201005105509.11343-1-ben.chuanggli@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The pinctrl driver can work without the EINT resource, but, if it is
expected to have this resource but the mtk_build_eint() function fails
after allocating their data (because can't get the resource or can't map
the irq), the data is not freed and you end with a NULL pointer
dereference. Fix this by freeing the data if mtk_build_eint() fails, so
pinctrl still works and doesn't hang.
This is noticeable after commit f97dbf48ca43 ("irqchip/mtk-sysirq: Convert
to a platform driver") on MT8183 because, due this commit, the pinctrl driver
fails to map the irq and spots the following bug:
[ 1.947597] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
[ 1.956404] Mem abort info:
[ 1.959203] ESR = 0x96000004
[ 1.962259] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.967565] SET = 0, FnV = 0
[ 1.970613] EA = 0, S1PTW = 0
[ 1.973747] Data abort info:
[ 1.976619] ISV = 0, ISS = 0x00000004
[ 1.980447] CM = 0, WnR = 0
[ 1.983410] [0000000000000004] user address but active_mm is swapper
[ 1.989759] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.995322] Modules linked in:
[ 1.998371] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1+ #44
[ 2.004715] Hardware name: MediaTek krane sku176 board (DT)
[ 2.010280] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--)
[ 2.015850] pc : mtk_eint_set_debounce+0x48/0x1b8
[ 2.020546] lr : mtk_eint_set_debounce+0x34/0x1b8
[ 2.025239] sp : ffff80001008baa0
[ 2.028544] x29: ffff80001008baa0 x28: ffff0000ff7ff790
[ 2.033847] x27: ffff0000f9ec34b0 x26: ffff0000f9ec3480
[ 2.039150] x25: ffff0000fa576410 x24: ffff0000fa502800
[ 2.044453] x23: 0000000000001388 x22: ffff0000fa635f80
[ 2.049755] x21: 0000000000000008 x20: 0000000000000000
[ 2.055058] x19: 0000000000000071 x18: 0000000000000001
[ 2.060360] x17: 0000000000000000 x16: 0000000000000000
[ 2.065662] x15: ffff0000facc8470 x14: ffffffffffffffff
[ 2.070965] x13: 0000000000000001 x12: 00000000000000c0
[ 2.076267] x11: 0000000000000040 x10: 0000000000000070
[ 2.081569] x9 : ffffaec0063d24d8 x8 : ffff0000fa800270
[ 2.086872] x7 : 0000000000000000 x6 : 0000000000000011
[ 2.092174] x5 : ffff0000fa800248 x4 : ffff0000fa800270
[ 2.097476] x3 : ffff8000100c5000 x2 : 0000000000000000
[ 2.102778] x1 : 0000000000000000 x0 : 0000000000000000
[ 2.108081] Call trace:
[ 2.110520] mtk_eint_set_debounce+0x48/0x1b8
[ 2.114870] mtk_gpio_set_config+0x5c/0x78
[ 2.118958] gpiod_set_config+0x5c/0x78
[ 2.122786] gpiod_set_debounce+0x18/0x28
[ 2.126789] gpio_keys_probe+0x50c/0x910
[ 2.130705] platform_drv_probe+0x54/0xa8
[ 2.134705] really_probe+0xe4/0x3b0
[ 2.138271] driver_probe_device+0x58/0xb8
[ 2.142358] device_driver_attach+0x74/0x80
[ 2.146532] __driver_attach+0x58/0xe0
[ 2.150274] bus_for_each_dev+0x70/0xc0
[ 2.154100] driver_attach+0x24/0x30
[ 2.157666] bus_add_driver+0x14c/0x1f0
[ 2.161493] driver_register+0x64/0x120
[ 2.165319] __platform_driver_register+0x48/0x58
[ 2.170017] gpio_keys_init+0x1c/0x28
[ 2.173672] do_one_initcall+0x54/0x1b4
[ 2.177499] kernel_init_freeable+0x1d0/0x238
[ 2.181848] kernel_init+0x14/0x118
[ 2.185328] ret_from_fork+0x10/0x34
[ 2.188899] Code: a9438ac1 12001266 f94006c3 121e766a (b9400421)
[ 2.194991] ---[ end trace 168cf7b3324b6570 ]---
[ 2.199611] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.207260] SMP: stopping secondary CPUs
[ 2.211294] Kernel Offset: 0x2ebff4800000 from 0xffff800010000000
[ 2.217377] PHYS_OFFSET: 0xffffb50500000000
[ 2.221551] CPU features: 0x0240002,2188200c
[ 2.225811] Memory Limit: none
[ 2.228860] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
Fixes: 89132dd8ffd2 ("pinctrl: mediatek: extend eint build to pinctrl-mtk-common-v2.c")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Sean Wang <sean.wang@kernel.org>
Link: https://lore.kernel.org/r/20201001142511.3560143-1-enric.balletbo@collabora.com
[rebased on changed infrastructure]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
kcov testing uncovered call to usb_hcd_giveback_urb() without disabling
interrupts.
Link: https://lore.kernel.org/linux-usb/CAAeHK+wb4k-LGTjK9F5YbJNviF_+yU+wE_=Vpo9Rn7KFN8vG6Q@mail.gmail.com/
usb_hcd_giveback_urb() is called from vhci's urb_enqueue, when it
determines it doesn't need to xmit the urb and can give it back.
This path runs in task context.
Disable irqs around usb_hcd_giveback_urb() call.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20201006223914.39257-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
As warned by Randy:
on x86_64:
CONFIG_USB_ROLE_SWITCH=m
and HISI_HIKEY_USB=y.
ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove':
hisi_hikey_usb.c:(.text+0x61): undefined reference to `usb_role_switch_unregister'
ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to `usb_role_switch_put'
ld: drivers/misc/hisi_hikey_usb.o: in function `hub_usb_role_switch_set':
hisi_hikey_usb.c:(.text+0xd3): undefined reference to `usb_role_switch_get_drvdata'
ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch':
hisi_hikey_usb.c:(.text+0x54d): undefined reference to `usb_role_switch_set_role'
ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe':
hisi_hikey_usb.c:(.text+0x8a5): undefined reference to `usb_role_switch_get'
ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to `usb_role_switch_register'
ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to `usb_role_switch_put'
Make it dependent on CONFIG_USB_ROLE_SWITCH.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/0e49432d0db9ee8429a9923a1d995935b6b83552.1602047370.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add Copyrights to those files that have been updated for UV5 changes.
Signed-off-by: Mike Travis <mike.travis@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201005203929.148656-14-mike.travis@hpe.com
|
|
Update UV MMRs in uv_mmrs.h for UV5 based on Verilog output from the
UV Hub hardware design files. This is the next UV architecture with
a new class (UVY) being defined for 52 bit physical address masks.
Uses a bitmask for UV arch identification so a single test can cover
multiple versions. Includes other adjustments to match the uv_mmrs.h
file to keep from encountering compile errors. New UV5 functionality
is added in the patches that follow.
[ Fix W=1 build warnings. ]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Mike Travis <mike.travis@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Steve Wahl <steve.wahl@hpe.com>
Link: https://lkml.kernel.org/r/20201005203929.148656-5-mike.travis@hpe.com
|
|
Remove the define is_uv() is_uv_system and just use the latter as is.
This removes a conflict with a new symbol in the generated uv_mmrs.h
file (is_uv()).
Signed-off-by: Mike Travis <mike.travis@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Reviewed-by: Steve Wahl <steve.wahl@hpe.com>
Link: https://lkml.kernel.org/r/20201005203929.148656-4-mike.travis@hpe.com
|
|
In nvme_set_queue_limits() we initialize vwc to false and later add
a condition to set vwc true. The value of the vwc can be declare
initialized which makes all the blk_queue_XXX() calls uniform.
Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
In nvme_validate_ns() the exra variable ctrl is used only twice.
Using ns->ctrl directly still maintains the redability and original
length of the lines in the code. Get rid of the extra variable ctrl &
use ns->ctrl directly.
Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Just fold it into the only caller.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
|
|
Move the logic to revalidate the block_device size or remove the
namespace from the caller into nvme_validate_ns. This removes
the return value and thus the status code translation. Additionally
it also catches non-permanent errors from nvme_update_ns_info using
the existing logic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
|
|
Move nvme_validate_ns just above its only remaining caller.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
|
|
Check the namespace identifier list first thing when scanning namespaces.
This keeps the code to query the CSI common between the alloc and validate
path, and helps to structure the code better for multiple command set
support.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
|
|
Consolidate the two calls into a single place.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
|
|
Now that the queue is frozen before updating ->lba_shift we can't hit the
invalid references mentioned in the comment any more. More importantly
this code would not have helped us if the format was changed by another
controller or through implementation defined back channels.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
|
