This requires changing the nl80211 parsing code a bit to use
intermediate pointers for the allocation, but clarifies the
API towards the drivers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This also propagates through the drivers.
The orinoco driver uses the cfg80211 API structs for internal
bookkeeping, and so needs a (void *) cast that removes the
const - but that's OK because it allocates those pointers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Exynos5800 clock structure is mostly similar to 5420 with only
a small delta changes. So the 5420 clock file is re-used for
5800 also. The common clocks for both are seggreagated and few
clocks which are different for both are separately initialized.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Vince noticed that we test the (unsigned long) flags field against an
(unsigned int) constant. This would allow setting the high bits on 64bit
platforms and not get an error.
There is nothing that uses the high bits, so it should be entirely
harmless, but we don't want userspace to accidentally set them anyway,
so fix the constants.
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140423102254.GL11096@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Alexander noticed that we use RCU iteration on rb->event_list but do
not use list_{add,del}_rcu() to add,remove entries to that list, nor
do we observe proper grace periods when re-using the entries.
Merge ring_buffer_detach() into ring_buffer_attach() such that
attaching to the NULL buffer is detaching.
Furthermore, ensure that between any 'detach' and 'attach' of the same
event we observe the required grace period, but only when strictly
required. In effect this means that only ioctl(.request =
PERF_EVENT_IOC_SET_OUTPUT) will wait for a grace period, while the
normal initial attach and final detach will not be delayed.
This patch should, I think, do the right thing under all
circumstances, the 'normal' cases all should never see the extra grace
period, but the two cases:
1) PERF_EVENT_IOC_SET_OUTPUT on an event which already has a
ring_buffer set, will now observe the required grace period between
removing itself from the old and attaching itself to the new buffer.
This case is 'simple' in that both buffers are present in
perf_event_set_output() one could think an unconditional
synchronize_rcu() would be sufficient; however...
2) an event that has a buffer attached, the buffer is destroyed
(munmap) and then the event is attached to a new/different buffer
using PERF_EVENT_IOC_SET_OUTPUT.
This case is more complex because the buffer destruction does:
ring_buffer_attach(.rb = NULL)
followed by the ioctl() doing:
ring_buffer_attach(.rb = foo);
and we still need to observe the grace period between these two
calls due to us reusing the event->rb_entry list_head.
In order to make 2 happen we use Paul's latest cond_synchronize_rcu()
call.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140507123526.GD13658@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The csa_counter_offs was erroneously described as csa_offs in
the docbook section.
This fixes two warnings when making htmldocs (at least):
Warning(include/net/mac80211.h:3428): No description found for parameter 'csa_counter_offs[IEEE80211_MAX_CSA_COUNTERS_NUM]'
Warning(include/net/mac80211.h:3428): Excess struct/union/enum/typedef member 'csa_offs' description in 'ieee80211_mutable_offsets'
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move the comment in the structure to a description of the
max_num_csa_counters field in the docbook area.
This fixes a warning when building htmldocs (at least):
Warning(include/net/cfg80211.h:3064): No description found for parameter 'max_num_csa_counters'
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of letting the ULD play games with the prep_fn move back to
the model of a central prep_fn with a callback to the ULD. This
already cleans up and shortens the code by itself, and will be required
to properly support blk-mq in the SCSI midlayer.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Now that all objects are released in the reverse order via the
transaction infrastructure, we can enqueue the release via
call_rcu to save one synchronize_rcu. For small rule-sets loaded
via nft -f, it now takes around 50ms less here.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Instead of caching the original skbuff that contains the netlink
messages, this stores the netlink message sequence number, the
netlink portID and the report flag. This helps to prepare the
introduction of the object release via call_rcu.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Leave the set content in consistent state if we fail to load the
batch. Use the new generic transaction infrastructure to achieve
this.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This patch speeds up rule-set updates and it also provides a way
to revert updates and leave things in consistent state in case that
the batch needs to be aborted.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This patch speeds up rule-set updates and it also introduces a way to
revert chain updates if the batch is aborted. The idea is to store the
changes in the transaction to apply that in the commit step.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This patch reworks the nf_tables API so set updates are included in
the same batch that contains rule updates. This speeds up rule-set
updates since we skip a dialog of four messages between kernel and
user-space (two on each direction), from:
1) create the set and send netlink message to the kernel
2) process the response from the kernel that contains the allocated name.
3) add the set elements and send netlink message to the kernel.
4) process the response from the kernel (to check for errors).
To:
1) add the set to the batch.
2) add the set elements to the batch.
3) add the rule that points to the set.
4) send batch to the kernel.
This also introduces an internal set ID (NFTA_SET_ID) that is unique
in the batch so set elements and rules can refer to new sets.
Backward compatibility has been only retained in userspace, this
means that new nft versions can talk to the kernel both in the new
and the old fashion.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The patch adds message type to the transaction to simplify the
commit the and abort routines. Yet another step forward in the
generalisation of the transaction infrastructure.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This patch generalises the existing rule transaction infrastructure
so it can be used to handle set, table and chain object transactions
as well. The transaction provides a data area that stores private
information depending on the transaction type.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The new transaction infrastructure updates the family, table and chain
objects in the context structure, so let's deconstify them. While at it,
move the context structure initialization routine to the top of the
source file as it will be also used from the table and chain routines.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Armin pointed me to the fact that the identifier which is used to ensure the
unique include processing in lunux/include/uapi/linux/can.h is CAN_H.
This clashed with his own source as includes from libraries and APIs should
use an underscore '_' at the identifier start.
This patch fixes the protection identifiers in all CAN relavant includes.
Reported-by: Armin Burchardt <armin@uni-bremen.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Add support for the CAN controller found in Renesas R-Car SoCs.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The configuration is stored in NVRAM on the maXTouch chip. When the device
is reset it reports a CRC of the stored configuration values. Therefore it
isn't necessary to send the configuration on each probe - we can check the
CRC matches and avoid a timeconsuming backup/reset cycle.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* The mapping of the GPIO numbers into the T19 status byte varies between
different maXTouch chips. Some have up to 7 GPIOs. Allowing a keycode array
of up to 8 items is simpler and more generic. So replace #define with
configurable number of keys which also allows the removal of is_tp.
* Rename platform data parameters to include "t19" to prevent confusion with
T15 key array.
* Probe aborts early on when pdata is NULL, so no need to check.
* Move "int i" to beginning of function (mixed declarations and code)
* Use API calls rather than __set_bit()
* Remove unused dev variable.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Yufeng Shen <miletus@chromium.org>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
It is not necessary to download these values to the maXTouch chip on every
probe, since they are stored in NVRAM. It makes life difficult when tuning
the device to keep them in sync with the config array/file, and requires a
new kernel build for minor tweaks.
These parameters only represent a tiny subset of the available
configuration options, tracking all of these options in platform data would
be a endless task. In addition, different versions of maXTouch chips may
have these values in different places or may not even have them at all.
Having these values also makes life more complex for device tree and other
platforms where having to define a static configuration isn't helpful.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Get rid of the attb_read_val() platform hook. Instead, read the ATTB gpio
directly from the driver.
Fail if valid ATTB gpio is not provided by patform data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Introduce helper functions to configure power and interrupt registers.
Default to IDLE mode on probe as device supports auto wakeup to ACVIE mode
on detecting finger touch.
Configure interrupt mode and polarity on start up. Power down on device
closure or module removal.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fix following warnings:
smp_32.c:177:5: warning: symbol 'setup_profiling_timer' was not declared. Should it be static?
smp_64.c:1202:5: warning: symbol 'setup_profiling_timer' was not declared. Should it be static?
smp_64.c:989:6: warning: symbol 'kgdb_roundup_cpus' was not declared. Should it be static?
Add prototype to include/linux/profile.h of setup_profiling_timer
Add missing include to smp_64.c
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bit[9:0] is interrupt ID field in GICC_IAR. Bit[12:10] is CPU ID field,
and others are reserved.
So we should use GICC_IAR_INT_ID_MASK to get interrupt ID. It's not a good way
to use ~0x1c00 (CPU ID field) to get interrupt ID.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Link: https://lkml.kernel.org/r/1399795571-17231-3-git-send-email-haojian.zhuang@linaro.org
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
This would be a no-op, so there is no reason to request it.
This also allows conversion of the current implementations of
ethtool_ops::{get,set}_rxfh_indir to ethtool_ops::{get,set}_rxfh
with no change other than their parameters.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
We usually allocate special values of u32 fields starting from the top
down, so also change the value to 0xffffffff. As these operations
haven't been included in a stable release yet, it's not too late to
change.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
There are several fixes in this patch (mostly because it's hard
splitting them up):
- Revert the name field in struct hwrng back to 'const'. Also, don't
do an extra kmalloc for the name - just wasteful.
- Deal with allocation failures properly.
- Use IDA to allocate device number instead of brute forcing one.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder->mode_set callback removal (Daniel)
- 64b reloc fixes (Ben)
- first part of atomic plane updates (Ville)
* tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Remove useless checks from primary enable/disable
drm/i915: Merge LP1+ watermarks in safer way
drm/i915: Make sure computed watermarks never overflow the registers
drm/i915: Add pipe update trace points
drm/i915: Perform primary enable/disable atomically with sprite updates
drm/i915: Make sprite updates atomic
drm/i915: Support 64b relocations
drm/i915: Support 64b execbuf
drm/i915/sdvo: Remove ->mode_set callback
drm/i915/crt: Remove ->mode_set callback
drm/i915/tv: Remove ->mode_set callback
drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set
drm/i915/tv: De-magic device check
drm/i915/tv: extract set_color_conversion
drm/i915/tv: extract set_tv_mode_timings
drm/i915/dvo: Remove ->mode_set callback
drm/i915: Make encoder->mode_set callbacks optional
drm/i915: Make primary_enabled match the actual hardware state
drm/i915: Move ring_begin to signal()
drm/i915: Virtualize the ringbuffer signal func
...
Calling netif_carrier_{on,off} is sufficient. There is no need
to duplicate the carrier state in a driver specific flag.
Acked-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lots of devices request much larger buffers than reasonable. This
cause real problems for users of hosts with limited resources.
Reducing the default buffer size to 16kB for such devices is
a reasonable trade-off between allowing them to aggregate traffic
and avoiding memory exhaustion on resource restrained hosts.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
To have an idea of the effects of the protocol coalescing
it's useful to have some counters showing the different
aspects.
Due to the asymmetrical usbnet interface the netdev
rx_bytes counter has been counting real received payload,
while the tx_bytes counter has included the NCM/MBIM
framing overhead. This overhead can be many times the
payload because of the aggressive padding strategy of
this driver, and will vary a lot depending on device
and traffic.
With very few exceptions, users are only interested in
the payload size. Having an somewhat accurate payload
byte counter is particularly important for mobile
broadband devices, which many NCM devices and of course
all MBIM devices are. Users and userspace applications
will use this counter to monitor account quotas.
Having protocol specific counters for the overhead, we are
now able to correct the tx_bytes netdev counter so that
it shows the real payload
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
We pad frames larger than X to maximum size for devices which
don't need a ZLP after maximum sized frames. This allows the
device to optimize its transfers for one fixed buffer size.
X was arbitrarily set at 512 bytes regardless of real buffer
maximum, causing extreme overheads due to excessive padding of
larger tx buffers. Limit the padding to at most 3 full USB
packets, still allowing the overhead to payload ratio of 3/1.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Many newer NCM and MBIM devices will request a maximum tx
datagram count which is much smaller than our hard-coded
absolute max. We can reduce the overhead without sacrificing
any of the simplicity for these devices, by simply using the
true negotiated count in when calculated the maximum NTH and
NDP header sizes.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Datagram coalescing is an integral part of the NCM and MBIM
protocols, intended to reduce the interrupt load primarily
on the device end of the USB link. As with all coalescing
solutions, there is a trade-off between buffering and
interrupts.
The current defaults are based on the assumption that device
side buffers should be the limiting factor. However, many
modern high speed LTE modems suffers from buffer-bloat,
making this assumption fail. This results in sub-optimal
performance due to excessive coalescing. And in cases where
such modems are connected to cheap embedded hosts there is
often severe buffer allocation issues, giving very noticeable
performance degradation .
A start on improving this is going from build time hard
coded limits to per device user configurable limits. The
ethtool coalescing API was selected as user interface
because, although the tuned values are buffer sizes, these
settings directly control datagram coalescing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Prior to commit fbd929f2dc
bonding: support QinQ for bond arp interval
the arp monitoring code allowed for proper detection of devices
stacked on top of vlans. Since the above commit, the
code can still detect a device stacked on top of single
vlan, but not a device stacked on top of Q-in-Q configuration.
The search will only set the inner vlan tag if the route
device is the vlan device. However, this is not always the
case, as it is possible to extend the stacked configuration.
With this patch it is possible to provision devices on
top Q-in-Q vlan configuration that should be used as
a source of ARP monitoring information.
For example:
ip link add link bond0 vlan10 type vlan proto 802.1q id 10
ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
ip link add link vlan100 type macvlan
Note: This patch limites the number of stacked VLANs to 2,
just like before. The original, however had another issue
in that if we had more then 2 levels of VLANs, we would end
up generating incorrectly tagged traffic. This is no longer
possible.
Fixes: fbd929f2dc (bonding: support QinQ for bond arp interval)
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@redhat.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Patric McHardy <kaber@trash.net>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit dc8eaaa006.
vlan: Fix lockdep warning when vlan dev handle notification
Instead we use the new new API to find the lock subclass of
our vlan device. This way we can support configurations where
vlans are interspersed with other devices:
bond -> vlan -> macvlan -> vlan
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently netif_addr_lock_nested assumes that there can be only
a single nesting level between 2 devices. However, if we
have multiple devices of the same type stacked, this fails.
For example:
eth0 <-- vlan0.10 <-- vlan0.10.20
A more complicated configuration may stack more then one type of
device in different order.
Ex:
eth0 <-- vlan0.10 <-- macvlan0 <-- vlan1.10.20 <-- macvlan1
This patch adds an ndo_* function that allows each stackable
device to report its nesting level. If the device doesn't
provide this function default subclass of 1 is used.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Multiple devices in the kernel can be stacked/nested and they
need to know their nesting level for the purposes of lockdep.
This patch provides a generic function that determines a nesting
level of a particular device by its type (ex: vlan, macvlan, etc).
We only care about nesting of the same type of devices.
For example:
eth0 <- vlan0.10 <- macvlan0 <- vlan1.20
The nesting level of vlan1.20 would be 1, since there is another vlan
in the stack under it.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- localize GPIO header in mach-at91 directory
- big update on the CCF front with main and slow clocks
- a cleanup of ADC and touchscreen driver with unification on IIO and
removal of old driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJTamtjAAoJEAf03oE53VmQ0A4IAL1ir8w5bMCkrQL67jWSnCVm
dmmOsajAX4hqmXSYZrBv/eBfghM8FO/z8v8LguDpO/b1lXU97Bm1S256X6gBfcC7
25a0sdaUvwiXfj77r323oGlvs2MKFAkMZ85ERNVhjmluBT58Yk7/fpiRY4pS6vzg
L2Gp3INixXYMxcniiel+blGPFyp6IAWIxZs09e7SkUIEqTu4DZu9PijmuoW/66Uu
dIstLZigDf1naUevRvf1ebIONoPwx8EF502n97NaVsmNRooA2hnuPKQ6Fc9WptYy
ih9sGw/HIhPmsPwAOcrYrlMglOVft6k8bMEPpf0vKKlP54MJI8NPf4rfqNzT+4k=
=pk+7
-----END PGP SIGNATURE-----
Merge tag 'at91-cleanup' of git://github.com/at91linux/linux-at91 into next/soc
Merge "at91: cleanup for 3.16 #1" from Nicolas Ferre:
First cleanup series for 3.15
- localize GPIO header in mach-at91 directory
- big update on the CCF front with main and slow clocks
- a cleanup of ADC and touchscreen driver with unification on IIO and
removal of old driver
[olof: Most of this branch is new code, not cleanups, so I'm merging this into
the SoC branch in spite of the branch name]
* tag 'at91-cleanup' of git://github.com/at91linux/linux-at91: (28 commits)
ARM: at91/dt: at91-cosino_mega2560 remove useless tsadcc node
ARM: at91: remove atmel_tsadcc platform_data
Input: atmel_tsadcc: remove driver
ARM: at91: remove atmel_tsadcc from sama5_defconfig
ARM: at91: sam9rl: switch from atmel_tsadcc to at91_adc
ARM: at91: sam9g45: switch from atmel_tsadcc to at91_adc
ARM: at91: sam9rlek add touchscreen support through at91_adc
ARM: at91: sam9rl: add at91_adc to support adc and touchscreen
iio: adc: at91: add sam9rl support
iio: adc: at91: remove unused include from include/mach
ARM: at91: sam9m10g45ek: Add touchscreen support through at91_adc
iio: adc: at91_adc: Add support for touchscreens without TSMR
iio: adc: at91: cleanup platform_data
ARM: at91: sam9260: remove unused platform_data
ARM: at91: sam9g45: remove unused platform_data
ARM: at91/dt: define sam9rlek crystal frequencies
ARM: at91/dt: move at91sam9rl SoC to the new slow/main clock models
ARM: at91/dt: define main xtal frequency of the at91sam9261ek board
ARM: at91/dt: move at91sam9261 SoC to the new main clock model
ARM: at91/dt: add xtal frequencies to sama5d3 xplained board
...
Signed-off-by: Olof Johansson <olof@lixom.net>
Mostly DTS additions to the SOCFPGA platform from Steffan Trumtrar, and a
couple of device tree documentation updates/typo fix.
This one does not the GPIO binding patch, as that is pending further
discussion. Also, v3 fixes a rebase artifact and compile tested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJTaFnlAAoJEBmUBAuBoyj06AEP/2mrqDlhxSalLTB2GM8dzwsK
6eVTeP1LTGmfV+qmMez5zW83z/+1tw8Ime3Z46mdvr4ORu1vynz8RQ//jb5d5366
JBms9E68vRHbmJXS3PJ9u9VegaKePKePV7NuoA6G9WtlAItPdLTrYLyuBIIiSwJP
XLBPz33xUdeJBoMRGI44C4pOiL/icsOC12jmH5M61CzxrhhMX6I8qEJnF2hC6mhk
S5fnGmt649pKR4sgfLrk4DE2yzemy6qfb+dSXw1K1HrnOlZDKUmhtj18dQNIVpQX
K3b1kxrlIxOe1/m5pBadk8cBiKeJEJO65iNvWnimAw+x7KGRcDKaiZLSsuGG1rKH
W54rbJrY4XOFssHq4IRiJ6YO5mIPpJw6pgCrWSdHKg4Shni0muymdBkZmB4Rvxm6
uWXon8X0tMEZjaJ5jjZaNYNxIiRkxtOo0+x6WwXyBy/x6aIZtSh8r4wNlPS85AFQ
f7hNBslQ5YhatvuqJj8b1VIG6cMtAqOwUOk/xx64VmBMf/zkXZk1PE8pbnvCzBkd
22yLb/JWYBE+rA+kQ78o8Aj8cwrajezOkEm0G2WV26ie2gG6Qmd8W/hqm83/1TFV
9SyaomV3KXKjBf/KJGr9vYf/t293Kvw9zDpx8PfOM4BKiuuwZ3zoHQ+CkknBvzYX
ckvge60rWGdynGiAFJ3f
=4CDi
-----END PGP SIGNATURE-----
Merge tag 'socfpga-dt-updates-for-3.16_v3' of git://git.rocketboards.org/linux-socfpga-next into next/dt
Merge "dts: socfpga: general updates for the socfpga platform" from Dinh
Nguyen:
Mostly DTS additions to the SOCFPGA platform from Steffan Trumtrar, and a
couple of device tree documentation updates/typo fix.
This one does not the GPIO binding patch, as that is pending further
discussion. Also, v3 fixes a rebase artifact and compile tested.
* tag 'socfpga-dt-updates-for-3.16_v3' of git://git.rocketboards.org/linux-socfpga-next:
ARM: socfpga: dts: Add div-reg to the main_pll clocks
ARM: socfpga: dts: add reset-controller
Documentation: dt: reset: move socfpga-reset
Documentation: dt: socfpga: add reset-cells property
ARM: socfpga: dts: Add DTS entries for USB
ARM: socfpga: dts: Remove hard coded clock-frequency property
ARM: socfpga: dts: add eeprom and rtc on i2c0
ARM: socfpga: dts: convert to preprocessor includes
ARM: socfpga: dts: add rtc on i2c0 to socrates
ARM: socfpga: dts: add support for EBV SOCrates
ARM: socfpga: dts: add can0+1
ARM: socfpga: dts: add i2c busses
ARM: socfpga: dts: add remaining interrupts for pdma
ARM: socfpga: dts: fix pdma interrupt
Signed-off-by: Olof Johansson <olof@lixom.net>
The 802.15.4-2011 standard states that for each key, a list of devices
that use this key shall be kept. Previous patches have only considered
two options:
* a device "uses" (or may use) all keys, rendering the list useless
* a device is restricted to a certain set of keys
Another option would be that a device *may* use all keys, but need not
do so, and we are interested in the actual set of keys the device uses.
Recording keys used by any given device may have a noticable performance
impact and might not be needed as often. The common case, in which a
device will not switch keys too often, should still perform well.
Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds user-visible interfaces for the llsec infrastructure.
For the added methods, the only major difference between all add/remove
implementation lies in how the specific object is parsed, and for dump
requests, how objects are written into netlink messages.
To save on boilerplate code, table dumps are routed through a helper
function that handles netlink dump state, leaving the actual dumping
code to care only about iterating over the table to be dumped and
filling netlink messages. For add/remove methods, the boilerplate
required to work is not quite as large, but still enough to also move
into a local helper.
Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
