| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
into regmap-next
|
|
Merge reason: Update from an ancient -rc1 base to an almost-final stable kernel.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
A runtime suspend of a device (e.g. an MMC controller) belonging to
a power domain or, in a more complicated scenario, a runtime suspend
of another device in the same power domain, may cause power to be
removed from the entire domain. In that case, the amount of time
necessary to runtime-resume the given device (e.g. the MMC
controller) is often substantially greater than the time needed to
run its driver's runtime resume callback. That may hurt performance
in some situations, because user data may need to wait for the
device to become operational, so we should make it possible to
prevent that from happening.
For this reason, introduce a new sysfs attribute for devices,
power/pm_qos_resume_latency_us, allowing user space to specify the
upper bound of the time necessary to bring the (runtime-suspended)
device up after the resume of it has been requested. However, make
that attribute appear only for the devices whose drivers declare
support for it by calling the (new) dev_pm_qos_expose_latency_limit()
helper function with the appropriate initial value of the attribute.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
|
For files that are actively using linux/device.h, make sure
that they call it out. This will allow us to clean up some
of the implicit uses of linux/device.h within include/*
without introducing build regressions.
Yes, this was created by "cheating" -- i.e. the headers were
cleaned up, and then the fallout was found and fixed, and then
the two commits were reordered. This ensures we don't introduce
build regressions into the git history.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
[Fix for breakage which will be introduced during the merge window via
header reworks in another tree, the regmap tree does include device.h
but Paul's tree breaks that. Reworded subject to reflect -- broonie]
regmap.s uses devres_alloc() and others that are prototyped in device.h.
Include that to solve the following:
drivers/base/regmap/regmap.c: In function 'devm_regmap_init':
drivers/base/regmap/regmap.c:331:2: error: implicit declaration of function 'devres_alloc' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c:338:3: error: implicit declaration of function 'devres_add' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c:340:3: error: implicit declaration of function 'devres_free' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c: In function '_regmap_raw_write':
drivers/base/regmap/regmap.c:421:5: error: implicit declaration of function 'dev_err' [-Werror=implicit-function-declaration]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This was done to resolve a conflict in the drivers/base/cpu.c file.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The PowerPC legacy iSeries plateform is being removed along with the
"one looney iseries driver", so this code can now be removed as well.
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Came in in the deferred probe patch, quick, clean them up before a
kernel janitor finds them and sends me 4 individual patches to fix them
up...
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Nothing outside of the driver core needs to get to the deferred probe
pointer, so move it inside the private area of 'struct device' so no one
tries to mess around with it.
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Allow drivers to report at probe time that they cannot get all the resources
required by the device, and should be retried at a later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
mucking about with initcall ordering which is a complete hack, and
doesn't even remotely handle the case where device drivers are in
modules. This approach completely sidesteps the issues by allowing
driver registration to occur in any order, and any driver can request
to be retried after a few more other drivers get probed.
v4: - Integrate Manjunath's addition of a separate workqueue
- Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
- Update comment blocks to reflect how the code really works
v3: - Hold off workqueue scheduling until late_initcall so that the bulk
of driver probes are complete before we start retrying deferred devices.
- Tested with simple use cases. Still needs more testing though.
Using it to get rid of the gpio early_initcall madness, or to replace
the ASoC internal probe deferral code would be ideal.
v2: - added locking so it should no longer be utterly broken in that regard
- remove device from deferred list at device_del time.
- Still completely untested with any real use case, but has been
boot tested.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dilan Lee <dilee@nvidia.com>
Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: David Daney <david.daney@cavium.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Otherwise we'll end up running with bogus register numbers.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Most of the current users have register 0 as a volatile register or don't
have a register 0 so it's not been apparent that it's not getting synced.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
* pm-domains:
PM / Domains: Fix include for PM_GENERIC_DOMAINS=n case
PM / Domains: Provide a dummy dev_gpd_data() when generic domains are not used
PM / Domains: Run late/early device suspend callbacks at the right time
ARM: EXYNOS: Hook up power domains to generic power domain infrastructure
PM / Domains: Add OF support
|
|
* pm-sleep:
PM / Freezer: Remove references to TIF_FREEZE in comments
PM / Sleep: Add more wakeup source initialization routines
PM / Hibernate: Enable usermodehelpers in hibernate() error path
PM / Sleep: Make __pm_stay_awake() delete wakeup source timers
PM / Sleep: Fix race conditions related to wakeup source timer function
PM / Sleep: Fix possible infinite loop during wakeup source destruction
PM / Hibernate: print physical addresses consistently with other parts of kernel
PM: Add comment describing relationships between PM callbacks to pm.h
PM / Sleep: Drop suspend_stats_update()
PM / Sleep: Make enter_state() in kernel/power/suspend.c static
PM / Sleep: Unify kerneldoc comments in kernel/power/suspend.c
PM / Sleep: Remove unnecessary label from suspend_freeze_processes()
PM / Sleep: Do not check wakeup too often in try_to_freeze_tasks()
PM / Sleep: Initialize wakeup source locks in wakeup_source_add()
PM / Hibernate: Refactor and simplify freezer_test_done
PM / Hibernate: Thaw kernel threads in hibernation_snapshot() in error/test path
PM / Freezer / Docs: Document the beauty of freeze/thaw semantics
PM / Suspend: Avoid code duplication in suspend statistics update
PM / Sleep: Introduce generic callbacks for new device PM phases
PM / Sleep: Introduce "late suspend" and "early resume" of devices
|
|
The existing wakeup source initialization routines are not
particularly useful for wakeup sources that aren't created by
wakeup_source_create(), because their users have to open code
filling the objects with zeros and setting their names. For this
reason, introduce routines that can be used for initializing, for
example, static wakeup source objects.
Requested-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If __pm_stay_awake() is called after __pm_wakeup_event() for the same
wakep source object before its timer expires, it won't cancel the
timer, so the wakeup source will be deactivated from the timer
function as scheduled by __pm_wakeup_event(). In that case
__pm_stay_awake() doesn't have any effect beyond incrementing
the wakeup source's event_count field, although it should cancel
the timer and make the wakeup source stay active until __pm_relax()
is called for it.
To fix this problem make __pm_stay_awake() delete the wakeup source's
timer and ensure that it won't be deactivated from the timer funtion
afterwards by clearing its timer_expires field.
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If __pm_wakeup_event() has been used (with a nonzero timeout) to
report a wakeup event and then __pm_relax() immediately followed by
__pm_stay_awake() is called or __pm_wakeup_event() is called once
again for the same wakeup source object before its timer expires, the
timer function pm_wakeup_timer_fn() may still be run as a result of
the previous __pm_wakeup_event() call. In either of those cases it
may mistakenly deactivate the wakeup source that has just been
activated.
To prevent that from happening, make wakeup_source_deactivate()
clear the wakeup source's timer_expires field and make
pm_wakeup_timer_fn() check if timer_expires is different from zero
and if it's not in future before calling wakeup_source_deactivate()
(if timer_expires is 0, it means that the timer has just been
deleted and if timer_expires is in future, it means that the timer
has just been rescheduled to a different time).
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If wakeup_source_destroy() is called for an active wakeup source that
is never deactivated, it will spin forever. To prevent that from
happening, make wakeup_source_destroy() call __pm_relax() for the
wakeup source object it is about to free instead of waiting until
it will be deactivated by someone else. However, for this to work
it also needs to make sure that the timer function will not be
executed after the final __pm_relax(), so make it run
del_timer_sync() on the wakeup source's timer beforehand.
Additionally, update the kerneldoc comment to document the
requirement that __pm_stay_awake() and __pm_wakeup_event() must not
be run in parallel with wakeup_source_destroy().
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
Remove unused module.h and/or replace with export.h
as required.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Provide a regcache_sync_region() operation which allows drivers to
write only part of the cache back to the hardware. This is intended
for use in cases like power domains or DSP memories where part of the
device register map may be reset without fully resetting the device.
Fully supporting these devices is likely to require additional work to
make specific regions of the register map cache only while they are in
reset, but this is enough for most devices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
In order to allow us to support partial sync operations add minimum and
maximum register arguments to the sync operation and update the rbtree
and lzo caches to use this new information. The LZO implementation is
obviously not good, we could exit the iteration earlier, but there may
be room for more wide reaching optimisation there.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Useful for figuring out where the hardware interaction went or came from.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Previously the cache would never be marked clean, meaning syncs would
never be suppressed which isn't the end of the world but could be
inefficient.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
It's not used as all cache types have sync operations so it's just dead
code which never gets tested.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Saves some I/O when resyncing; we assume that syncs start from the device
reset state.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Add a file called 'name' containing the name of the driver.
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
To enable writing to the regmap debugfs registers file users will
need to modify the source directly and #define REGMAP_ALLOW_WRITE_DEBUGFS.
The reason for this is that it is dangerous to expose this
functionality in general where clients could potentially be PMICs.
[A couple of minor style updates -- broonie]
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into HEAD
New interfaces to allow other subsystems to gather information about the
regmap, allowing them to build further subsystem specific generic
features on top of the regmap.
Merged into ASoC in order to allow us to implement SND_SOC_BYTES_MASK()
controls which need to know the word size of the underlying registers.
|
|
Fall back to a register by register read to do so; most likely we'll be
cache only so the overhead will be low.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into regmap-drivers
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into regmap-drivers
|
|
Generic infrastructure based on top of regmap may want to operate on
blocks of data and therefore find it useful to find the size of the
register values. Provide an accessor operation for this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
resolved below within the FSI driver and allow the application of the
dmaeengine conversion that depends on this resolution.
Linux 3.3-rc4
Conflicts:
sound/soc/sh/fsi.c
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Fixes a bootstrapping issue for some registers when a less commonly used
method for register cache initialisation is used. Only affects a fairly
small proportion of users that both don't use explicit register defaults
and do use the cache.
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Fix cache defaults initialization from raw cache defaults
|
|
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
During regcache_init, if client has not passed the
default data of cached register then it is directly
read from the hw to initialize cache. This hw register
read happens before cache ops are initialized and hence
avoiding register read to check for the data available
on cache or not by enabling flag of cache_bypass.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Currently registers with a value of 0 are ignored when initializing the register
defaults from raw defaults. This worked in the past, because registers without a
explicit default were assumed to have a default value of 0. This was changed in
commit b03622a8 ("regmap: Ensure rbtree syncs registers set to zero properly").
As a result registers, which have a raw default value of 0 are now assumed to
have no default. This again can result in unnecessary writes when syncing the
cache. It will also result in unnecessary reads for e.g. the first update
operation. In the case where readback is not possible this will even let the
update operation fail, if the register has not been written to before.
So this patch removes the check. Instead it adds a check to ignore raw defaults
for registers which are volatile, since those registers are not cached.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
|
|
The bulk_write() supports the data transfer to multi
register which takes the data into cpu_endianness format
and does formatting of data to device format before
sending to device.
The transfer can be completed in single transfer or multiple
transfer based on data formatting.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Initialize wakeup source locks in wakeup_source_add() instead of
wakeup_source_create(), because otherwise the locks of the wakeup
sources that haven't been allocated with wakeup_source_create()
aren't initialized and handled properly.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
Adding support for caching of data into the
non-volatile register from the call of reg_raw_write().
This will allow the larger block of data write into multiple
register without worrying whether register is cached or not
through reg_raw_write().
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Traditionally, any System-on-Chip based platform creates a flat list
of platform_devices directly under /sys/devices/platform.
In order to give these some better structure, this introduces a new
bus type for soc_devices that are registered with the new
soc_device_register() function. All devices that are on the same
chip should then be registered as child devices of the soc device.
The soc bus also exports a few standardised device attributes which
allow user space to query the specific type of soc.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Due to the sysdev conversion to struct device, the cpu objects get
reused when adding a cpu after offlining it, which causes a big warning
that the kobject portion is not properly initialized.
So clear out the object before we register it again, so all is quiet.
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Show all the cache status flags in debugfs if we have a cache.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This was a cut'n'paste from some older code.
Since we're about to add debugfs support don't do the obvious thing and
use bool, use u32 instead (which debugfs has been using since time
immemorial).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
One system with 2048g ram, reported soft lockup on recent kernel.
[ 34.426749] cpu_dev_init done
[ 61.166399] BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]
[ 61.166733] Modules linked in:
[ 61.166904] irq event stamp: 1935610
[ 61.178431] hardirqs last enabled at (1935609): [<ffffffff81ce8c05>] mutex_lock_nested+0x299/0x2b4
[ 61.178923] hardirqs last disabled at (1935610): [<ffffffff81cf2bab>] apic_timer_interrupt+0x6b/0x80
[ 61.198767] softirqs last enabled at (1935476): [<ffffffff8106e59c>] __do_softirq+0x195/0x1ab
[ 61.218604] softirqs last disabled at (1935471): [<ffffffff81cf359c>] call_softirq+0x1c/0x30
[ 61.238408] CPU 0
[ 61.238549] Modules linked in:
[ 61.238744]
[ 61.238825] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc1-tip-yh-02076-g962f689-dirty #171
[ 61.278212] RIP: 0010:[<ffffffff810b3e3a>] [<ffffffff810b3e3a>] lock_release+0x90/0x9c
[ 61.278627] RSP: 0018:ffff883f64dbfd70 EFLAGS: 00000246
[ 61.298287] RAX: ffff883f64dc0000 RBX: 0000000000000000 RCX: 000000000000008b
[ 61.298690] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 61.318383] RBP: ffff883f64dbfda0 R08: 0000000000000001 R09: 000000000000008b
[ 61.338215] R10: 0000000000000000 R11: 0000000000000000 R12: ffff883f64dbfd10
[ 61.338610] R13: ffff883f64dc0708 R14: ffff883f64dc0708 R15: ffffffff81095657
[ 61.358299] FS: 0000000000000000(0000) GS:ffff883f7d600000(0000) knlGS:0000000000000000
[ 61.378118] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 61.378450] CR2: 0000000000000000 CR3: 00000000024af000 CR4: 00000000000007f0
[ 61.398144] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 61.417918] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 61.418260] Process swapper/0 (pid: 1, threadinfo ffff883f64dbe000, task ffff883f64dc0000)
[ 61.445358] Stack:
[ 61.445511] 0000000000000002 ffff897f649ba168 ffff883f64dbfe10 ffff88ff64bb57a8
[ 61.458040] 0000000000000000 0000000000000000 ffff883f64dbfdc0 ffffffff81ceb1b4
[ 61.458491] 000000000011608c ffff88ff64bb58a8 ffff883f64dbfdf0 ffffffff81c57638
[ 61.478215] Call Trace:
[ 61.478367] [<ffffffff81ceb1b4>] _raw_spin_unlock+0x21/0x2e
[ 61.497994] [<ffffffff81c57638>] klist_next+0x9e/0xbc
[ 61.498264] [<ffffffff8148ba99>] next_device+0xe/0x1e
[ 61.517867] [<ffffffff8148c0cc>] subsys_find_device_by_id+0xb7/0xd6
[ 61.518197] [<ffffffff81498846>] find_memory_block_hinted+0x3d/0x66
[ 61.537927] [<ffffffff8149887f>] find_memory_block+0x10/0x12
[ 61.538193] [<ffffffff814988b6>] add_memory_section+0x35/0x9e
[ 61.557932] [<ffffffff827fecef>] memory_dev_init+0x68/0xda
[ 61.558227] [<ffffffff827fec01>] driver_init+0x97/0xa7
[ 61.577853] [<ffffffff827cdf3c>] kernel_init+0xf6/0x1c0
[ 61.578140] [<ffffffff81cf34a4>] kernel_thread_helper+0x4/0x10
[ 61.597850] [<ffffffff81ceb59d>] ? retint_restore_args+0xe/0xe
[ 61.598144] [<ffffffff827cde46>] ? start_kernel+0x3ab/0x3ab
[ 61.617826] [<ffffffff81cf34a0>] ? gs_change+0xb/0xb
[ 61.618060] Code: 10 48 83 3b 00 eb e8 4c 89 f2 44 89 fe 4c 89 ef e8 e1 fe ff ff 65 48 8b 04 25 40 bc 00 00 c7 80 cc 06 00 00 00 00 00 00 41 54 9d <5e> 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 89 cf
[ 89.285380] memory_dev_init done
Finally it takes about 55s to create 16400 memory entries.
Root cause: for x86_64, 2048g (with 2g hole at [2g,4g), and TOP2 will be 2050g), will have 16400 memory block.
find_memory_block/subsys_find_device_by_id will be expensive with that many entries.
Actually, we don't need to find that memory block for BOOT path.
Skip that finding make it get back to normal.
[ 34.466696] cpu_dev_init done
[ 35.290080] memory_dev_init done
Also solved the delay with topology_init when sections_per_block is not 1.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Nathan Fontenot <nfont@austin.ibm.com>
Cc: Robin Holt <holt@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This was done to resolve a merge and build problem with the
drivers/acpi/processor_driver.c file.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
With the movement of the cpu sysdev code to be real stuct devices, now
when we remove a cpu from the system, the driver core rightfully
complains that there is not a release method for this device.
For now, paper over this issue by quieting the driver core, but comment
this in detail. This will be resolved in future kernels to be solved
properly.
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When userspace needs to find a specific device, it currently isn't easy to
resolve a /sys/devices/ path from a specific device tree node. Nor is it
easy to obtain the compatible list for devices.
This patch generalizes the code that inserts OF_* values into the uevent
device attribute so that any device that is attached to an OF node will
have that information exported to userspace. Without this patch only
platform devices and some powerpc-specific busses have access to this
data.
The original function also creates a MODALIAS property for the compatible
list, but that code has not been generalized into the common case because
it has the potential to break module loading on a lot of bus types. Bus
types are still responsible for their own MODALIAS properties.
Boot tested on ARM and compile tested on PowerPC and SPARC.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: Frederic Lambert <frdrc66@gmail.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Mark Brown <broonie@sirena.org.uk>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
