like ctrl+c does not work when logged in from the
console - only when logged in throuhg ssh. This is really not that
important as the machine only acts as a monitor-less fileserver.
If You need additional information - please let me know.
regards
/Rene
> On Sun, 27 May 2001 05:10:30 +0200 (CEST),
> Rene <[EMAIL PROTECTED]> wrote:
> >Problem #2
> >Certain keystrokes like ctrl+c does not work when logged in from the
> >console
>
> Are you using /dev/console or /dev/tty for the console session?
> /dev/conso
On Sun, 27 May 2001, Keith Owens wrote:
> On Sun, 27 May 2001 06:04:28 +0200 (CEST),
> Rene <[EMAIL PROTECTED]> wrote:
> >hmm I feel quite certain that I am using /dev/tty - is there some way I
> >can check this?
>
> /etc/inittab, lines for mingetty, getty or
Hello,
this is V2 of a patches-series for controllers using the ezusb-functions.
ezusb: remove dependency to usb_serial interface
euzsb: add support for Cypress FX2LP
ezusb: add functions for firmware download
ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
--
René Bürgel
SOHA
This patch removes the dependency on the usb_serial interface and names
some magic constants
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,2
This patch removes the dependency on the usb_serial interface and names
some magic constants
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,2
Hello,
this is V2 of a patches-series for controllers using the ezusb-functions.
ezusb: remove dependency to usb_serial interface
euzsb: add support for Cypress FX2LP
ezusb: add functions for firmware download
ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
--
René Bürgel
SOHARD
This patch removes the dependency on the usb_serial interface and names
some magic constants
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,2
This Patch adds support for the newer Cypress FX2LP. It also adapts
three drivers currently using ezusb to the interface change. (whiteheat
and keyspan[_pda])
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 3048b52d..351988d 100644
--- a/
This patch adds new functions to upload firmware to the controller. The
drivers currently using ezusb are adapted to use these new functions.
This also fixes a bug occuring during firmware loading in the
whiteheat-driver:
The driver iterates over an ihex-formatted firmware using ++ on a "const
This patch moves drivers/usb/serial/ezusb.c to drivers/usb/misc/and
adapts Makefiles and Kconfigs
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bfcd02..1c63b54 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -244,3 +2
please ignore this thread, i'm still new to this mailing list stuff :/
I'll do my best to avoid such noise in the future
- Ursprüngliche Mail -
> Hello,
>
> this is V2 of a patches-series for controllers using the
> ezusb-functions.
>
> ezusb: remove dependency to usb_serial interface
>
> Git should show this as a move, not as a "add a file and remove a
> file"
> type patch. Are you generating it properly?
Whats the proper way to do this? I did a git mv, git commit and than git diff
on that commit hash.
> Also, why move it? Are there other modules that need to use it?
>
> t
> Also, why move it? Are there other modules that need to use it?
Fullquote from Aug, 24:
> > > > - Although i removed the dependency from ezusb to usb_serial,
> > > > ezusb.c still resides in drivers/usb/serial.
> > > > Can you give me a hint, where to put it instead?
> > > > I would like
ootable system.
Or some such. Not too clear anymore, but I remember it saved the day.
Rene.
--
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/
side the actual partitions
themselves and as such I believe not all together relevant to the issue? (as
said, not following along though...)
Rene
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
aking quick tests, doing
recovery...
If it must go for the greater architectural good, so be it, but it's the
type of thing that's used specifically in the situations where you don't
have stable, well arranged (or known!) setups to begin with.
Rene.
--
To unsubscribe from this
On 13-02-08 13:16, Michael Ellerman wrote:
On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote:
On 13-02-08 05:44, Greg KH wrote:
While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me
On 13-02-08 13:06, Rene Herman wrote:
On 13-02-08 05:44, Greg KH wrote:
While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable
been dealt with.
Rene.
--
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/
er supported if only due to to availability of the older
hardware for testing.
Rene.
--
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/
create directory `/lib/modules/2.6.25-rc2': Permission denied
How to fix?
Rene.
--
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 t
ly, I
don't object.
Did that for now...
Rene.
--
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/
> ERROR: "ezusb_fx1_ihex_firmware_download"
> [drivers/usb/serial/whiteheat.ko] undefined!
> ERROR: "ezusb_fx1_ihex_firmware_download"
> [drivers/usb/serial/keyspan_pda.ko] undefined!
> ERROR: "ezusb_fx1_set_reset" [drivers/usb/serial/keyspan_pda.ko]
> undefined!
> ERROR: "ezusb_fx1_ihex_firmware_d
On 10.12.2012, at 21:19, Alexander Graf wrote:
>
> On 10.12.2012, at 20:54, Henrik Rydberg wrote:
>
>> Hi Guenter,
>>
>>> On Mon, Dec 10, 2012 at 09:51:35AM -0500, Gabriel L. Somlo wrote:
The AppleSMC contains two char[32] keys, OSK0 and OSK1, which are not
reported in the key count
On 10.12.2012, at 22:24, Alexander Graf wrote:
> On 10.12.2012, at 21:43, Rene Rebe wrote:
>
>> On 10.12.2012, at 21:19, Alexander Graf wrote:
>>>
>>> On 10.12.2012, at 20:54, Henrik Rydberg wrote:
>>>
>>>> Hi Guenter,
>>>>
&
> > - Although i removed the dependency from ezusb to usb_serial,
> > ezusb.c still resides in drivers/usb/serial.
> > Can you give me a hint, where to put it instead?
> > I would like to do that with an additional patch.
>
> Why do you want to move it?
because is has nothing to do with an
Hello,
this is v3 of a patches-series for controllers using the ezusb-functions.
euzsb: add support for Cypress FX2LP
ezusb: add functions for firmware download
ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
--
René Bürgel
SOHARD Embedded Systems GmbH
--
To unsubscribe from thi
This Patch adds support for the newer Cypress FX2LP. It also adapts
three drivers currently using ezusb to the interface change. (whiteheat
and keyspan[_pda])
Signed-off-by: René Bürgel
---
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 3048b52d..351988d 100644
--- a
This patch adds new functions to upload firmware to the controller. The
drivers currently using ezusb are adapted to use these new functions.
This also fixes a bug occuring during firmware loading in the
whiteheat-driver:
The driver iterates over an ihex-formatted firmware using ++ on a "const
This patch moves drivers/usb/serial/ezusb.c to drivers/usb/misc/and
adapts Makefiles and Kconfigs
Signed-off-by: René Bürgel
---
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bfcd02..1c63b54 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -244,3 +
> I get the following build errors with
> this patch applied:
>
> ERROR: "ezusb_fx1_ihex_firmware_download"
> [drivers/usb/serial/whiteheat.ko] undefined!
> ERROR: "ezusb_fx1_ihex_firmware_download"
> [drivers/usb/serial/keyspan_pda.ko] undefined!
> ERROR: "ezusb_fx1_set_reset" [drivers/usb/serial
This patch moves drivers/usb/serial/ezusb.c to drivers/usb/misc/and
adapts Makefiles and Kconfigs switching from bool to tristate for
CONFIG_USB_EZUSB
Signed-off-by: René Bürgel
---
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bfcd02..1c63b54 100644
--- a/drivers/usb/m
(!x) == !!(!x) = !x, so conditions work out differently?
not the opposite, so this is a functional change...
Rene.
--
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
On 17-02-08 04:56, H. Peter Anvin wrote:
Rene Herman wrote:
On 16-02-08 20:01, H. Peter Anvin wrote:
Roel Kluin wrote:
Not entirely sure who to send this to
---
Replace !likely(x) by likely(!x)
Whoa...
Are you sure this is correct?
!likely(x) is equivalent to unlikely(!x)
Not with
nal NAK in sofar that the PIC delays were reported to be necesary
with some VIA chipsets earlier in these threads.
Rene.
--
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/
I/O delay (which the
Pentium obsoleted) I suppose it'll probably be okay even without fixing that
specifically but do note such -- it's a vital part of the problem.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On 18-02-08 22:04, Rene Herman wrote:
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a vital part
of th
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure
On 18-02-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is
of most concern here
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not
dereference pnp_dev->protocol. So do the
pnp_{stop,start}_dev() the tests protect, but let's be consistent
at least.
Spotted by Adrian Bunk <[EMAIL PROTECTED]> and the Coverity checker.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/drivers/pnp/driver.c b/driver
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure
On 20-02-08 18:05, H. Peter Anvin wrote:
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for
kernels without support for the earlier families, but if you insist...
"Only remaining o
end)
pnp_dev->protocol->suspend(pnp_dev, state);
return 0;
}
@@ -181,7 +181,7 @@
if (!pnp_drv)
return 0;
- if (pnp_dev->protocol && pnp_dev->protocol->resume)
+ if (pnp_dev->protocol->resume)
p
n pre .26 again. It introduces boot
parameters and as such becomes part of API somewhat, so if it's not going to
stay let's kill it quickly.
Ren
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Wed Feb 20 12:52:30 2008 +0100
entire development cycle I'd feel but I obviously don't feel strongly about
the issue itself.
Rene.
--
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/majordom
out ISAPnP, not PnPBIOS. No BIOS involved at
all.
Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but the
PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the pnp .probe()
method.
I'll look into providing a more extensive answer and/or test whatever comes
i
- Ursprüngliche Mail -
> On Fri, Aug 03, 2012 at 05:06:27PM +0200, René Bürgel wrote:
> > Hello,
> >
> > this is a patches-series for controllers using the ezusb-functions.
> >
> > ezusb: remove dependency to usb_serial interface
> > euzsb: add support for Cypress FX2LP
> > ezusb: add fu
This fixes an error during modpost, when ezusb is built into the kernel while
USB is built as module.
Signed-off-by: René Bürgel
--
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index a8f0523..fecde69 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -246
- Ursprüngliche Mail -
> On Thu, Nov 22, 2012 at 07:10:50PM +0100, Rene Buergel wrote:
> > This fixes an error during modpost, when ezusb is built into the
> > kernel while USB is built as module.
> thanks for the fix, I'll queue it up for 3.8
> and
> backp
This patch
- moves drivers/usb/serial/ezusb.c to drivers/usb/misc/
- renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors
- adapts Makefiles and Kconfigs switching from bool to tristate for
CONFIG_USB_EZUSB_FX2
Signed-off-by: René Bürgel
---
diff --git a/drivers/usb/misc/Kconf
> Also, does the code in fact support only FX2, neither older chips nor
> newer FX3?
It also does support the FX(1), but not FX3. At first sight, it looks like FX3
got another
register interface.
> If FX is also supported then perhaps still rename the option,
> although I think renaming is unrel
unwelcome
amounts of recompiles. Using ccache would proably be effective in this
situation but I keep neglecting to check it out...
Rene
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
lm constant_tsc pni monitor ds_cpl est cid xtpr
Run a 64-bit kernel and userspace. not a 32-bit.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
Hello,
some time ago Ingo Oeser tried to replace strtok() and noone seemed to
notice. This time it's me who believes to be on this quest.
Why? strtok() is not reentrant, it uses a global variable to store some
kind of state. As its manpage states: "Don't use this function". But right
now almost
Hi!
I have an Asus K7M motherboard with an AMD Irongate and a VIA VT82C686
connected to an IBM-DPTA-372050 and/or IBM-DTLA-307030.
I ever had IDE-DMA problems since I got the board in the beginning of
this year.
Until Kernel 2.4.0-test7 (or test6 or 8?) it was not possible to use a
ATA-66 cable
Hi!
Thanks for the fast reply - but I can't follow. What is the _tuning
aspect_ and how is it modified?
Andre Hedrick <[EMAIL PROTECTED]> wrote:
>
> There is a problem that it does not downgrade the IO if all you have is
> iCRC errors. The threshold is 10 events without other errors and it
>
Hi there, as the subject says the trident sound does not work since
2.4.0-test9. this messages does dmesg:
Trident 4DWave/SiS 7018/ALi 5451 PCI Audio, version 0.14.6, 12:36:52 Nov 20 2000
trident: Trident 4DWave DX found at IO 0xd800, IRQ 0
trident: unable to allocate irq 0
any ideas?
-
To unsubs
Jens Axboe wrote:
>
> On Mon, Aug 28 2000, Rene Mayrhofer wrote:
> > I already tried to do so, but I could not find a way.to lock the CD-ROM
> > tray on my (SCSI DVD) CD-ROM drive after it has been mounted with the door
> > not being lock. How can this be done ?
> >
v/cdrom if root should
> > be allowed to unlock under all conditions) ?
>
> I don't think that allowing root to unlock a busy tray is that big a
> deal, we have to assume he/she knows what they are doing anyway. But
> for now, you can try this patch.
Thank you, I will try it
le to allocate irq 0
orac modprobe: modprobe: Can't locate module sound-slot-0
orac modprobe: modprobe: Can't locate module sound-service-0-0
amd there isn't any sound anymore!!
It was a nice working Trident Microsystems 4DWave DX (rev 01)
in pre-10
-
Groeten / Regards, Rene Blokland
cate irq 0
>any ideas?
After removing the soundcard and inserting it again to update the pci-bios
of the mb, found out that when the srcew is tight the irq 0.
when the screw is not tight it works like a charm!
So it was a hardware problem and NOT the kernel.
Sorry and regards, Rene.
-
To unsubscr
"shared nothing" semantics where even root's processes are "cloaked".
Patch is against 2.6.12-rc2-mm2, please give it a try and tell me how
you like it.
Thanks,
Rene
diff -pur l1/Documentation/kernel-parameters.txt
l2/Documentation/kernel-parameters.txt
--- l1/
Bodo Eggert schrieb:
> On Sun, 10 Apr 2005, Rene Scharfe wrote:
>
>
>>First, configuring via kernel parameters is sufficient.
>
>
> I don't remember: Would a mount option be equally easy to implement?
> (Kernel parameters are OK for me, too.)
A mount option
kbLayout" "us"
Option "XkbOptions" "compose:rwin"
EndSection
This worked fine upto 2.6.11.7, but doesn't under 2.6.12-rc2. The key
doesn't seem to be doing anything anymore: "Compose-'-e" just gets me
"'e&quo
> the stat() call. This value is used.
What is it used for? E.g. using the group ID of /proc//stat to
determine the egid that process is running as is not reliable even
without my patch. It's better to use the group ID of the directory
/proc// instead or to look up the ID in /proc//st
Hi,
[EMAIL PROTECTED] wrote:
On 04/13/05 14:40:31, Oliver Korpilla wrote:
You might also look at www.openembedded.org It has support for cross
compiling, and with one command can build an entire userland. Not
sure if it is exactly a fit for what you want to do, but it seems
very close.
Thank
work and shouldn't change the results. I didn't went so
far and actually test the patch, so please be careful. =) Compiles fine
here, at least.
Rene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
[PATCH NFS 1/3] Lose second parameter of nfs_block_size().
Most calls to nfs_block_size() were done with a NULL pointer as second
parameter anyway. We can simply calculate the number of bits ourselves
instead of using that ugly pointer thingy.
Signed-off-by: Rene Scharfe <[EMAIL PROTEC
this is wrong. :-) The patch uses the built-in
roundup_pow_of_two() instead.
Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---
fs/nfs/inode.c | 22 +++---
1 files changed, 3 insertions(+), 19 deletions(-)
4130722d1eeb5eb22c38df9f09dfa6be554bc72c
diff --git a/fs/nfs/inode.
[PATCH NFS 2/3] Lose second parameter of nfs_block_bits
Two of the three calls were passing a NULL pointer and we can simply
calculate the number of bits ourselves.
Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---
fs/nfs/inode.c | 17 -
1 files changed, 8 insertions
, which explicitly states the
intent of nfs_block_bits()? It still needs patch 1 and 2.
Thanks,
Rene
[PATCH 3/4] Simplify and rename nfs_block_bits() to rounddown_pow_of_two()
nfs_block_bits() doesn't have a lot to do with bits anymore. It can
also be implemented simpler and clearer
Rene Herman wrote:
David Brownell wrote:
Until I have some time available to actually look at this, all I can do
is answer questions and say "hmm, that's strange" given wierd facts. The
wierdness here is why that "Async" status bit is ever getting set when
the
Lorenzo Hernández García-Hierro schrieb:
> This patch restricts non-root users to view only their own processes.
You may also want to have a look at the patches I submitted over the
last few weeks that restricted some file permissions in /proc// and
the comments I received.
Regards,
Rene
-
own_pow_of_two() belongs in kernel.h next to
roundup_pow_of_two(). And maybe it should get a shorter name.
Anyway, I also don't like "nfs_blocksize_align". So let's simply keep
the old name. Renaming can be done later if really needed.
Rene
[PATCH 3/3] Simplify nfs_block_b
milar).
Is this only about the ones then left for things like legacy PIC and PIT?
Does anyone care about just sticking in a udelay(2) (or 1) there as a
replacement and call it a day?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On 08-01-08 00:24, H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary
On 08-01-08 13:51, Bodo Eggert wrote:
On Tue, 8 Jan 2008, Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and PIT?
Does anyone care about just sticking in a udelay(2) (or 1) there as a
replacement and call it a day?
PIT is problematic because the PIT may
On 09-01-08 10:34, Frans Pop wrote:
Bjorn:
Len Brown wrote:
Well, yes, the warning is actually new as well. Previously your kernel
just silently ignored 8 more mem resources than it does now it seems.
Given that people are hitting these limits, it might make sense to just
do away with the w
ecation is considered enough instead, no need to
touch anything in drivers/, only changes to "outb(); udelay()" outside drivers/.
I'd let Alan decide here.
Thanks for the roundup.
Rene.
--
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/
istened?
Right, not use port 0x80 but since that's the current idea anyway outside of
legacy drivers, you don't actually need to listen.
If the quirk-to-0xed or similar was to stay, it's a much better switching
point than DMI strings but if not, it's not actually important.
ig
CS4236+ MPU401 PnP manual resources are invalid, using auto config
and the sound now works after resume!
So the question is: why is this line present?
Is this a bug? What's the correct fix?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
see
what catches fire.
If there are no sensible fixes, an 0x80/0xed choice could I assume be hung
of DMI or something (if that _is_ parsed soon enough).
Rene.
--
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/
On 07-12-07 08:17, Rene Herman wrote:
On 07-12-07 06:54, David P. Reed wrote:
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family?
Please do not top-post. Who knows, probably not. You just experienced
that 0x80 is apparently not safe
gacy port. Even though it may not be all that sensible a thing today
I'd say that if your machine put anything other than an actual integrated
POST monitor on port 0x80 it in fact fucked up.
I think the worst of the problems would be fixed by changing just the
CMOS_READ/CMOS_WRITE macros.
On 07-12-07 16:43, Rene Herman wrote:
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within
CMOS_READs at all. And I doubt any other chip/device needs waiting
that isn't
I don't know about CMOS, but there were definitely some not t
e than 10 years) who required IO delays in the
floppy driver and the 8253/8259. But on those the jumps are already
far too fast.
Also see Alan's replies in the thread I posted a link to:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/5700.html
Also 8254 (PIT) at least it seems.
Ren
Isn't 8 generally a bit overly long? I believe the norm is 1?
Rene.
--
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/
On 07-12-07 19:42, Alan Cox wrote:
On Fri, 07 Dec 2007 19:45:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
On 07-12-07 18:19, Alan Cox wrote:
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
You don't need to. Port 0x80 historically is about 8uS
tting themselves due to aborts on LPC together with ACPI involving
the BIOS sounds a bit suspicious (and in that case using 0xed shouldn't help
any).
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
n
x86-64, I do not have 64-bit compiler near me).
static inline void native_io_delay(void)
{
- asm volatile("outb %%al,$0x80" : : : "memory");
+ udelay(8);
}
Alan, did you double-check that 8 us? I tried to but I seem to not have
trustworthy documentation.
On 10-12-07 12:30, Krzysztof Halasa wrote:
Rene Herman <[EMAIL PROTECTED]> writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/
transaction is 1 µs, so two of them back to
back should be 2 µs, not 8 µs...
Sigh. And now where do these _two_ transactions come from? (and yes, see
Alan's folowups, a transaction on a spec bus is 1 us).
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
ssible. But if the simple udelay(1)
just works, all the better.
Rene.
--
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/
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would
On 11-12-07 14:50, David Newall wrote:
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That cou
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The "little over" I d
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test
1 - 100 of 670 matches
Mail list logo
