> supported by the old Intel 2400m (used in Sandy Bridge laptops
> and earlier), which is the only driver using the kernel's wimax
> stack.
>
> Inaky, do you have any additional information about possible
> users? If we are sure there are none, then I'd suggest removing
&
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 wrote:
>
> On Wed, 2017-10-25 at 17:12 +, Perez-Gonzalez, Inaky wrote:
>>> On Tue, 2017-10-24 at 21:00 +, Perez-Gonzalez, Inaky wrote:
>>>>> ping any comments on this?
>>>>
>>>> None fr
>On Tue, 2017-10-24 at 21:00 +, 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
> 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.
n Mar 11, 2014, at 14:53, "Joe Perches" wrote:
> The archive of the mailing list looks as if it's been
> dead for years.
>
> https://lists.linuxwimax.org/pipermail/wimax/
>
> Inaky, is this still alive at all?
>
> If not, I suggest orphaning both WIMAX ST
> 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
> > userspace parts.
> > I wouldn't be surprised to learn of other distributions doing the same.
>
> Inaky?
> Are you doing any work on this at all?
> Should this be deleted?
I do minimal maintenance, which in the last two years has been close to zero.
I do get,
> 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
is no separate wimax
tree
anymore, it is in pure maintenance mode.
BTW: thanks for tackling the UAPI issue
Acked-by: Inaky Perez-Gonzalez
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Sunday 29 July 2007 07:58, Adrian Bunk wrote:
> -DEVICE_ATTR(authorized_default, 0644,
> - usb_host_authorized_default_show,
> - usb_host_authorized_default_store);
> +static DEVICE_ATTR(authorized_default, 0644,
> > + usb_host_authorized_default_show,
Ack, patchse
>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.
>
> ...
>
On Tuesday 27 February 2007 12:45, Ingo Oeser wrote:
> Hi Inaky,
>
> On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> > On Monday 26 February 2007 18:18, Alan wrote:
> > > > Yeah, I need semaphore. This is a hw register that says when the hw
> > >
On Monday 26 February 2007 18:18, Alan wrote:
> > Yeah, I need semaphore. This is a hw register that says when the hw
> > is ready to accept a new command. Code that wants to send commands has
> > to down the semaphore and then send it. When hw is ready to get a new
> > command, it sends and IRQ an
recovery actions (like resetting it,
for sake of being polite).
I use this in the WHCI Ultra Wide Band radio controller code (coming soon
to a hw store near you).
Cristoph, I still wonder how the hell you do it to spot every message
that comes into lkml -- I bet you have a cluster of employees
As suggested by Arjan van de Ven, introduced a generic semaphore.h for
all that arches (previous patch in series). Make all arches include
that generic file.
Warning: not compile tested in all arches
Signed-off-by: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
include/asm-alpha/semap
into
asm-generic/semaphore.h to lay the egg for a saner sharing of
semaphore code between arches. This patch also introduces that witn
the down_interruptible_timeout() decl and the next adds the inclusion
to all the arches' semaphore.h [note: haven't been able to compile
test all of
Introduce down_interruptible_timeout() using timers to make the waiter
stop waiting by simulating a signal (see first patch for more
details). As well introduce asm-generic/semaphore.h and make other
architectures use it too.
--
Inaky
-
To unsubscribe from this list: send the line "unsubs
arrives after the signal and after
down_interruptible returns, nothing in theory. There is a window
where the timer could still execute before it is deleted and it
would look like a timeout [which theoretically could be right too].
Maybe the result < 0 && data.result < 0 check should
>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 introduce
>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()
>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
oo, so...
>How do I do that with this API?
>
>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 is relative
>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;
>> +
rly termination-n-restart
(such as end time drift) are to be avoided.
Joe
"Money can buy bandwidth, but latency is forever" -- John Mashey
Signed-off-by: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
2.6.12-rc4-jak/include/linux/time.h|6 +
2.6.12-rc4-jak/include/linux/timeou
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 ex
v/null include/linux/timeout.h
--- /dev/null 2004-06-24 14:04:38.0 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002
-0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez <[EMAIL PROTECT
43ms
11 maximum cycle time: 1.173ms
12 maximum cycle time: 0.008ms
13 maximum cycle time: 0.008ms
...
--
Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
FC, BTW.)
Ouch, true--rule out %...
> Still, why would you escape it? My shell will not take # as a
> comment start if it is immediately after an alphanumeric character.
Well, you just taught me something about bash I didn't know....
/me goes back to his hole with some more knowledg
l refer to your testing branch in that repository.
Can we use something other than #? we'll have to scape it all the time
in the shell (or at least also allow some other char, something
without special meta-character meaning in the shell, like %).
--
Inaky
-
To unsubscribe from this list: send the
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> >>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> I see--would the following fit your view?
>>
> I
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>> Back to my example before: in fusyn, a user space lock is a kernel
>> space lock with a wrapper, that provides all that is necessary for
>
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> I have to agree with Inaky too. Fundamentally, PI is the same for
> the system regardless of if the locks are user or kernel. I still
> don
multiple owners
(read locks need to have them), the procedure is mostly the
same. However, this not being POSIX, nobody (yet) has asked for it.
--
Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
t; sdb: Write Protect is off
> sdb: asuming driver cache: write-through
If this is the model of your disk, the USB device has been detected
properly, or at least it shows up. Are the contents encrypted you
said? Can you post a more complete log?
--
Inaky
-
To unsubscribe from this list: se
ple of mutexes.
So that's why I chose to put it in the task struct, it becomes O(1)
at the expense (granted) of having to calc a min each time we compute
the dynamic priority.
But these are implementation details
> ...
>will never hit the RT-level. So assuming the RT-lock based code
>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
x can safely save the owner
>priority with out a Fusyn jumping in and changing it and the other way
>around..
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 speci
be built on top of that. And
exposing to user space is the toughest task (unless you don't
care about the fast-path).
-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
detection system will work
>properly (in theory).
So that would mean to create a restriction (which is implicit
now, anyway): "a system call cannot return holding an rt-mutex"
right?
-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ean with them
they will cause an error, but should not have undesired consequences
in the kernel. But BUGS in the code will be as unclear as in RT mutexes.
>it is is bad maintainance to have to maintain two seperate systems. The
>best way ought to be to try to only have one PI system. The k
he futexes]. The deadlock stuff gets
hairier, but it's not such a big of a deal when you have your data
structures setup. It takes time, though.
>> Of course, selling it to the lkml is another story.
>
>I would think that pushing as much of this into userspace would
>mak
>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
>&g
>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
>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
dea
27;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 suspect?
Not really. Deadlock check is needed on PI, so it can be done at the
same time (you have to walk the chain anyway). In any other case, i
ncept--it doesn't
even implement the async interface.
It kind of works, but is not all that solid [last time I tried
the JVMs locked up].
-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
le upstream than the former
>> 100-queues approach.
>
> Inaky was telling me that 100 queues approach is two years old.
>
>The biggest problem is that fusyn has it's own PI system .. So it's not
>clear if that will work with the RT mutex,. I was thinking the PI s
50 matches
Mail list logo
