c0adf54a10 introduced new sparse warnings:
CHECK /home/dahern/kernels/linux.git/net/rds/ib_cm.c
net/rds/ib_cm.c:191:34: warning: incorrect type in initializer (different base types)
net/rds/ib_cm.c:191:34: expected unsigned long long [unsigned] [usertype] dp_ack_seq
net/rds/ib_cm.c:191:34: got restricted __be64 <noident>
net/rds/ib_cm.c:194:51: warning: cast to restricted __be64
The temporary variable for sequence number should have been declared as __be64
rather than u64. Make it so.
Signed-off-by: David Ahern <david.ahern@oracle.com>
Cc: shamir rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 8d7d9cca43.
Now that the necessary infrastructure is really all there
in the tree, we can put this change back in.
Signed-off-by: David S. Miller <davem@davemloft.net>
When smsc911x uses GPIO as the interrupt controller, and if both are
loaded as modules, we get following error:
"smsc911x: Could not allocate irq resource"
This issue is because of smsc911x using platform_get_resource to get
device tree based irq resource.
commit "9ec36ca (of/irq: do irq resolution in platform_get_irq)" and
commit "7085a7 (drivers: platform: parse IRQ flags from resources)" add
support in platform_get_irq to resolve irq and irq_flags respectively
for both modern device tree and legacy static platform data platforms.
Modify smsc911x driver to use platform_get_irq to pick up irq resource
correctly and use irq_get_trigger_type to get the IRQ trigger flags.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a FUA request enters its DATA stage of flush pipeline, the
request is added to mq requeue list, the request will then be added to
ctx->rq_list. blk_mq_attempt_merge() might merge the request with a bio.
Later when the request is finished the flush pipeline, the
request->__data_len is 0. Then I only saw the bio gets endio called, the
original request never finish.
Adding REQ_FLUSH_SEQ into REQ_NOMERGE_FLAGS looks an easy fix.
stable: 3.15+
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Ying Xue says:
====================
tipc: cleanup topology server
Not only function names declared in subscr.c are very confused, but
also topology server's locking policy is not designed very well, for
instance, usually leading to panic in some special corner cases.
In this series, we attempt to eliminate the confusion of function names
and simplify topology server's locking policy to solve above mentioned
issues. More importantly, the change will make relevant code easily
understandable and maintainable.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Once tipc_conn_new() returns NULL, the connection should be shut
down immediately, otherwise, oops may happen due to the NULL pointer.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently subscriber's lock protects not only subscriber's subscription
list but also all subscriptions linked into the list. However, as all
members of subscription are never changed after they are initialized,
it's unnecessary for subscription to be protected under subscriber's
lock. If the lock is used to only protect subscriber's subscription
list, the adjustment not only makes the locking policy simpler, but
also helps to avoid a deadlock which may happen once creating a
subscription is failed.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At present subscriber's lock is used to protect the subscription list
of subscriber as well as subscriptions linked into the list. While one
or all subscriptions are deleted through iterating the list, the
subscriber's lock must be held. Meanwhile, as deletion of subscription
may happen in subscription timer's handler, the lock must be grabbed
in the function as well. When subscription's timer is terminated with
del_timer_sync() during above iteration, subscriber's lock has to be
temporarily released, otherwise, deadlock may occur. However, the
temporary release may cause the double free of a subscription as the
subscription is not disconnected from the subscription list.
Now if a reference counter is introduced to subscriber, subscription's
timer can be asynchronously stopped with del_timer(). As a result, the
issue is not only able to be fixed, but also relevant code is pretty
readable and understandable.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Introducing a new function makes the purpose of tipc_subscrb_connect_cb
callback routine more clear.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a topology server accepts a connection request from its client,
it allocates a connection instance and a tipc_subscriber structure
object. The former is used to communicate with client, and the latter
is often treated as a subscriber which manages all subscription events
requested from a same client. When a topology server receives a request
of subscribing name services from a client through the connection, it
creates a tipc_subscription structure instance which is seen as a
subscription recording what name services are subscribed. In order to
manage all subscriptions from a same client, topology server links
them into the subscrp_list of the subscriber. So subscriber and
subscription completely represents different meanings respectively,
but function names associated with them make us so confused that we
are unable to easily tell which function is against subscriber and
which is to subscription. So we want to eliminate the confusion by
renaming them.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hardware doesn't seem to work correctly, just block userspace in this case.
v2: add missing defines
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320
Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The code in __netdev_upper_dev_link() has an over-stringent
loop detection logic that actually prevents valid configurations
from working correctly.
In particular, the logic returns an error if an upper device
is already in the list of all upper devices for a given dev.
This particular check seems to be a overzealous as it disallows
perfectly valid configurations. For example:
# ip l a link eth0 name eth0.10 type vlan id 10
# ip l a dev br0 typ bridge
# ip l s eth0.10 master br0
# ip l s eth0 master br0 <--- Will fail
If you switch the last two commands (add eth0 first), then both
will succeed. If after that, you remove eth0 and try to re-add
it, it will fail!
It appears to be enough to simply check adj_list to keeps things
safe.
I've tried stacking multiple devices multiple times in all different
combinations, and either rx_handler registration prevented the stacking
of the device linking cought the error.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Veaceslav Falico <vfalico@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As German phone operators are discontinuing ISDN service, neither
Hansjörg nor I will be able to maintain the Gigaset ISDN drivers
any longer. Paul Bolle offered to step into the breach for odd
fixes.
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Acked-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Lüssing says:
====================
Exporting IGMP/MLD checking from bridge code
The multicast optimizations in batman-adv are yet only usable and
enabled in non-bridged scenarios. To be able to support bridged setups
batman-adv needs to be able to detect IGMP/MLD queriers and reports on
mesh nodes without bridges, too. See the following link for details:
http://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-listener-reports
To avoid duplicate code between the bridge and batman-adv, the IGMP/MLD
message validation code is moved from the bridge to the IPv4/IPv6 stack.
On the way, some refactoring to increase readability and to iron out
some subtle differences between the IGMP and MLD parsing code is done.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
With this patch, the IGMP and MLD message validation functions are moved
from the bridge code to IPv4/IPv6 multicast files. Some small
refactoring was done to enhance readibility and to iron out some
differences in behaviour between the IGMP and MLD parsing code (e.g. the
skb-cloning of MLD messages is now only done if necessary, just like the
IGMP part always did).
Finally, these IGMP and MLD message validation functions are exported so
that not only the bridge can use it but batman-adv later, too.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: David S. Miller <davem@davemloft.net>
Let's use these new, neat helpers.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds support for the LED controller on Broadcom's BCM6328.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This adds device tree binding documentation for the Broadcom BCM6328 LED controller.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch adds a driver for the 1.5A Step-Up Current Regulator
for Flash LEDs. The device is programmed through a Skyworks proprietary
AS2Cwire serial digital interface.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch adds device tree binding documentation for
1.5A Step-Up Current Regulator for Flash LEDs.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: devicetree@vger.kernel.org
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Part of led-trigger API was in the private drivers/leds/leds.h header.
Move it to the include/linux/leds.h header to unify the API location
and announce it as public. It has been already exported from
led-triggers.c with EXPORT_SYMBOL_GPL macro. The no-op definitions are
changed from macros to inline to match the style of the surrounding code.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Make sure that already registered LEDs will be torn down properly
if the name of the next LED to create is unavailable.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
-EPROBE_DEFER on the second gpio led to be created, the first already
registered led is not torn down properly. This causes create_gpio_led()
to fail for the first led on re-probe().
Fix this misbehaviour by incrementing num_leds only if all
potentially failing calls completed successfully.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The TLC59116 is an I2C bus controlled 16-channel LED driver. The
TLC59108 is an I2C bus controlled 8-channel LED driver, which is very
similar to the TLC59116. Each LED output has its own 8-bit
fixed-frequency PWM controller to control the brightness of the LED.
The LEDs can also be fixed off and on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Imre Kaloz <kaloz@openwrt.org>
Cc: Matthew.Fatheree@belkin.com
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Document the binding for the TLC591xx LED driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Imre Kaloz <kaloz@openwrt.org>
Cc: Matthew.Fatheree@belkin.com
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.
This board has support for device tree based booting, and we've been
printing warnings about the legacy booting being deprecated for a
few merge cycles now. Let's attempt to remove the legacy booting
for it.
The reason for removing the legacy booting support now rather than
later is we can simply revert this patch if necessary if we run
into some unexpected issues that are not trivial to fix for the
device tree based booting.
Cc: Florian Vaussard <florian.vaussard@epfl.ch>
Acked-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
WSC connection is secure (privacy bit set in various frames)
but authentication suite, keys etc. are absent.
Support this mode in the connect WMI command. Detect WSC by
having 'sme->privacy' and no RSN IE. Inform firmware about WSC
session by setting dot11_auth_mode to WMI_AUTH11_WSC.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Introduce 2 types of GTK, Tx (for this STA) and Rx (for each peer).
Now, AP has only Tx GTK, STA - only Rx one. PBSS not supported yet;
for it, continue using pseudo-DMS.
Handle per-vring .1x state, update it from WMI_VRING_EN_EVENTID
event. This allows unification for unicast and broadcast vrings.
This mechanism replaces former per-CID "data_port_open"
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Pmc is a hardware debug mechanism which allows capturing phy data,
packets, and internally generated events and messages synchronized
and time stamped by the hardware. It requires memory buffers
allocated by the driver in order to be used by hardware dma to
upstream real time debug data to host memory.
Driver will handle memory allocation and release, and fetching
the data from the memory to application layer via debug file
system. The configuration of pmc is handled entirely by the
application layer.
Signed-off-by: Vladimir Shulman <qca_shulmanv@qca.qualcomm.com>
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Parameters for the start_ap and change_bcon contains
probe response template and probe response IE's.
supplicant puts in the proberesp_ies only WPS related IE's,
while firmware need all IE's, most notable is RSN that is not
included in the proberesp_ies.
Always use IE's provided by the bcon->probe_resp
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Boot loader "ready" indication has changed from "bit0 set"
to "only bit0 set". This is to address hardware glitches.
Due to glitches, sometimes right after reset register reads
0xffffffff, or (rarely) other garbage.
Reflect this in the driver
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Rx descriptor fields accordingly to the updated
hardware documentation
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Sometimes it takes for the firmware more than 20ms to
react on "echo" command after reset. Increase timeout
from 20 to 50ms
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.
This board has support for device tree based booting, and we've been
printing warnings about the legacy booting being deprecated for a
few merge cycles now. Let's attempt to remove the legacy booting
for it.
The reason for removing the legacy booting support now rather than
later is we can simply revert this patch if necessary if we run
into some unexpected issues that are not trivial to fix for the
device tree based booting.
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
qca6174 otp binary seems to always return an error to the host, even if the
calibration succeeded. Add a firmware feature flag to detect if the firmware
image which have this problem and workaround the issue in ath10k by ignoring
the error code.
I was also considering making this hw specific flag but as this is strictly a
firmware issue it's best to handle this via a firmware feature flag so that it
will be easy to disable the workaround.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm.bias_level with snd_soc_codec_get_bias_level().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm with snd_soc_codec_get_dapm().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm.bias_level with snd_soc_codec_get_bias_level().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm.bias_level with snd_soc_codec_get_bias_level().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm.bias_level with snd_soc_codec_get_bias_level() and all
remaining access to codec->dapm with snd_soc_codec_get_dapm().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm with snd_soc_codec_get_dapm().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dapm field of the snd_soc_codec struct is eventually going to be
removed, in preparation for this replace all manual access to
codec->dapm with snd_soc_codec_get_dapm().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
11 bits on OMAP5 as against 8 bits on OMAP4, with the master
NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
field.
2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
input sources on OMAP5. The common DEBUGSS source is at a
different input on each SoC.
Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
rt5650 and rt5645 are similar codec so reuse the cht_bsw_rt5645 driver
Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
