Checkpatch reported several cases of struct file_operations
not being const. This resolves those warnings.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Due to the way the DFID was embedded in our debug strings checkpatch
would report the following error:
CHECK: Concatenated strings should use spaces between elements
This patch introduces proper space to resolve these reports.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a RAID set was created on dm-raid version < 1.9.0 (old RAID
superblock format), all of the new 1.9.0 members of the superblock are
uninitialized (zero) -- including the device sectors member needed to
support shrinking.
All the other accesses to superblock fields new in 1.9.0 were reviewed
and verified to be properly guarded against invalid use. The 'sectors'
member was the only one used when the superblock version is < 1.9.
Don't access the superblock's >= 1.9.0 'sectors' member unconditionally.
Also add respective comments.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
This patch disables the use of the DMA for data transfer and forces the
use of PIO transfers instead as a quick fixup to solve the cache aliasing
issue on ARM9 based cores, which embeds a VIVT data cache.
Indeed in the case of VIVT data caches, it is not safe to call dma_map_*()
functions to map buffers for DMA transfers when those buffers have been
allocated by vmalloc() or from any DMA-unsafe area.
Further patches may propose a better solution based on the use of a bounce
buffer at the SPI sub-system level but such solution needs more time to be
discussed. Then the use of DMA transfers could be enabled again to improve
the performances but before that, this patch already solves the issue.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Implement S500 Smart Power System power-gating.
For now flag PD_CPU2 and PD_CPU3 as always-on.
Based on LeMaker linux-actions tree.
Signed-off-by: Andreas Färber <afaerber@suse.de>
This fixes up two commits that have touched this driver. The
command status field is now a blk_status_t, so we can't check
for < 0 and we definitely can't assume it's holding -Exxxx error
values. All we care about here is whether ->status is zero or not.
Check for that, and remove the various attempts at smart error
reporting. Just log to dmesg what command failed, and the
blk_status_t value.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 2a842acab1 ("block: introduce new block status code type")
Fixes: 3f5e6a3577 ("mtip32xx: convert internal command issue to block IO path")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Pull "bus: ARM CCN PMU driver updates" from Paweł Moll:
* Fixed missing module aliases, thus autoloading.
* Use appropriate (c)allocation function for arrays of structures.
* Add compatibility string (thus support) for CCN-502 variant.
* tag 'ccn/fixes-for-4.13-v2' of git://git.linaro.org/people/pawel.moll/linux:
bus: arm-ccn: Enable stats for CCN-502 interconnect
dt-bindings: arm-ccn: Add bindings info for CCN-502 compatible string
bus: arm-ccn: Use devm_kcalloc() in arm_ccn_probe()
bus: arm-ccn: Fix module autoload
Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/bus/arm-ccn.ko | grep alias
$
After this patch:
$ modinfo drivers/bus/arm-ccn.ko | grep alias
alias: of:N*T*Carm,ccn-504C*
alias: of:N*T*Carm,ccn-504
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Some recent Dell laptops, including the XPS13 model numbers 9360 and
9365, cannot be woken up from suspend-to-idle by pressing the power
button which is unexpected and makes that feature less usable on
those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is
not expected to be used at all (the OS these systems ship with never
exercises the ACPI S3 path in the firmware) and suspend-to-idle is
the only viable system suspend mechanism there.
The reason why the power button wakeup from suspend-to-idle doesn't
work on those systems is because their power button events are
signaled by the EC (Embedded Controller), whose GPE (General Purpose
Event) line is disabled during suspend-to-idle transitions in Linux.
That is done on purpose, because in general the EC tends to be noisy
for various reasons (battery and thermal updates and similar, for
example) and all events signaled by it would kick the CPUs out of
deep idle states while in suspend-to-idle, which effectively might
defeat its purpose.
Of course, on the Dell systems in question the EC GPE must be enabled
during suspend-to-idle transitions for the button press events to
be signaled while suspended at all, but fortunately there is a way
out of this puzzle.
First of all, those systems have the ACPI_FADT_LOW_POWER_S0 flag set
in their ACPI tables, which means that the OS is expected to prefer
the "low power S0 idle" system state over ACPI S3 on them. That
causes the most recent versions of other OSes to simply ignore ACPI
S3 on those systems, so it is reasonable to expect that it should not
be necessary to block GPEs during suspend-to-idle on them.
Second, in addition to that, the systems in question provide a special
firmware interface that can be used to indicate to the platform that
the OS is transitioning into a system-wide low-power state in which
certain types of activity are not desirable or that it is leaving
such a state and that (in principle) should allow the platform to
adjust its operation mode accordingly.
That interface is a special _DSM object under a System Power
Management Controller device (PNP0D80). The expected way to use it
is to invoke function 0 from it on system initialization, functions
3 and 5 during suspend transitions and functions 4 and 6 during
resume transitions (to reverse the actions carried out by the
former). In particular, function 5 from the "Low-Power S0" device
_DSM is expected to cause the platform to put itself into a low-power
operation mode which should include making the EC less verbose (so to
speak). Next, on resume, function 6 switches the platform back to
the "working-state" operation mode.
In accordance with the above, modify the ACPI suspend-to-idle code
to look for the "Low-Power S0" _DSM interface on platforms with the
ACPI_FADT_LOW_POWER_S0 flag set in the ACPI tables. If it's there,
use it during suspend-to-idle transitions as prescribed and avoid
changing the GPE configuration in that case. [That should reflect
what the most recent versions of other OSes do.]
Also modify the ACPI EC driver to make it handle events during
suspend-to-idle in the usual way if the "Low-Power S0" _DSM interface
is going to be used to make the power button events work while
suspended on the Dell machines mentioned above
Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull irqchip updates for v4.13 from Marc Zyngier
- support for the new Marvell wire-to-MSI bridge
- support for the Aspeed I2C irqchip
- Armada XP370 per-cpu interrupt fixes
- GICv3 ITS ACPI NUMA support
- sunxi-nmi cleanup and updates for new platform support
- various GICv3 ITS cleanups and fixes
- some constifying in various places
Drivers must not perform unbalanced calls to stop the entity pipeline,
however if they do they will fault in the core media code, as the
entity->pipe will be set as NULL. We handle this gracefully in the core
with a WARN for the developer.
Replace the erroneous check on zero streaming counts, with a check on
NULL pipe elements instead, as this is the symptom of unbalanced
media_pipeline_stop calls.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pincharts@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The type field in struct v4l2_selection is supposed to never use the
_MPLANE variants. E.g. if the driver supports V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
then userspace should still pass V4L2_BUF_TYPE_VIDEO_CAPTURE.
The reasons for this are lost in the mists of time, but it is really
annoying. In addition, the exynos drivers didn't follow this rule and
instead expected the _MPLANE type.
To fix that code is added to the v4l2 core that maps the _MPLANE buffer
types to their regular equivalents before calling the driver.
Effectively this allows for userspace to use either _MPLANE or the regular
buffer type. This keeps backwards compatibility while making things easier
for userspace.
Since drivers now never see the _MPLANE buffer types the exynos drivers
had to be adapted as well.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Change the core structure for adding subdevices in the topology.
Instead of calling the specific create function for each subdevice,
inject a child platform_device with the driver's name.
Each type of node in the topology (sensor, capture, debayer, scaler)
will register a platform_driver with the corresponding name through the
component subsystem.
Implementing a new subdevice type doesn't require vimc-core to be altered.
This facilitates future implementation of dynamic entities, where
hotpluging an entity in the topology is just a matter of
registering/unregistering a platform_device in the system.
It also facilitates other implementations of different nodes without
touching the core code and remove the need of a header file for each
type of node.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Allow user space to change the image format as the frame size, the
pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Allow user space to change the image format as the frame size, the
media bus pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c
as this core will be reused by other subdevices to activate the stream
in their directly connected nodes
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
As all the subdevices in the topology will be initialized in the same
way, to avoid code repetition the vimc_ent_sd_{register, unregister}
helper functions were created
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Pull "Qualcomm ARM Based Driver Updates for v4.13" from Andy Gross:
* Improve QCOM SMSM error handling
* tag 'qcom-drivers-for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux:
soc: qcom: smsm: Improve error handling, quiesce probe deferral
Commit e789029761 ("i2c: sh_mobile: don't send a stop condition by
default inside transfers") makes the i2c_sh_mobile I2C-adapter emit a
stop/start sequence between messages in a single transfer only when
explicitly requested with I2C_M_STOP.
This breaks the ov772x driver in the SH4 Migo-R board as the Omnivision
sensor uses the I2C-like SCCB protocol that doesn't support repeated
starts:
i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
ov772x 0-0021: Product ID error 92:92
Fix it by marking the client as SCCB, forcing the emission of a
stop/start sequence between all messages.
As I2C_M_STOP requires the I2C adapter to support protocol mangling,
ensure that the I2C_FUNC_PROTOCOL_MANGLING functionality is available.
Tested on SH4 Migo-R board, with OV772x now successfully probing
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
ov772x 0-0021: ov7725 Product ID 77:21 Manufacturer ID 7f:a2
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The error check of mbr < 0 is always false because mbr is a u32. Make
mbt an int so that a -ve error return from stm32_spi_prepare_mbr can be
detected.
Detected by CoverityScan, CID#1446586 ("Unsigned compared against 0")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When trying to TX through a monitor interface, the
conditions in iwl_mvm_tx_skb_non_sta() don't match
and the frame tries to go out from an usued TXQ.
Add a check for monitor iface, and use the AUX queue
in such a case.
In non-DQA mode the frame is sent through the
static-allocated queues anyway, so the problem is
in DQA mode only.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In some platforms, having the device enabled with certain radio
frontends causes the platform to not be able to resume properly
from suspend, regardless of the wakeup cause. This was traced to
a hardware issue with the integrated 9000-series A-step variant.
Set the right hardware bit to disable the problematic state.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When the firmware crashes, the transmit queues can't make
any progress. This is why we stop the counter that monitor
the transmit queues' activity.
The call that notifies the error to the op_mode may take
a bit of time, so stop the timer of the transmit queues
earlier.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The driver prints "L1 Enabled - LTR Enabled" all the time as dev_info,
which is just useless noise in most cases. Convert this to
IWL_DEBUG_POWER() so we don't pollute the log unnecessarily but still
can get this info on demand.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
It's sometimes hard to find out which HW address the iwlwifi device is
using, for instance when reading crouded sniffer logs. To make it
easier, print out an info level message with the HW address as soon as
we know it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This new API allows flushing queues based on station ID and TID in A000
devices. One reason for using this is that tfd_queue_mask is only good
for 32 queues, which is not enough for A000 devices.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Mordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we get an ASSERT, the fw_dump_desc pointer points to
iwl_mvm_dump_desc_assert which can't be freed since it is
a global. We still need to NULL'ify the pointer when we
call iwl_mvm_free_fw_dump_desc otherwise we will hit
int iwl_mvm_fw_dbg_collect_desc(struct iwl_mvm *mvm,
const struct iwl_mvm_dump_desc *desc,
const struct iwl_fw_dbg_trigger_tlv *trigger)
{
<snip>
if (WARN_ON(mvm->fw_dump_desc))
iwl_mvm_free_fw_dump_desc(mvm);
Fixes: b6eaa45aa1 ("iwlwifi: mvm: add the cause of the firmware dump in the dump")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When updating the mac context after association,
assoc_beacon_arrive_time is not being set, which causes the FW to
set a wrong TSF to the MAC.
Fix this by setting the assoc_beacon_arrive_time when updating the
mac context after association.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Nothing ever checks the return value of iwl_pcie_apm_stop_master(),
so there's no point in it having one - make it return void.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In case we need to move the scheduler write pointer by
steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck.
This leads to hardware error interrupts with status:
0x5A5A5A5A or alike.
In order to work around this, detect in the transport
layer that we are going to hit this case and tell iwlmvm
to increment the sequence number of the packets. This
allows to keep the requirement that the WiFi sequence
number is in sync with the index in the scheduler Tx queue
and it also allows to avoid the problematic sequence.
This means that from time to time, we will start a queue
from ssn + 1, but that shouldn't be a problem since we
don't switch to new queues for AMPDU now that we have
DQA which allows to keep the same queue while toggling
the AMPDU state.
This bug has been fixed on 9000 devices and up.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
A TID may not have traffic but still have a BA agreement
active (or being setup / torn down) since a BA agreement
can be triggered by a debugfs hook.
Just avoid to consider such a TID as inactive to make the
logic safer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If the hardware is stuck, we can't read any of the memory we need to
dump it, so we end up printing only 0xa5a5a5a5, which is useless.
To solve this, poke the hardware by triggering a reset and re-enabling
the clocks if we detect a HW error.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we started using threaded irqs, all the opmode calls were changed
to be called with local_bh disabled. The reason for this was it was
that mac80211 needs that. When we are handling FW errors, mac80211 is
not involved, so we don't need it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In BSS mode in the disconnection flow, mac80211 removes
the AP station before the vif is set to unassociated.
Our firmware wants it the other way around: first set
the vif as unassociated, and then remove the AP station.
In order to bridge between those two different behaviors,
iwlmvm doesn't remove the station from the firmware when
mac80211 removes it, but only after the vif is set to
unassociated. The implementation is in
iwl_mvm_bss_info_changed_station:
if (assoc state was modified && mvmvif->ap_sta_id is VALID
&& assoc state is now UNASSC)
remove_the_station_from_the_firmware()
During the recovery flow, mac80211 re-adds the AP station
and then reconfigures the vif. Since the vif is not
associated, and then, we enter the if above (which was
intended to be taken in the disconnection flow only) and
remove the station we just added. This defeats the
recovery flow.
Fix this by not removing the AP station in this flow if
we are in recovery flow.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We allocate nvm_data in iwl_mvm_nvm_get_from_fw(). If something goes
wrong after the allocation (i.e. if no valid MAC address is valid), we
should free nvm_data before returning an error.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This function just calls kfree(), so it only obscures the code without
bringing any benefits. Remove it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
