> From: Arnd Bergmann
>
> Makes sense. I checked
> https://en.wikipedia.org/wiki/List_of_WiMAX_networks, and it appears
> that these entries are all stale, after everyone has migrated to LTE
> or discontinued their service altogether.
>
> NetworkManager appears to have dropped userspace support
This driver should be orphaned.
While I can’t certainly say nobody is using it, the HW has not been sold for
years and it hasn’t been brought to current LK standards.
If your assesment is the code shall not be used, it’s then another argument
towards disconnecting it.
> On Aug 18, 2019, at
> On Oct 25, 2017, at 10:39, Dan Williams <d...@redhat.com> wrote:
>
> On Wed, 2017-10-25 at 17:12 +, Perez-Gonzalez, Inaky wrote:
>>> On Tue, 2017-10-24 at 21:00 +0000, Perez-Gonzalez, Inaky wrote:
>>>>> ping any comments on this?
>>>>
> On Oct 25, 2017, at 10:39, Dan Williams wrote:
>
> On Wed, 2017-10-25 at 17:12 +0000, Perez-Gonzalez, Inaky wrote:
>>> On Tue, 2017-10-24 at 21:00 +0000, Perez-Gonzalez, Inaky wrote:
>>>>> ping any comments on this?
>>>>
>>>> None fr
>On Tue, 2017-10-24 at 21:00 +0000, Perez-Gonzalez, Inaky wrote:
>> > ping any comments on this?
>>
>> None from me; I don't have access to this HW anymore, so I can't
>> validate if the change would work or not.
> I still have a 5350 around somewhere, I can make
>On Tue, 2017-10-24 at 21:00 +0000, Perez-Gonzalez, Inaky wrote:
>> > ping any comments on this?
>>
>> None from me; I don't have access to this HW anymore, so I can't
>> validate if the change would work or not.
> I still have a 5350 around somewhere, I can make
> ping
> any comments on this?
None from me; I don't have access to this HW anymore, so I can't validate
if the change would work or not.
> ping
> any comments on this?
None from me; I don't have access to this HW anymore, so I can't validate
if the change would work or not.
(Sorry for the formatting, iPhone email)
The mailing list is alive (judging for all the spam bounces I get) but valid
traffic has been pretty much nothing for a long time.
Patches have trickled through for the last years with me maybe once having to
ack.
So I'm ok with either.
> On Mar
(Sorry for the formatting, iPhone email)
The mailing list is alive (judging for all the spam bounces I get) but valid
traffic has been pretty much nothing for a long time.
Patches have trickled through for the last years with me maybe once having to
ack.
So I'm ok with either.
On Mar 11,
> From: Joe Perches [mailto:j...@perches.com]
>
> On Thu, 2013-09-26 at 18:11 +0000, Perez-Gonzalez, Inaky wrote:
> > > From: Joe Perches [mailto:j...@perches.com]
> > > >
> > > > The W: link is dead.
> > > >
> > > >
> From: Joe Perches [mailto:j...@perches.com]
> >
> > The W: link is dead.
> >
> > Given wimax never really took off, is there any point in keeping this in
> > the kernel at all ?
> > We turned off the drivers in Fedora a while ago, and just threw out the
> > userspace parts.
> > I wouldn't be
From: Joe Perches [mailto:j...@perches.com]
The W: link is dead.
Given wimax never really took off, is there any point in keeping this in
the kernel at all ?
We turned off the drivers in Fedora a while ago, and just threw out the
userspace parts.
I wouldn't be surprised to learn
From: Joe Perches [mailto:j...@perches.com]
On Thu, 2013-09-26 at 18:11 +, Perez-Gonzalez, Inaky wrote:
From: Joe Perches [mailto:j...@perches.com]
The W: link is dead.
Given wimax never really took off, is there any point in keeping this in
the kernel at all ?
We
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
0m: fix i2400m->wake_tx_skb handling
>
...
>
> Only compile tested.
I don't have access to hardware to test this--might want to contact Dan
Williams,
as he has been more actively using it.
--
To unsubscribe from this list:
From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
0m: fix i2400m-wake_tx_skb handling
...
Only compile tested.
I don't have access to hardware to test this--might want to contact Dan
Williams,
as he has been more actively using it.
--
To unsubscribe from this list: send the
Hello David
> From: David Howells [mailto:dhowe...@redhat.com]
>
> Can you merge the following branch into the wimax tree please.
>
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently. After these patches,
> userspace
Hello David
From: David Howells [mailto:dhowe...@redhat.com]
Can you merge the following branch into the wimax tree please.
This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently. After these patches,
userspace headers
>From: Randy Dunlap <[EMAIL PROTECTED]>
>
>Make kernel-doc comments match macro names.
>Correct parameter names in a few places.
>Remove '#' from beginning of kernel-doc comment macro names.
>Remove extra (erroneous) blank lines in kernel-doc.
>
> ...
>
>cc: Inaky Perez-Gonzalez <[EMAIL
From: Randy Dunlap [EMAIL PROTECTED]
Make kernel-doc comments match macro names.
Correct parameter names in a few places.
Remove '#' from beginning of kernel-doc comment macro names.
Remove extra (erroneous) blank lines in kernel-doc.
...
cc: Inaky Perez-Gonzalez [EMAIL PROTECTED]
cc: Daniel
>From: Arjan van de Ven [mailto:[EMAIL PROTECTED]
>
>> I gave it a quick try (must admit, not too tested) and it seems that
>> the setting of TIF_SIGPENDING without really having a signal queued
>> is not having easily visible ugly consequences.
>
>what happens if you get a signal around the time
From: Arjan van de Ven [mailto:[EMAIL PROTECTED]
I gave it a quick try (must admit, not too tested) and it seems that
the setting of TIF_SIGPENDING without really having a signal queued
is not having easily visible ugly consequences.
what happens if you get a signal around the time the
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Hmm, I cannot think of more ways to specify a timeout than how
>> long I want to wait (relative) or until when (absolute) and which
>> is the reference clock. And t
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> I cannot produce (top of my head) any other POSIX API calls that
>> allow you to specify another clock source, but they are there,
>> somewhere. If I am to introdu
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Usefulness: (see the rationale in the patch), but in a nutshell;
>> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
>> (eg: pthread_mutex_timed_lo
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Perez-Gonzalez, Inaky wrote:
>
>>>I can get the first sleep. Suppose I oversleep by X nanoseconds. I
>>>wake, and get an opaque timeout back. How do I ask for the new wake
>>>time to be "endtime + I
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Joe Korty wrote:
>
>> The returned timeout struct has a bit used to mark the value as
absolute. Thus
>> the caller treats the returned timeout as a opaque cookie that can be
>> reapplied to the next (or more likely, the to-be restarted)
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> +flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
>> +clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
>> +
>> +result = -EINVAL;
>> +
Hi Andrew
I would like to ask for the inclusion of the general timeout
specification API in the -mm tree, looking forward it to bubble
up to mainline.
For more context, please visit:
http://groups.google.com/group/linux.kernel/browse_frm/thread/a426e5b0d0
Hi Andrew
I would like to ask for the inclusion of the general timeout
specification API in the -mm tree, looking forward it to bubble
up to mainline.
For more context, please visit:
http://groups.google.com/group/linux.kernel/browse_frm/thread/a426e5b0d0
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
+flags = tp-clock_id TIMEOUT_FLAGS_MASK;
+clock_id = tp-clock_id TIMEOUT_CLOCK_MASK;
+
+result = -EINVAL;
+if (flags ~TIMEOUT_RELATIVE)
+goto out;
+
+/* someday
From: Christopher Friesen [mailto:[EMAIL PROTECTED]
Joe Korty wrote:
The returned timeout struct has a bit used to mark the value as
absolute. Thus
the caller treats the returned timeout as a opaque cookie that can be
reapplied to the next (or more likely, the to-be restarted) timeout.
Okay,
From: Christopher Friesen [mailto:[EMAIL PROTECTED]
Perez-Gonzalez, Inaky wrote:
I can get the first sleep. Suppose I oversleep by X nanoseconds. I
wake, and get an opaque timeout back. How do I ask for the new wake
time to be endtime + INTERVAL?
endtime.ts += INTERVAL
[we all know opaque
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
Usefulness: (see the rationale in the patch), but in a nutshell;
most POSIX timeout specs have to be absolute in CLOCK_REALTIME
(eg: pthread_mutex_timed_lock()). Current kernel needs the timeout
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
I cannot produce (top of my head) any other POSIX API calls that
allow you to specify another clock source, but they are there,
somewhere. If I am to introduce a new API, I better make it
flexible
Hi John
>From: john stultz [mailto:[EMAIL PROTECTED]
>On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
>> The main user of this new inteface is to allow system calls to get
>> time specified in an absolute form (as most of POSIX states) and thus
>> avoid extra time conversion work.
Hi John
From: john stultz [mailto:[EMAIL PROTECTED]
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
The main user of this new inteface is to allow system calls to get
time specified in an absolute form (as most of POSIX states) and thus
avoid extra time conversion work.
...
>From: Esben Nielsen [mailto:[EMAIL PROTECTED]
>
>I think we (at least) got a bit confused here. What (I think) the
thread
>started out with was a clear layering of the mutexes. I.e. the code
obeys
>the grammar
>
> VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
> |
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
>
>> You should not need any of this if your user space mutexes are a
>> wrapper over the kernel space ones. The kernel handles everything
>> the same and there is
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
>
>> So no, you will not need the same API, at all :-) Fusyn manipulates
>> task->static_prio and only task->prio when no RT lock is taken. When
the
>> first RT-lock is taken/released it manipulates
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>I just wanted to discuss the problem a little more. From all the
>conversations that I've had it seem that everyone is worried about
>having PI in Fusyn, and PI in the RT mutex.
It sure is overlapping functionalities.
> ...
>The RT mutex will
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>> Well yeah, but you could lock a fusyn, then invoke a system call
which
>> locks a kernel semaphore.
>
>Right .. For deadlock detection, I want to assume that the fusyn lock
is
>on the outer level. That way both deadlock detection system will work
>From: Esben Nielsen [mailto:[EMAIL PROTECTED]
>On 12 Apr 2005, Daniel Walker wrote:
>
>>
>>
>> At least, both mutexes will need to use the same API to raise and
lower
>> priorities.
>
>You basicly need 3 priorities:
>1) Actual: task->prio
>2) Base prio with no RT locks taken: task->static_prio
From: Esben Nielsen [mailto:[EMAIL PROTECTED]
On 12 Apr 2005, Daniel Walker wrote:
At least, both mutexes will need to use the same API to raise and
lower
priorities.
You basicly need 3 priorities:
1) Actual: task-prio
2) Base prio with no RT locks taken: task-static_prio
3) Base prio with
From: Daniel Walker [mailto:[EMAIL PROTECTED]
Well yeah, but you could lock a fusyn, then invoke a system call
which
locks a kernel semaphore.
Right .. For deadlock detection, I want to assume that the fusyn lock
is
on the outer level. That way both deadlock detection system will work
properly
From: Daniel Walker [mailto:[EMAIL PROTECTED]
I just wanted to discuss the problem a little more. From all the
conversations that I've had it seem that everyone is worried about
having PI in Fusyn, and PI in the RT mutex.
It sure is overlapping functionalities.
...
The RT mutex will never
From: Daniel Walker [mailto:[EMAIL PROTECTED]
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
So no, you will not need the same API, at all :-) Fusyn manipulates
task-static_prio and only task-prio when no RT lock is taken. When
the
first RT-lock is taken/released it manipulates task-prio
From: Daniel Walker [mailto:[EMAIL PROTECTED]
On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
You should not need any of this if your user space mutexes are a
wrapper over the kernel space ones. The kernel handles everything
the same and there is no need to take care of any special
From: Esben Nielsen [mailto:[EMAIL PROTECTED]
I think we (at least) got a bit confused here. What (I think) the
thread
started out with was a clear layering of the mutexes. I.e. the code
obeys
the grammar
VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
|
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>> Quick fix: the usual. Enable deadlock detection and if it
>> returns deadlock, assume it is locked already and proceed (or
>> do a recursive mutex, or a trylock).
>
>You have to be joking me ? geez.
>...
This is way *more* common than you
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
>> If you are exposing the kernel locks to userspace to implement
>> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
>> to hav
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
>>
>> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>>
>> > Let me re-phrase then: it is a must have only on PI, to make sure
you
&
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> Let me re-phrase then: it is a must have only on PI, to make sure you
>> don't have a loop when doing it. Maybe is a consequence of the
>> algorithm I ch
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> >OTOH, deadlock detection is another issue. It's quite expensive and
i'm
>> >not sure we want to make it a runtime thing. But for fusyn's
deadlock
>>
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>
>i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if
>they come in small, clean steps. E.g. Daniel's plist.h stuff was nice
>and clean.
I am finishing breaking it up in small bits so you can take a look
at it. Should be finished
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if
they come in small, clean steps. E.g. Daniel's plist.h stuff was nice
and clean.
I am finishing breaking it up in small bits so you can take a look
at it. Should be finished
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:
OTOH, deadlock detection is another issue. It's quite expensive and
i'm
not sure we want to make it a runtime thing. But for fusyn's
deadlock
detection and safe teardown on owner-exit is a must-have i
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:
Let me re-phrase then: it is a must have only on PI, to make sure you
don't have a loop when doing it. Maybe is a consequence of the
algorithm I chose. -However- it should be possible to disable
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:
Let me re-phrase then: it is a must have only on PI, to make sure
you
don't have a loop when doing it. Maybe is a consequence
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
If you are exposing the kernel locks to userspace to implement
mutexes (eg POSIX mutexes), deadlock checking is a feature you want
to have to complain with POSIX. According
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
Quick fix: the usual. Enable deadlock detection and if it
returns deadlock, assume it is locked already and proceed (or
do a recursive mutex, or a trylock).
You have to be joking me ? geez.
...
This is way *more* common than you think--I've
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>> Current tip of development has some issues with conditional variables
>> and broadcasts (requeue stuff) that I need to sink my teeth in. Joe
>> Korty is fixing up a lot of corner cases I wasn't catching, but
>> other than that is doing fine.
>
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote:
>
>> this one looks really clean.
>>
>> it makes me wonder, what is the current status of fusyn's? Such a
light
>> datastructure would be much more mergeable upstream than the former
>> 100-queues
From: Daniel Walker [mailto:[EMAIL PROTECTED]
On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote:
this one looks really clean.
it makes me wonder, what is the current status of fusyn's? Such a
light
datastructure would be much more mergeable upstream than the former
100-queues approach.
From: Daniel Walker [mailto:[EMAIL PROTECTED]
Current tip of development has some issues with conditional variables
and broadcasts (requeue stuff) that I need to sink my teeth in. Joe
Korty is fixing up a lot of corner cases I wasn't catching, but
other than that is doing fine.
You try to
65 matches
Mail list logo
