didn't touch the procinfo method in the other ISDN
drivers, as far as I can see.
(If it was intentional, gigaset_procinfo() can of course be removed.)
> - iif->ctr.proc_fops = _proc_fops;
> + iif->ctr.proc_show = gigaset_proc_show,
> INIT_LIST_HEAD(>appls);
> skb_queue_head_init(>sendqueue);
> atomic_set(>sendqlen, 0);
Thanks,
Paul Bolle
On Mon, 2018-03-26 at 20:05 +0200, Paul Bolle wrote:
> Your patch never hit my inbox. The joy of email! Anyhow, the diff on spinic's
> netdev archive suggests you left (at least) one reference to http://gigaset307
> x.sourceforge.net/ in the documentation.
>
> If you'd be so kind t
reference too
that would be appreciated.
Thanks!
Paul Bolle
ep on doing
that for years. But still, I'd love to hear someone say: yes, I still care
about mainline ISDN.
Does that person still exists?
Thanks,
Paul Bolle
again shows, I'd say, that the gigaset code mainly
exists to see if there's still a pulse in mainline ISDN. Is that enough to
bother? Or should mainline ISDN go the way of, say, IRDA?
But I digress. An alternative patch would be much appreciated.
Thanks,
Paul Bolle
for all three drivers (including
bas_gigaset). So driver->cs itself is invalid here.
And since the patch uses
struct cardstate *cs = urb->context;
in a few places my guess is that it's really the patch that triggers this.
Thanks,
Paul Bolle
On Thu, 2017-10-19 at 23:03 +0200, Paul Bolle wrote:
> On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to p
On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
Acked-by: Paul Bolle <pebo..
On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> This replaces a kmalloc followed by a bunch of per-field zeroing with a
> single kzalloc call, reducing the lines of code.
Acked-by: Paul Bolle <pebo...@tiscali.nl>
Thanks,
Paul Bolle
inters in these timer
callbacks is removed.)
Thanks,
Paul Bolle
ook at
them properly!): I'd prefer it if that was done separately in a preceding
patch. Would that bother you?
Thanks,
Paul Bolle
d-off-by: Joe Perches <j...@perches.com>
> ---
> drivers/isdn/gigaset/interface.c| 2 +-
Gigaset hunk looks good to me:
Acked-by: Paul Bolle <pebo...@tiscali.nl>
> drivers/isdn/hardware/mISDN/avmfritz.c | 17 +
> drivers/isdn/hardware/mISDN/hfcmulti
On Tue, 2017-01-03 at 23:25 +0100, Arnd Bergmann wrote:
> As far as I'm concerned, we are totally fine as long as there exists a
> longterm supported kernel that has i4l in drivers/staging.
Or in drivers/isdn, right?
Paul Bolle
nups?
How often did a bunch of drivers re-enter the tree after being sent to
staging?
Paul Bolle
On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
> I don't have a problem with C programming
I'm sorry, but you do need to learn C, at a basic level, first.
Paul Bolle
net/wireless/reg.o' failed
make: *** [net/wireless/reg.o] Error 2
Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
Paul Bolle
st box locked up
twice some random period after all that. So quite a bit of a mess, all in all.
Paul Bolle
to trigger a WARN in driver_unregister().
And it's that WARN that I think requires the entire stable song and dance.
Otherwise it would be, as far as I can tell, a hard to hit problem in an
obscure driver without any side effects.
Paul Bolle
ves behind once gigaset_initdriver() fails before
saying so.
Thanks for reporting this!
Paul Bolle
es should be proper English. But commit header lines
should not end with a period. The vast majority doesn't. Yes, I've just
checked.
How many newspaper headlines end with a period?
Thanks,
Paul Bolle
gt; to break that hard dependency from those drivers without preventing their
> usage altogether.
By the way: would you have pointers to threads that discussed attempts
to achieve this using currently available Kconfig options?
Thanks,
Paul Bolle
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > And in your example BAR is bool, right? Does the above get more
> > complicated if BAR would be tristate?
>
> If BAR=m then implying BAZ from FOO=y will force BAZ to
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > What happens when a tristate symbol is implied by a symbol set to 'y'
> > and by a symbol set to 'm'?
>
> That's respectively the third and second rows in the table above.
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > You probably got "["if" ]" for free by copying what's there for
> > select. But this series doesn't use it, so perhaps it would be better
> > to not d
b1) Swap all "select FOO" to "depends on FOO" or,
> b2) Swap all "depends on FOO" to "select FOO"
> + c) Consider the use of "imply" instead of "select"
If memory serves me right this text was added after a long discussion
with Luis Rodriguez. Luis might want to have a look at any
Haven't looked at the code yet, sorry. I'm still trying to see whether
I can wrap my mind around this. It looks like just setting a default on
another symbol, but there could be a twist I missed.
Paul Bolle
..@linaro.org>
As far as I can see this series doesn't add a user of "suggest". So I
see no reason to add it.
NAK.
Paul Bolle
On Wed, 2016-10-26 at 19:41 -0400, Nicolas Pitre wrote:
> On Thu, 27 Oct 2016, Paul Bolle wrote:
> > If you'll have to send another update don't bother including Yann. Yann
> > hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
> > kconfig.
>
> What
selected") has a special meaning in kconfig land. I guess you meant
something neutral like "set" here. Is that correct?
By the way: "also" makes this sentence hard to parse.
Paul Bolle
update don't bother including Yann. Yann
hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
kconfig.
Paul Bolle
benefits for the users
of these laptops? In other words: should I bother somehow contacting
Dell and point them to this discussion in order to have them fix this?
Paul Bolle
100 lines or so, that
apparently are generated directly after modprobing iwlwifi.
After these 100 lines there's a ten second gap (I guess it took me ten
seconds to actually use the wifi). I assume you don't care about that
part of the debug messages.
Have fun!
Paul Bolle
<7>[ 767.691342]
Luca,
On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> Could you please give this a spin? I have tested it with some handmade
> ACPI tables in QEMU and it seems to work fine now.
Tested-by: Paul Bolle <pebo...@tiscali.nl>
Not that this test was worth a lot: it builds cle
Chris' version came preinstalled with
something else?
Thanks,
Paul Bolle
01 is increased until
it reaches RP20. (The machine has 20 PCI devices according to lspci. I
have no clue how to match that RPxx number to the 20 devices showing up
in lspci, sorry.)
Paul Bolle
nt:
Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> In any case, I will rework this code, so I'd prefer if we skip this
> patch entirely.
Feel free to prod me for testing whatever you come up with.
Paul Bolle
ents[0].integer.value != 0) {
> > - IWL_ERR(trans, "Unsupported splx structure\n");
> > + IWL_WARN(trans, "Unsupported splx structure, not limiting WiFi
> > power\n");
> > return 0;
> > }
>
> If this is really bothering you, I guess I could apply this patch for
> now. But as I said, this is not solving the actual problem.
Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
imply one needs to act on this message, while warn does imply that
action is needed.
Thanks,
Paul Bolle
On Wed, 2016-09-28 at 18:50 +0200, SF Markus Elfring wrote:
> Would you like to look once more into an improved patch series for this
> software module a bit later?
I'm afraid I'm not looking forward to receiving an update of this
series, sorry.
Thanks,
Paul Bolle
ver kmalloc with multiply
Am I being trolled?
Paul Bolle
insertions(+), 15 deletions(-)
Two of the five patches introduced bugs. The rest of the series isn't
free of various nits either. Of course, I was in no mood to be lenient
when I looked at those three patches.
I won't take any of these patches, sorry.
Paul Bolle
verify that. It was fun,
> even.)
Agree.
Except this patch assumes the superfluous braces would be removed in
4/5. But it turns out that other patch must be dropped. It would have
been better to remove the braces in this patch.
Paul Bolle
, sizeof(*drv->cs), GFP_KERNEL);
For "minors" the same holds as for "channels", above.
And you snuck in a parentheses change. That should have probably been
merged with 5/5.
> if (!drv->cs)
> goto error;
Paul Bolle
You're in Eliza mode again.
(Hat tip to Björn Mork, https://lkml.org/lkml/2016/1/4/259).
Paul Bolle
quot;?
My translation of this question is: could you please hold my hand while
I read the code of a driver I do not use - a driver for hardware that I
don't even have, and therefor cannot really test - after I submitted a
patch that appears to be broken?
My answer to that question is: no, sorry, I won't do that.
Paul Bolle
-error:
> +free_bcs:
> + kfree(cs->bcs);
> +report_failure:
> gig_dbg(DEBUG_INIT, "failed");
> gigaset_freecs(cs);
gigaset_freecs() is not a function I look at for the fun of it. But
still, in it we find:
case 0: /* error in basic setup */
[...]
kfree(cs->inbuf);
kfree(cs->bcs);
As far as I can tell we will call those two kfree()'s if we jump to
"error". So, contrary to your analysis, I don't think we leak cs->bcs.
> return NULL;
Paul Bolle
for that discovery?
> Enclose two expressions for the sizeof operator by parentheses
>
> drivers/isdn/gigaset/common.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
Paul Bolle
On Mon, 2016-09-26 at 14:52 +0200, SF Markus Elfring wrote:
> Would it eventually make sense to move this "if" (behind an "else")
> to a separate line and increase the indentation for the corresponding
> code one level then?
No.
Paul Bolle
Where did the [PATCH 5/5] part of the subject go? You didn't drop it,
did you? Because that's surprisingly annoying.
Paul Bolle
ck you should
resend the entire series (minus those patches that have been NAK-ed, of
course) as an update (v2, v3, etc.).
Don't resubmit one single patch of a series (within hours!) as you did
here.
I hope to have a look at your series within a few days. Show some
patience.
Thanks,
Paul Bolle
w.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
You use checkpatch a lot, don't you? Didn't you use it to, you know,
check your patch?
Paul Bolle
36 insertions(+), 23 deletions(-)
So I ran checkpatch on this file, just like you did. Specifically, I
did:
scripts/checkpatch.pl -f drivers/isdn/capi/capidrv.c | grep "assignment in
if condition" | wc -l
It tells me there are actually 18 instances of this "ERROR". Why did
you ignore one of it in this patch?
Paul Bolle
mISDN + Asterisk + chan-capi setup? (That's
the closest to mISDN with CAPI support that I could find. Did I miss
something?)
Thanks,
Paul Bolle
On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote:
> As a consequence, owners of HiSAX type adapters are in fact stuck with
> the old hisax driver if they want to continue using i4l userspace
> tools.
Do you know whether or not mISDN tools offer functionality comparable to
i4l tool
On vr, 2016-03-04 at 17:32 +0100, Arnd Bergmann wrote:
> A third patch moves the capidrv source from drivers/isdn/capi/
> into the i4l directory.
I see. Why exactly?
Thanks,
Paul Bolle
ntation
> when I move the compat ioctl handler from fs/compat_ioctl.c
> into drivers/net/ppp/ppp_generic.c, but I guess I can do that
> anyway as it seems that i4l never worked properly in compat mode.
Paul Bolle
ggers this formletter?
Thanks,
Paul Bolle
syzkaller hadn't insisted in rubbing my nose
in it.)
So chances are you would have come up with something similar to this fix
would commit 25cad69f21f5 ("base/platform: Fix platform drivers with no
probe callback") already have landed.
Thanks,
Paul Bolle
e
additional benefit of actually working.
Reported-by: Dmitry Vyukov <dvyu...@google.com>
Tested-by: Dmitry Vyukov <dvyu...@google.com>
Signed-off-by: Paul Bolle <pebo...@tiscali.nl>
---
drivers/isdn/gigaset/ser-gigaset.c | 9 +
1 file changed, 1 insertion(+), 8 deletions
into the code.
This should eventually land in stable. No fixes tag because backporting is
probably not so straightforward for v4.3 and earlier. So I suggest I'll send
proper backports in about two weeks.
Paul Bolle (1):
ser_gigaset: use container_of() instead of detour
drivers/isdn/gigaset
On vr, 2016-02-05 at 22:25 +0100, Dmitry Vyukov wrote:
> On Fri, Feb 5, 2016 at 7:36 PM, Paul Bolle <pebo...@tiscali.nl> wrote:
> > Does that make any difference?
> Nope.
> Almost 500 objects leaked in less than 10 seconds:
Too bad. Still a nice (potential) clean up though.
Thanks,
Paul Bolle
Hi Dmitry,
On vr, 2016-02-05 at 17:06 +0100, Paul Bolle wrote:
> On vr, 2016-02-05 at 14:28 +0100, Dmitry Vyukov wrote:
> > I wonder why you don't see the leak I am seeing...
>
> So do I, for a few days now.
0) I finally managed to reliably trigger this leak on an i686, single
co
> cs->hw.ser is not freed yet. Just a guess.
I'll have to ponder on that a bit, sorry.
Paul Bolle
On vr, 2016-02-05 at 17:06 +0100, Paul Bolle wrote:
> If that would happen, then cs can be reused while the previous
> > cs->hw.ser is not freed yet. Just a guess.
>
> I'll have to ponder on that a bit, sorry.
This is from the hit-the-code-until-it-confesses department:
Hi Dmitry,
On do, 2016-02-04 at 14:15 +0100, Dmitry Vyukov wrote:
> On Thu, Feb 4, 2016 at 2:09 PM, Paul Bolle <pebo...@tiscali.nl> wrote:
> > What are you seeing here?
>
> I see that active_objs is slowly, constantly growing.
>
> I've attached my config file, please
d me if I stay silent for too long.
Thanks for narrowing things down!
Paul Bolle
nfo should be interpreted, sorry. But
the interesting fields appear to be "" and "".
"" seems to be stable here (during the runs of a few minutes
that I dare to inflict on my laptop). "" is more volatile.
But I also saw it going down while the reproducer was running.
What are you seeing here?
Thanks,
Paul Bolle
0xc0 fs/ioctl.c:680
> [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
The above should provide me with enough information to figure out what's
going on here.
> On commit 34229b277480f46c1e9a19f027f30b074512e68b.
That's "Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net",
of two days ago.
Thanks for the report,
Paul Bolle
Hi Dmitry,
On wo, 2016-02-03 at 17:16 +0100, Paul Bolle wrote:
> The above should provide me with enough information to figure out
> what's going on here.
I've instrumented ser_gigaset with some printk's. Basically I added the
stuff pasted at the end of this message. In 10.00
From: Tilman Schmidt <til...@imap.cc>
device->platform_data and platform_device->resource are never used
and remain NULL through their entire life. Drops the kfree() calls
for them from the device release method.
Signed-off-by: Tilman Schmidt <til...@imap.cc>
Signed-off-by
Sascha Levin reported that the syzkaller fuzzer triggered a WARNING in
ser_gigaset (see https://lkml.kernel.org/g/56587467.8050...@oracle.com ). It
turned out that ser_gigaset has always deallocated its platform device
structure incorrectly. Tilman submitted the patch that fixes that (3/4) and a
ed-off-by: Tilman Schmidt <til...@imap.cc>
Fixes: 2869b23e4b95 ("drivers/isdn/gigaset: new M101 driver (v2)")
Reported-by: Sasha Levin <sasha.le...@oracle.com>
Signed-off-by: Paul Bolle <pebo...@tiscali.nl>
---
drivers/isdn/gigaset/ser-gigaset.c | 10 +++---
method. That in itself is probably a mistake given
modern coding practices - but needs fixing in the tty layer.
Signed-off-by: Alan Cox <a...@linux.intel.com>
Acked-by: Tilman Schmidt <til...@imap.cc>
Signed-off-by: Paul Bolle <pebo...@tiscali.nl>
---
drivers/isdn/gigaset/ser-giga
From: Tilman Schmidt <til...@imap.cc>
Commit f34d7a5b7010 ("tty: The big operations rework") changed
tty->driver to tty->ops but left NULL checks for tty->driver untouched.
Fix.
Signed-off-by: Tilman Schmidt <til...@imap.cc>
[pebolle: removed Fixes tag]
Hi Tilman,
On za, 2015-12-12 at 19:09 +0100, Tilman Schmidt wrote:
> Am 10.12.2015 um 12:31 schrieb Paul Bolle:
> > 1/3 ran into objections and, I think, Alan Cox is working on an
> > alternative for it. Would you mind resending 2/3 and 3/3 as a two
> > patches ser
On wo, 2015-12-09 at 12:10 +0100, Tilman Schmidt wrote:
> Am 09.12.2015 um 00:12 schrieb Paul Bolle:
> > So what does setting
> > cs->hw.ser->dev.dev.driver_data to NULL just before freeing it buy
> > us?
>
> We're freeing cs->hw.ser, not cs->hw.ser-&g
.32 there is a trivial merge conflict with a removed
> comment line.
1/3 ran into objections and, I think, Alan Cox is working on an
alternative for it. Would you mind resending 2/3 and 3/3 as a two
patches series? Feel free to add
Acked-by: Paul Bolle <pebo...@tiscali.nl>
to both.
(The p
me, I think. We're
discussing a series submitted by Tilman.
Confused,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
clear = old_state & ~new_state;
It's pretty obvious that this should have been part of commit
f34d7a5b7010 ("tty: The big operations rework"). That being said, these
test puzzle me. It's not obvious why they're needed. Ie, can the null
dereferences they try to catch really happen? But
es setting
cs->hw.ser->dev.dev.driver_data to NULL just before freeing it buy us?
> + kfree(cs->hw.ser);
> + cs->hw.ser = NULL;
I might be missing something, but what does setting this to NULL buy us
here?
(I realize that I'm asking questions to code that isn't actually ne
: Tilman Schmidt <til...@imap.cc>
> Reported-by: Paul Bolle <pebo...@tiscali.nl>
s/Reported-by/Acked-by/
(Having both lines would be overdoing things.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord..
[Re-added mailinglist that got dropped somehow.]
On ma, 2015-12-07 at 10:27 +0100, Tilman Schmidt wrote:
> Am 06.12.2015 um 21:12 schrieb Paul Bolle:
> > This solution assumes that the struct platform_device is moved out
> > of
> > the struct ser_cardstate, doesn
On wo, 2015-12-02 at 18:48 -0500, Peter Hurley wrote:
> On 11/30/2015 01:01 PM, Paul Bolle wrote:
> > Should (something like) this go into stable too?
>
> Definitely for stable since it has a userspace triggerable component.
Thanks, will do.
> > --- a/drivers/isdn/
er);
> + cs->hw.ser = NULL;
> }
This solution assumes that the struct platform_device is moved out of
the struct ser_cardstate, doesn't it? In other words, this is something
to do on top of my (draft) patch. Otherwise we'd still be freeing memory
managed through reference counti
On di, 2015-12-01 at 10:30 +0100, Tilman Schmidt wrote:
> Am 30.11.2015 um 22:07 schrieb Paul Bolle:
> > How would attaching two devices work with GIGASET_MINORS hardcoded
> > to 1?
>
> Ah, it wouldn't. You'd have to recompile with a bigger GIGASET_MINORS.
>
> (I wo
second M105's in a box somewhere, so I could check myself
what happens when a second USB device is added, for what that's worth.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordo
On ma, 2015-11-30 at 00:23 +0100, Paul Bolle wrote:
> Relevant part of dmesg attached at the end of this message. This
> should give me (and Tilman too?) an entry to get to bottom of this.
> Since this is relevant for anyone with just the ser-gigaset module
> installed, I hope to
ggered
this warning, I'm afraid it will be hard to determine which struct
timer_list is at the root of all this. (Ie, there's probably quite a bit
of code to wade through in order to determine that.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe netdev&q
On zo, 2015-11-29 at 21:26 +0100, Paul Bolle wrote:
> If the above is correct it would be nice to know the .config of the
> kernel used by syzkaller.
>
> Anyhow, without further details of the chain of events that triggered
> this warning, I'm afraid it will be hard to determi
ually ISDN drivers in general) while running
recent kernel releases? I haven't seen reports that suggest people
really do that for some time now.
So, just to be absolutely sure: this was generated with a kernel that
used the ser-gigaset driver without actually using the related hardware,
wasn't i
(A few quick notes follow. The hope here is basically that my display of
ignorance might trigger others to speak up while I'm still pondering on
this bug.)
On vr, 2015-11-27 at 13:15 -0500, Sasha Levin wrote:
> On 11/27/2015 12:57 PM, Paul Bolle wrote:
> > On vr, 2015-11-27 at 10:19 -05
ount of data
> + the line discipline is willing to accept from the
> + driver with a single call to receive_buf().
A lot clearer than v1! (I do assume the TTY people will shout if that
sentence isn't actually correct.)
Thanks for looking into this, again.
Paul Bolle
--
T
doesn't add users for art_to_mono64() and
art_to_mono64(), right?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
in v4.3.
Applied.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that it might be in time for
v4.3.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
builtin_platform_driver() for built-in only
code.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/bman.o' failed
make[1]: *** [[...]/drivers/soc/fsl/qbman/bman.o] Error 1
Makefile:1568: recipe for target 'bman.ko' failed
make: *** [bman.ko] Error 2
make: Leaving directory '[...]'
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
(0)
+#else
+#define DPA_ASSERT(x)
+#endif
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+#define copy_shorts memcpy
+#define copy_bytes memcpy
+#endif
--- /dev/null
+++ b/include/soc/fsl/bman.h
+static inline int bman_reserve_bpid(u32 bpid)
+{
+ return bman_reserve_bpid_range(bpid, 1);
+}
Unused.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe
matters is what the people that need to sign
off on these drivers (ppc? netdev?) are comfortable with. I know that
some maintainers won't even bother looking at code that has no callers.
In the mean time I'll skip the exports for the remainder of this series.
Thanks,
Paul Bolle
--
To unsubscribe
[...] uevent when
they're created. Where should I look for those struct platform_device's?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--- /dev/null
+++ b/net/hv_sock/af_hvsock.c
+static int hvsock_init(void)
+{
+ [...]
+}
+
+static void hvsock_exit(void)
+{
+ [...]
+}
+
+module_init(hvsock_init);
+module_exit(hvsock_exit);
Any specific reason not to mark these functions __init and __exit?
Thanks,
Paul Bolle
1 - 100 of 113 matches
Mail list logo
