Re: [PATCH RESEND V2 3/7] scsi: storvsc: Untangle the storage protocol negotiation from the vmbus protocol negotiation.
On Thu, 2015-08-13 at 08:43 -0700, K. Y. Srinivasan wrote:
> From: Keith Mange
>
> Currently we are making decisions based on vmbus protocol versions
> that have been negotiated; use storage potocol versions instead.
>
> Tested-by: Alex Ng
> Signed-off-by: Keith Mange
> Signed-off-by: K. Y. Srinivasan
> ---
> drivers/scsi/storvsc_drv.c | 109
> +++-
> 1 files changed, 87 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5f9d133..f29871e 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -56,14 +56,18 @@
> * V1 RC > 2008/1/31: 2.0
> * Win7: 4.2
> * Win8: 5.1
> + * Win8.1: 6.0
> + * Win10: 6.2
> */
>
> #define VMSTOR_PROTO_VERSION(MAJOR_, MINOR_) MAJOR_) & 0xff) << 8) | \
> (((MINOR_) & 0xff)))
>
> +#define VMSTOR_PROTO_VERSION_WIN6VMSTOR_PROTO_VERSION(2, 0)
> #define VMSTOR_PROTO_VERSION_WIN7VMSTOR_PROTO_VERSION(4, 2)
> #define VMSTOR_PROTO_VERSION_WIN8VMSTOR_PROTO_VERSION(5, 1)
> -
> +#define VMSTOR_PROTO_VERSION_WIN8_1 VMSTOR_PROTO_VERSION(6, 0)
> +#define VMSTOR_PROTO_VERSION_WIN10 VMSTOR_PROTO_VERSION(6, 2)
>
> /* Packet structure describing virtual storage requests. */
> enum vstor_packet_operation {
> @@ -205,6 +209,46 @@ struct vmscsi_request {
>
>
> /*
> + * The list of storage protocols in order of preference.
> + */
> +struct vmstor_protocol {
> + int protocol_version;
> + int sense_buffer_size;
> + int vmscsi_size_delta;
> +};
> +
> +#define VMSTOR_NUM_PROTOCOLS5
> +
> +const struct vmstor_protocol vmstor_protocols[VMSTOR_NUM_PROTOCOLS] = {
Sparse doesn't like this not being static:
CHECK drivers/scsi/storvsc_drv.c
drivers/scsi/storvsc_drv.c:221:30: warning: symbol 'vmstor_protocols'
was not declared. Should it be static?
I fixed it up.
James
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.
Reposting updated version as it turned out that we can call do_send_sig_info()
with task_lock held. ;-) ( http://marc.info/?l=linux-mm&m=144059948628905&w=2 )
Tetsuo Handa wrote:
> Should selected_tasksize be added to rem even when TIF_MEMDIE was not set?
Commit e1099a69a624 "android, lmk: avoid setting TIF_MEMDIE if process
has already exited" changed not to add selected_tasksize to rem. But I
noticed that rem is initialized to 0 and there is only one addition
(i.e. rem += selected_tasksize means rem = selected_tasksize) since
commit 7dc19d5affd7 "drivers: convert shrinkers to new count/scan API".
I don't know what values we should return, but this patch restores
pre commit e1099a69a624 because omitting a call to mark_oom_victim()
due to race will not prevent from reclaiming memory because we already
sent SIGKILL.
>From b7075abd3a1e903e88f1755c68adc017d2125b0d Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 27 Aug 2015 00:13:57 +0900
Subject: [PATCH 2/2] android, lmk: Send SIGKILL before setting TIF_MEMDIE.
It was observed that setting TIF_MEMDIE before sending SIGKILL at
oom_kill_process() allows memory reserves to be depleted by allocations
which are not needed for terminating the OOM victim.
This patch reverts commit 6bc2b856bb7c ("staging: android: lowmemorykiller:
set TIF_MEMDIE before send kill sig"), for oom_kill_process() was updated
to send SIGKILL before setting TIF_MEMDIE.
Signed-off-by: Tetsuo Handa
---
drivers/staging/android/lowmemorykiller.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index d5d25e4..af604cf 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -156,26 +156,21 @@ next:
}
if (selected) {
task_lock(selected);
- if (!selected->mm) {
- /* Already exited, cannot do mark_tsk_oom_victim() */
- task_unlock(selected);
- goto out;
- }
+ lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
+selected->pid, selected->comm,
+selected_oom_score_adj, selected_tasksize);
+ send_sig(SIGKILL, selected, 0);
/*
* FIXME: lowmemorykiller shouldn't abuse global OOM killer
* infrastructure. There is no real reason why the selected
* task should have access to the memory reserves.
*/
- mark_oom_victim(selected);
- lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
-selected->pid, selected->comm,
-selected_oom_score_adj, selected_tasksize);
+ if (selected->mm)
+ mark_oom_victim(selected);
task_unlock(selected);
lowmem_deathpending_timeout = jiffies + HZ;
- send_sig(SIGKILL, selected, 0);
rem += selected_tasksize;
}
-out:
lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
sc->nr_to_scan, sc->gfp_mask, rem);
rcu_read_unlock();
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 11/44] [media] media: use entity.graph_obj.mdev instead of .parent
Em Tue, 25 Aug 2015 13:25:15 -0600 Shuah Khan escreveu: > On Tue, Aug 25, 2015 at 12:36 AM, Hans Verkuil wrote: > > On 08/23/2015 10:17 PM, Mauro Carvalho Chehab wrote: > >> From: Javier Martinez Canillas > >> > >> The struct media_entity has a .parent field that stores a pointer > >> to the parent struct media_device. But recently a media_gobj was > >> embedded into the entities and since struct media_gojb already has > >> a pointer to a struct media_device in the .mdev field, the .parent > >> field becomes redundant and can be removed. > >> > >> This patch replaces all the usage of .parent by .graph_obj.mdev so > >> that field will become unused and can be removed on a later patch. > >> > >> No functional changes. > >> > >> The transformation was made using the following coccinelle spatch: > >> > >> @@ > >> struct media_entity *me; > >> @@ > >> > >> - me->parent > >> + me->graph_obj.mdev > >> > >> @@ > >> struct media_entity *link; > >> @@ > >> > >> - link->source->entity->parent > >> + link->source->entity->graph_obj.mdev > >> > >> @@ > >> struct exynos_video_entity *ve; > >> @@ > >> > >> - ve->vdev.entity.parent > >> + ve->vdev.entity.graph_obj.mdev > >> > >> Suggested-by: Mauro Carvalho Chehab > >> > >> Signed-off-by: Javier Martinez Canillas > >> Signed-off-by: Mauro Carvalho Chehab > > > > Acked-by: Hans Verkuil > > The change looks good to me. I would really like to see a before and after > media graph with these changes, this patch and series in general. Well, it shouldn't change. If something changes, things would be wrong :) Btw, Javier is doing a before/after tests on OMAP3. There are a few fixup things to be added/adjusted (unfortunately, OMAP3 doesn't compile on x86 COMPILE_TEST), but on his tests, the differences between before and after, with media-ctl are zero. As media-ctl is using the legacy API, it shouldn't have any changes there, otherwise something is broken and should be fixed ;) I'll spin this patch series with Javier fixes for OMAP at the next version of this patch series. > > thanks, > -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 10/44] [media] media: rename the function that create pad links
Em Tue, 25 Aug 2015 12:55:41 -0600 Shuah Khan escreveu: > On 08/23/2015 02:17 PM, Mauro Carvalho Chehab wrote: > > Now that a link can be either between two different graph > > objects, we'll need to add more functions to create links. > > Is this an incomplete sentence. Should it read: "either between > two different graph objects or two pads" ? That would be redundant, as pad is a graph object ;) > > > So, rename the existing one that create links only between > > two pads as media_create_pad_link(). > > > > > No functional changes. > > > > This patch was created via this shell script: > > for i in $(find drivers/media -name '*.[ch]' -type f) $(find > > drivers/staging/media -name '*.[ch]' -type f) $(find include/ -name '*.h' > > -type f) ; do sed s,media_entity_create_link,media_create_pad_link,g <$i >a > > && mv a $i; done > > > > Didn't want to experiment with Coccinelle?? :) I use Coccinelle, but only when I need more complex changes, as Coccinelle may mangle with comments. > > > Signed-off-by: Mauro Carvalho Chehab > > Acked-by: Hans Verkuil > > Signed-off-by: Mauro Carvalho Chehab > > > > Changes look good to me. After fixing the commit log: > > Acked-by: Shuah Khan > > thanks, > -- Shuah > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] android, lmk: Protect task->comm with task_lock.
Hello.
Next patch is mm-related but this patch is not.
Via which tree should these patches go?
>From 48c1b457eb32d7a029e9a078ee0a67974ada9261 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 26 Aug 2015 20:49:17 +0900
Subject: [PATCH 1/2] android, lmk: Protect task->comm with task_lock.
Passing task->comm to printk() wants task_lock() protection in order
to avoid potentially emitting garbage bytes.
Signed-off-by: Tetsuo Handa
---
drivers/staging/android/lowmemorykiller.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 872bd60..d5d25e4 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -134,26 +134,25 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
return 0;
}
oom_score_adj = p->signal->oom_score_adj;
- if (oom_score_adj < min_score_adj) {
- task_unlock(p);
- continue;
- }
+ if (oom_score_adj < min_score_adj)
+ goto next;
tasksize = get_mm_rss(p->mm);
- task_unlock(p);
if (tasksize <= 0)
- continue;
+ goto next;
if (selected) {
if (oom_score_adj < selected_oom_score_adj)
- continue;
+ goto next;
if (oom_score_adj == selected_oom_score_adj &&
tasksize <= selected_tasksize)
- continue;
+ goto next;
}
selected = p;
selected_tasksize = tasksize;
selected_oom_score_adj = oom_score_adj;
lowmem_print(2, "select %d (%s), adj %hd, size %d, to kill\n",
p->pid, p->comm, oom_score_adj, tasksize);
+next:
+ task_unlock(p);
}
if (selected) {
task_lock(selected);
@@ -168,10 +167,10 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
* task should have access to the memory reserves.
*/
mark_oom_victim(selected);
- task_unlock(selected);
lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
selected->pid, selected->comm,
selected_oom_score_adj, selected_tasksize);
+ task_unlock(selected);
lowmem_deathpending_timeout = jiffies + HZ;
send_sig(SIGKILL, selected, 0);
rem += selected_tasksize;
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.
Hello.
Should selected_tasksize be added to rem even when TIF_MEMDIE was not set?
Please see a thread from http://www.spinics.net/lists/linux-mm/msg93246.html
if you want to know why to reverse the order.
>From 2d4cc11d8128e4c1397631b91fea78da3eaefb47 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 26 Aug 2015 20:52:39 +0900
Subject: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and
sending SIGKILL.
If we set TIF_MEMDIE before sending SIGKILL, memory reserves could be
spent for allocations which are not needed for terminating the victim.
Reverse the order as with oom_kill_process() does.
Signed-off-by: Tetsuo Handa
---
drivers/staging/android/lowmemorykiller.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index d5d25e4..c39b6a2 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -156,26 +156,24 @@ next:
}
if (selected) {
task_lock(selected);
- if (!selected->mm) {
- /* Already exited, cannot do mark_tsk_oom_victim() */
- task_unlock(selected);
- goto out;
- }
+ lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
+selected->pid, selected->comm,
+selected_oom_score_adj, selected_tasksize);
+ task_unlock(selected);
+ send_sig(SIGKILL, selected, 0);
/*
* FIXME: lowmemorykiller shouldn't abuse global OOM killer
* infrastructure. There is no real reason why the selected
* task should have access to the memory reserves.
*/
- mark_oom_victim(selected);
- lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
-selected->pid, selected->comm,
-selected_oom_score_adj, selected_tasksize);
+ task_lock(selected);
+ if (selected->mm) {
+ mark_oom_victim(selected);
+ lowmem_deathpending_timeout = jiffies + HZ;
+ rem += selected_tasksize;
+ }
task_unlock(selected);
- lowmem_deathpending_timeout = jiffies + HZ;
- send_sig(SIGKILL, selected, 0);
- rem += selected_tasksize;
}
-out:
lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
sc->nr_to_scan, sc->gfp_mask, rem);
rcu_read_unlock();
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] atomics,cmpxchg: Privatize the inclusion of asm/cmpxchg.h
After commit:
atomics: add acquire/release/relaxed variants of some atomic operations
Architectures may only provide {cmp,}xchg_relaxed definitions in
asm/cmpxchg.h. Other variants, such as {cmp,}xchg, may be built in
linux/atomic.h, which means simply including asm/cmpxchg.h may not get
the definitions of all the{cmp,}xchg variants. Therefore, we should
privatize the inclusions of asm/cmpxchg.h to keep it only included in
arch/* and replace the inclusions outside with linux/atomic.h
Acked-by: Will Deacon
Signed-off-by: Boqun Feng
---
Documentation/atomic_ops.txt| 4
drivers/net/ethernet/sfc/mcdi.c | 2 +-
drivers/phy/phy-rcar-gen2.c | 3 +--
drivers/staging/speakup/selection.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index b19fc34..c9d1cac 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -542,6 +542,10 @@ The routines xchg() and cmpxchg() must provide the same
exact
memory-barrier semantics as the atomic and bit operations returning
values.
+Note: If someone wants to use xchg(), cmpxchg() and their variants,
+linux/atomic.h should be included rather than asm/cmpxchg.h, unless
+the code is in arch/* and can take care of itself.
+
Spinlocks and rwlocks have memory barrier expectations as well.
The rule to follow is simple:
diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index 81640f8..968383e 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -9,7 +9,7 @@
#include
#include
-#include
+#include
#include "net_driver.h"
#include "nic.h"
#include "io.h"
diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index 39d9b29..117b495 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -17,8 +17,7 @@
#include
#include
#include
-
-#include
+#include
#define USBHS_LPSTS0x02
#define USBHS_UGCTRL 0x80
diff --git a/drivers/staging/speakup/selection.c
b/drivers/staging/speakup/selection.c
index a031570..81c0888 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include "speakup.h"
--
2.5.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 7/8] staging: unisys: stop device registration before visorbus registration
Sudip Mukherjee writes:
> On Tue, Aug 25, 2015 at 08:33:55AM -0400, Jes Sorensen wrote:
>> Sudip Mukherjee writes:
>> > On Tue, Aug 18, 2015 at 03:14:02PM -0400, Benjamin Romer wrote:
>> >> In cases where visorbus is compiled directly into the kernel, if
>> >> visorbus registration fails for any reason, it is still possible for
>> >> other drivers to call visorbus_register_visor_driver(), which could
>> >> cause an oops. Prevent this by returning an error code when the bus
>> >> hasn't been registered.
>> >>
>> >> Signed-off-by: Benjamin Romer
>> >> ---
>> >> drivers/staging/unisys/visorbus/visorbus_main.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
>> >> b/drivers/staging/unisys/visorbus/visorbus_main.c
>> >> index 7905ea9..ad2b1ac 100644
>> >> --- a/drivers/staging/unisys/visorbus/visorbus_main.c
>> >> +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
>> >> @@ -863,6 +863,9 @@ int visorbus_register_visor_driver(struct
>> >> visor_driver *drv)
>> >> {
>> >> int rc = 0;
>> >>
>> >> + if (!visorbus_type.p)
>> >> + return -ENODEV; /*can't register on a nonexistent bus*/
>> >> +
>> > IIRC, Greg once told that we should not be working with the internal
>> > data structures of struct bus_type.
>>
>> If you looked at the code you would have noticed this is in fact the bus
>> driver, and visorbus_type is defined in this file. I guess we could tell
>> visorbus_main.c to not touch visorbus_type by deleting the file
>> completely .
> Yes, this is the bus driver, struct bus_type. Maybe the following might
> be a better approach where the struct bus_type internals are not touched
> yet it will server the purpose.
Replacing it with a global variable? Ehm sorry, but no thanks!
NACK
Jes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/8] fix staging:android style issue:Alignment should match open parenthesis
On Wed, Aug 26, 2015 at 11:52:12AM +0800, Peng Sun wrote: > Signed-off-by: Peng Sun Please always add a changelog message. Also, you need to fix the subject. The convention is to use something like: "a: b: ..." So in this case it should be something like: "staging: android: ..." You can look at `git log drivers/staging/android` for inspiration. This applies to all of your other patches as well. Finally, I don't think there is a point in using deep threading in this case. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 7/8] staging: unisys: stop device registration before visorbus registration
On Tue, Aug 25, 2015 at 08:33:55AM -0400, Jes Sorensen wrote:
> Sudip Mukherjee writes:
> > On Tue, Aug 18, 2015 at 03:14:02PM -0400, Benjamin Romer wrote:
> >> In cases where visorbus is compiled directly into the kernel, if
> >> visorbus registration fails for any reason, it is still possible for
> >> other drivers to call visorbus_register_visor_driver(), which could
> >> cause an oops. Prevent this by returning an error code when the bus
> >> hasn't been registered.
> >>
> >> Signed-off-by: Benjamin Romer
> >> ---
> >> drivers/staging/unisys/visorbus/visorbus_main.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
> >> b/drivers/staging/unisys/visorbus/visorbus_main.c
> >> index 7905ea9..ad2b1ac 100644
> >> --- a/drivers/staging/unisys/visorbus/visorbus_main.c
> >> +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
> >> @@ -863,6 +863,9 @@ int visorbus_register_visor_driver(struct visor_driver
> >> *drv)
> >> {
> >>int rc = 0;
> >>
> >> + if (!visorbus_type.p)
> >> + return -ENODEV; /*can't register on a nonexistent bus*/
> >> +
> > IIRC, Greg once told that we should not be working with the internal
> > data structures of struct bus_type.
>
> If you looked at the code you would have noticed this is in fact the bus
> driver, and visorbus_type is defined in this file. I guess we could tell
> visorbus_main.c to not touch visorbus_type by deleting the file
> completely .
Yes, this is the bus driver, struct bus_type. Maybe the following might
be a better approach where the struct bus_type internals are not touched
yet it will server the purpose.
regards
sudip
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 2309f5f..32500be 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -31,6 +31,7 @@ static int visorbus_debug;
static int visorbus_forcematch;
static int visorbus_forcenomatch;
static int visorbus_debugref;
+static bool bus_registered;
#define SERIALLOOPBACKCHANADDR (100 * 1024 * 1024)
#define CURRENT_FILE_PC VISOR_BUS_PC_visorbus_main_c
@@ -40,6 +41,7 @@ static int visorbus_debugref;
static int visorbus_uevent(struct device *xdev, struct kobj_uevent_env *env);
static int visorbus_match(struct device *xdev, struct device_driver *xdrv);
static void fix_vbus_dev_info(struct visor_device *visordev);
+static bool is_visorbus_registered(void);
/* BUS type attributes
*
@@ -863,6 +865,9 @@ int visorbus_register_visor_driver(struct visor_driver *drv)
{
int rc = 0;
+ if(!is_visorbus_registered())
+ return -ENODEV; /*can't register on a nonexistent bus*/
+
drv->driver.name = drv->name;
drv->driver.bus = &visorbus_type;
drv->driver.probe = visordriver_probe_device;
@@ -1263,7 +1268,17 @@ create_bus_type(void)
int rc = 0;
rc = bus_register(&visorbus_type);
- return rc;
+
+ if (rc)
+ return rc;
+ bus_registered = true;
+ return 0;
+}
+
+static bool
+is_visorbus_registered(void)
+{
+ return bus_registered;
}
/** Remove the one-and-only one instance of the visor bus type (visorbus_type).
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
