Jon Maloy says:
====================
tipc: some improvements and fixes
We introduce a better algorithm for selecting when and which
users should be subject to link congestion control, plus clean
up some code for that mechanism.
Commit #3 fixes another rare race condition during packet reception.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Despite recent improvements, the establishment of dual parallel
links still has a small glitch where messages can bypass each
other. When the second link in a dual-link configuration is
established, part of the first link's traffic will be steered over
to the new link. Although we do have a mechanism to ensure that
packets sent before and after the establishment of the new link
arrive in sequence to the destination node, this is not enough.
The arriving messages will still be delivered upwards in different
threads, something entailing a risk of message disordering during
the transition phase.
To fix this, we introduce a synchronization mechanism between the
two parallel links, so that traffic arriving on the new link cannot
be added to its input queue until we are guaranteed that all
pre-establishment messages have been delivered on the old, parallel
link.
This problem seems to always have been around, but its occurrence is
so rare that it has not been noticed until recent intensive testing.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After the recent changes in message importance handling it becomes
possible to simplify handling of messages and sockets when we
encounter link congestion.
We merge the function tipc_link_cong() into link_schedule_user(),
and simplify the code of the latter. The code should now be
easier to follow, especially regarding return codes and handling
of the message that caused the situation.
In case the scheduling function is unable to pre-allocate a wakeup
message buffer, it now returns -ENOBUFS, which is a more correct
code than the previously used -EHOSTUNREACH.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Master change notifications may occur other than when joining or
leaving a bridge, for example when being added to or removed from
a bond or Open vSwitch. In that case, do nothing instead of asking
the switch driver to remove a port from a bridge that it didn't join.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some Toshiba laptops with the "Special Functions" feature enabled
fail to properly enable such feature unless a specific value is
used to enable the hotkey events.
This patch adds a new function called "*_enable_special_functions",
that simply makes a call to the HCI_HOTKEY_EVENT call, but this time
we are using a different parameter to make the "Special Functions"
mode work as expected.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
With the previous patch adding support to "Hotkey Event Type", we can
now use the type to distinguish which keymap to use.
This patch changes the toshiba_acpi_setup_keyboard function to make
use of the hotkey event type to choose the correct keymap without the
need to use the DMI matching list.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This patch adds support to query the "Hotkey Event Type" the system
supports.
There are two main event types (so far), 0x10 and 0x11, with the
first being all those laptops that have the old keyboard layout, and
the latter all those new laptops with the new keyboard layout.
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
In commit bff431e49f ("ACPI: WMI: Add
ACPI-WMI mapping driver") this mutex was added, but the rest of the
final commit never actually made use of it, resulting in:
In file included from include/linux/mutex.h:29:0,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from drivers/platform/x86/wmi.c:35:
drivers/platform/x86/wmi.c:48:21: warning: ‘wmi_data_lock’ defined but not used [-Wunused-variable]
static DEFINE_MUTEX(wmi_data_lock);
^
A git grep shows no other instances/references to the wmi_data_lock.
Delete it, assuming that the mutex addition was just a leftover from
an earlier work in progress version of the change, since the original
dates from 2008.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
The faulting virtual address is >32bits and has been moved
to different registers. Add to error state and output upper
register first, in the same line for easy reconstruction of
the fault address.
v2: correct gen masking (Michel)
v3: s/TBL/TLB (Ville)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It should have been negative since it is returned with ERR_PTR().
Introduced in new code commit:
commit 50470bb011
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Mar 23 11:10:36 2015 +0000
drm/i915/skl: Support secondary (rotated) frame buffer mapping
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Or users can just spam the log all they want.
Issue introduced in
commit 9a8f0a1290
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Fri Feb 27 11:15:24 2015 +0000
drm/i915/skl: Allow Y (and Yf) frame buffer creation
References: https://bugs.freedesktop.org/show_bug.cgi?id=89628
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some Bluetooth controllers require initialization before being
used (vendor config, firmware download). Add possibility for a
HCI UART proto to implement this early init via the setup callback.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The set implementations' private struct will only contain the elements
needed to maintain the search structure, all other elements are moved
to the set extensions.
Element allocation and initialization is performed centrally by
nf_tables_api instead of by the different set implementations'
->insert() functions. A new "elemsize" member in the set ops specifies
the amount of memory to reserve for internal usage. Destruction
will also be moved out of the set implementations by a following patch.
Except for element allocation, the patch is a simple conversion to
using data from the extension area.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Add simple set extension infrastructure for maintaining variable sized
and optional per element data.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
A following patch will convert sets to use so called set extensions,
where the key is not located in a fixed position anymore. This will
require rhashtable hashing and comparison callbacks to be used.
As preparation, convert nft_hash to use these callbacks without any
functional changes.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Improve readability by indenting the parameter initialization.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Following patches will add new private members, restore struct nft_hash
as preparation.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
nftables sets will be converted to use so called setextensions, moving
the key to a non-fixed position. To hash it, the obj_hashfn must be used,
however it so far doesn't receive the length parameter.
Pass the key length to obj_hashfn() and convert existing users.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Add a new function iommu_context_addr() which takes care of the
differences and returns a pointer to a context entry which may be
in either format. The formats are binary compatible for all the old
fields anyway; the new one is just larger and some of the reserved
bits in the original 128 are now meaningful.
So far, nothing actually uses the new fields in the extended context
entry. Modulo hardware bugs with interpreting the new-style tables,
this should basically be a no-op.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Fixes below warning by dynamically allocating memory
All warnings:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c: In function
'cctrl_tbl_show':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c:689:1: warning: the
>> frame
>> size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change type from unsigned long to int to fix an issue reported by kbuild robot:
crypto/algif_skcipher.c:596 skcipher_recvmsg_async() warn: unsigned 'used' is
never less than zero.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a node joins a cluster while we are transmitting a fragment
stream over the broadcast link, it's missing the preceding fragments
needed to build a meaningful message. As a result, the node has to
drop it. However, as the fragment message is not acknowledged to
its sender before it's dropped, it accidentally causes link reset
of retransmission failure on the node.
Reported-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The irqclass_sub_desc array and enum interruption_class are out of sync
thus /proc/interrupts is broken. Remove IRQIO_CLW.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A local route may have a lower hop_limit set than global routes do.
RFC 3756, Section 4.2.7, "Parameter Spoofing"
> 1. The attacker includes a Current Hop Limit of one or another small
> number which the attacker knows will cause legitimate packets to
> be dropped before they reach their destination.
> As an example, one possible approach to mitigate this threat is to
> ignore very small hop limits. The nodes could implement a
> configurable minimum hop limit, and ignore attempts to set it below
> said limit.
Signed-off-by: D.S. Ljungmark <ljungmark@modio.se>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Move the declaration for external variables to sctp.h file avoiding
to repeatedly declare them with extern keyword.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Great for easily determining which mode a pin is operating in.
This patch was particularly helpful when debugging a recent GPIO/
Pinctrl disparity issue.
Before:
$ cat /sys/kernel/debug/pinctrl/<pin-controller>/pinconf-pins
pin 33 (PIO4[1]):[OE:0,PU:0,OD:0]
[retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]
After [GPIO]:
$ cat /sys/kernel/debug/pinctrl/<pin-controller>/pinconf-pins
pin 33 (PIO4[1]):[OE:0,PU:0,OD:0] GPIO
[retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]
After [Alt]:
$ cat /sys/kernel/debug/pinctrl/<pin-controller>/pinconf-pins
pin 33 (PIO4[1]):[OE:0,PU:0,OD:0] Alt Fn 2
[retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Until now ST's pinconf_dbg_show() call-back has displayed the PIO
alternate function direction, which is only relevant if a pin is
operating in an alternate function mode i.e not GPIO mode. If a
pin is in GPIO mode its direction is both set and status is
obtained by a completely different/unrelated bunch of registers.
This change ensures that the correct pin direction is shown, even
if a pin is operating in GPIO mode.
Reported-by: Olivier Clergeaud <olivier.clergeaud@st.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ST's hardware differentiates between GPIO mode and Pinctrl alternate
functions. When a pin is in GPIO mode, there are dedicated registers
to set and obtain direction status. However, If a pin's alternate
function is in use then the direction is set and status is derived
from a bunch of syscon registers. The issue is; until now there was
a lack of parity between the two.
For example:
Catting the two following information sources could result in
conflicting information (output has been snipped for simplicity):
$ cat /sys/kernel/debug/gpio
GPIOs 32-39, platform/961f080.pin-controller-sbc, PIO4:
gpio-33 (? ) out hi
$ cat /sys/kernel/debug/pinctrl/<pin-controller>/pinconf-pins
pin 33 (PIO4[1]):[OE:0,PU:0,OD:0]
[retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]
In this example GPIO-33 is a GPIO controlled LED, which is set for
output, as you'd expect. However, when the same information is
drafted from Pinctrl, it clearly states that OE (Output Enable) is
not set i.e. the pin is set for input. This is because OE normally
only represents alternate functions and has no bearing on how the
pin operates when in Alt-0 (GPIO mode).
This patch changes the current semantics and provides a parity link
between the two subsystems. The get_direction() call-back firstly
determines which function a pin is operating in, then uses the
appropriate helpers for that mode.
Reported-by: Olivier Clergeaud <olivier.clergeaud@st.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
domains") prevents certain options for devices with RMRRs. This even
prevents those devices from getting a 1:1 mapping with 'iommu=pt',
because we don't have the code to handle *preserving* the RMRR regions
when moving the device between domains.
There's already an exclusion for USB devices, because we know the only
reason for RMRRs there is a misguided desire to keep legacy
keyboard/mouse emulation running in some theoretical OS which doesn't
have support for USB in its own right... but which *does* enable the
IOMMU.
Add an exclusion for graphics devices too, so that 'iommu=pt' works
there. We should be able to successfully assign graphics devices to
guests too, as long as the initial handling of stolen memory is
reconfigured appropriately. This has certainly worked in the past.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@vger.kernel.org
st_get_pio_control() will be used by subsequent calls which are
to be located above its original position. This is required to
prevent the need for an unnecessary forward-declaration/prototype.
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
BIOS can set up x2apic_opt_out bit on some platforms, for various misguided
reasons like insane SMM code with weird assumptions about what descriptors
look like, or wanting Windows not to enable the IOMMU so that the graphics
driver will take it over for SVM in "driver mode".
A user can either disable the x2apic_opt_out bit in BIOS or by kernel
parameter "no_x2apic_optout". Instead of printing a warning, we just
print information of x2apic opt out.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This call fetches the numerical function value a specified pin is
currently operating in. Function zero is more often than not the
GPIO function. Greater than zero values represent an alternative
function. You'd need to either look those up in the Device Tree
sources or the Programmer's Manual.
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As far back as I can see (which right now is a draft of the v1.2 spec
dating from September 2008), bits 24-31 of the Extended Capability Register
have already been reserved. I have no idea why anyone ever thought there
would be multiple sets of IOTLB registers, but we've never supported them
and all we do is make sure we map enough MMIO space for them.
Kill it dead. Those bits do actually have a different meaning now.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The Quark SoC data sheet describes the baud rate setting using fractional
divider. The subset of possible values represented by a table suggests that the
divisor has one block that could divide by 5. This explains the number of the
beast in some cases in the table. Thus, in this particular case the divisor can
be evaluated as
5^i * 2^j * 2 * k,
where
i = [0, 1]
j = [0, 23]
k = [1, 256]
There are few cases as mentioned in the data sheet, i.e. better form of the
clock signal will be in case if DDS_CLK_RATE either 2^n or 2/5. It's also
possible to use any value that is less or equal to 0x33333 (1/5/16 = 1/80).
All three cases are compared to each other and the one that suits better is
chosen by the approximation algorithm. Anyone can play with the script [1] that
represents the algorithm.
[1] https://gist.github.com/06b084488b3629898121
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The WM8741 DAC supports the following typical audio sampling rates:
44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz)
32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz)
For the rates lists, we should use 82000 instead of 88235, 176400
instead of 1764000 and 192000 instead of 19200 (seems to be a typo).
Signed-off-by: Sergej Sawazki <ce3a@gmx.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
commit c66150824b ("ASoC: dapm: add code to configure dai link
parameters") introduced the following build warning:
sound/soc/soc-dapm.c: In function 'snd_soc_dapm_new_pcm':
sound/soc/soc-dapm.c:3389:4: warning: passing argument 1 of 'snprintf'
discards 'const' qualifier from pointer target type
snprintf(w_param_text[count], len,
This patch fixes this by switching to using devm_kasprintf. This also
saves a couple of lines of code.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This mouse is also known under other IDs. It needs the quirk or will disconnect
in runlevel 1 or 3.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order
to avoid attaching a TTY to the JTAG port as this board is based on the
CALAO Systems reference design and needs the same fix up.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
CC: stable <stable@vger.kernel.org>
[johan: clean up probe logic ]
Signed-off-by: Johan Hovold <johan@kernel.org>
The seq_printf return value, because it's frequently misused,
will eventually be converted to void.
See: commit 1f33c41c03 ("seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public")
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's no reason to allocate the dec{32,64}table on the stack; it
just wastes a bunch of instructions setting them up and, of course,
also consumes quite a bit of stack. Using size_t for such small
integers is a little excessive.
$ scripts/bloat-o-meter /tmp/built-in.o lib/built-in.o
add/remove: 2/2 grow/shrink: 2/0 up/down: 1304/-1548 (-244)
function old new delta
lz4_decompress_unknownoutputsize 55 718 +663
lz4_decompress 55 632 +577
dec64table - 32 +32
dec32table - 32 +32
lz4_uncompress 747 - -747
lz4_uncompress_unknownoutputsize 801 - -801
The now inlined lz4_uncompress functions used to have a stack
footprint of 176 bytes (according to -fstack-usage); their inlinees
have increased their stack use from 32 bytes to 48 and 80 bytes,
respectively.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes a regression from the net subsystem:
After commit d52fdbb735
"smc91x: retrieve IRQ and trigger flags in a modern way"
a regression would appear on some legacy platforms such
as the ARM PXA Zylonite that specify IRQ resources like
this:
static struct resource r = {
.start = X,
.end = X,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,
};
The previous code would retrieve the resource and parse
the high edge setting in the SMC91x driver, a use pattern
that means every driver specifying an IRQ flag from a
static resource need to parse resource flags and apply
them at runtime.
As we switched the code to use IRQ descriptors to retrieve
the the trigger type like this:
irqd_get_trigger_type(irq_get_irq_data(...));
the code would work for new platforms using e.g. device
tree as the backing irq descriptor would have its flags
properly set, whereas this kind of oldstyle static
resources at no point assign the trigger flags to the
corresponding IRQ descriptor.
To make the behaviour identical on modern device tree
and legacy static platform data platforms, modify
platform_get_irq() to assign the trigger flags to the
irq descriptor when a client looks up an IRQ from static
resources.
Fixes: d52fdbb735 ("smc91x: retrieve IRQ and trigger flags in a modern way")
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently probe deferral prints a message every time a device requests
deferral at info severity (which is displayed by default). This can have
an impact on system boot times with serial consoles and is generally quite
noisy.
Since subsystems and drivers should already be logging the specific reason
for probe deferral in order to aid users in understanding problems the
messages from the driver core should be redundant lower the severity of
the messages printed, cutting down on the volume of output on the console.
This does mean that if the drivers and subsystems aren't doing a good job
we get no output on the console by default. Ideally we'd be able to arrange
to print if nothing else printed, though that's a little fun. Even better
would be to come up with a mechanism that explicitly does dependencies so
we don't have to keep polling and erroring.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
So I've been annoyed lately with having a bunch of devices such as i2c
eeproms (for use by VPDs, server world !) and other bits and pieces that
I want to be able to identify from userspace, and possibly provide
additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF
tree device node, so that user space can use device-tree info such as
additional "location" or "label" (or whatever else we can come up with)
propreties to identify a given device, or get some attributes of use
about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis
using "devspec" properties. For example, PCI creates them if it can
correlate the probed device with a DT node. Some powerpc specific busses
do that too.
However, i2c doesn't and it would be nice to have something more generic
since technically any device can have a corresponding device tree node.
This patch adds an "of_node" symlink to devices that have a non-NULL
dev->of_node pointer, the patch is pretty trivial and seems to work just
fine for me.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested by Arnd Bergmann, this gives a practical accessor for
the of_node field of struct device while instructing the compiler
that it will be NULL if CONFIG_OF is not set.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
