On 22/11/2020 下午11:36, Guenter Roeck wrote:
On Wed, Nov 11, 2020 at 03:10:08PM +0800, Charles wrote:
Add the pmbus driver for the STMicroelectronics pm6764 voltage regulator.
the output voltage use the MFR_READ_VOUT 0xD4
vout value returned is linear11
Signed-off-by: Charles Hsu
Please fix
On 3/12/2020 下午11:48, Guenter Roeck wrote:
On Thu, Dec 03, 2020 at 08:34:32PM +0800, Charles wrote:
[ ... ]
It's really weird. I sent a mail to myself, and it looks good.
@@ -220,6 +220,15 @@ config SENSORS_MP2975
This driver can also be built as a module. If so, the module
On 28/11/2020 上午12:10, Guenter Roeck wrote:
On Fri, Nov 27, 2020 at 09:59:01AM +0800, Charles wrote:
Add the pmbus driver for the STMicroelectronics pm6764 voltage regulator.
the output voltage use the MFR_READ_VOUT 0xD4
vout value returned is linear11
Signed-off-by: Charles Hsu
This patch
Add the pmbus driver for the STMicroelectronics pm6764 voltage regulator.
the output voltage use the MFR_READ_VOUT 0xD4
vout value returned is linear11
Signed-off-by: Charles Hsu
---
v4:
- Add pm6764tr to Documentation/hwmon/index.rst.
v3:
- Add Documentation(Documentation/hwmon
Avoid following compiler warning on uninitialized variable
net/ipv4/fib_semantics.c: In function ‘fib_check_nh_v4_gw’:
net/ipv4/fib_semantics.c:1023:12: warning: ‘err’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (!tbl || err) {
Signed-off-by: Charles Oliveira
unsigned long flags;
^
Signed-off-by: Charles Oliveira <18oliveira.char...@gmail.com>
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index abc705716aa0..a6af73
On Wed, Nov 28, 2012 at 06:47:28PM +, Mark Brown wrote:
> Signed-off-by: Mark Brown
> ---
> drivers/mfd/wm5102-tables.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
> index 50bbe15..065ffd3 100644
> --- a/drivers/mfd/wm
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 3aacacc..5f91711 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon
It is important to clear the wake trigger status bits otherwise DCVDD
will be held high independent of the state of the LDOENA line.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |7 +++
include/linux/mfd/arizona/registers.h |8
2 files changed, 15
wm5102_devs array was used for ARRAY_SIZE whilst adding the wm5110
devices. This change corrects this to get the size from the wm5110_devs
array. As both arrays are the same size no issues should have been
caused by this bug.
Signed-off-by: Charles Keepax
---
drivers/mfd/arizona-core.c |2
In the interrupt handler for an underclocked event, whilst checking for
the source of the interrupt, AIF3 was checked twice and AIF1 was not
checked. This change correctly checks the AIF1 underclocked bit and
reports the correct error messages for all cases.
Signed-off-by: Charles Keepax
ARIZONA_MICB1_ENA_SHIFT was used for micbias 2 and 3. This change
correctly uses the ARIZONA_MICBX_ENA_SHIFT for each corresponding DAPM
supply. This should not have caused any problems as the micbias enables
are in the same place in each register.
Signed-off-by: Charles Keepax
---
sound/soc
ive.
Maybe you should show us ur better examples. :)
Regards,
Charles
On 10/25/2012 01:40 PM, Michael Wang wrote:
Hi, Folks
Charles has raised a problem that we don't have any tool yet
for testing the scheduler with out any disturb from other
subsystem, and I also found it's hard to test sch
On Fri, Feb 15, 2008 at 1:52 PM, Chris Holvenstot wrote:
> Per chance is 2.6.25-rc2 missing in action? I see the announcement from
> about 3 and a half hours ago, but the latest patch that I see is
> rc1-git4.
>
> I even took the unheard of action of hitting refresh on my browser.
>
browse the
On Wed, Oct 31, 2012 at 04:03:59PM +0530, Laxman Dewangan wrote:
> On Monday 29 October 2012 09:44 PM, Mark Brown wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Oct 29, 2012 at 09:33:33AM +, Charles Keepax wrote:
>>> regulator_put function
The HZ you configured is 100, and cs is 350+ per second, so
there will be 3.5cs per tick. This may cause loadavg caculation
not correctly.
This problem was discussed in the following link:
https://lkml.org/lkml/2012/6/12/130
If your kernel alread has Peter's latest fix patch
sched/nohz: Rewrite
supply.
Signed-off-by: Charles Keepax
---
drivers/regulator/core.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5c4829c..e68754c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
calc_load_exit_idle depends on updated jiffies, so you shouldn't move
this before tick_do_update_jiffies64.
And why should we do nohz_balance_enter_idle in tick_nohz_idle_exit?
It's nohz_balance_exit_idle here.
Regards,
Charles
On 10/30/2012 04:27 AM, Steven Rostedt wrote
. It this case it is
necessary for each sub device to locate their supply data on the main
device.
Signed-off-by: Charles Keepax
---
Hi Mark,
Following our discussions around the Arizona regulator
bindings here is an effort at putting a mechanism into the
regulator core to alias registering of a
: Heather Lomond
Signed-off-by: Charles Keepax
---
drivers/mfd/arizona-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 5ac3aa4..e13355b 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
patch ensure that we handle the gpio default as either an out of
range value or a zero value rather than both one after the other.
Reported-by: Heather Lomond
Signed-off-by: Charles Keepax
---
Hi,
Added a bit more explanation I hope this is a little clearer.
Thanks,
Charles
drivers/mfd/arizona-c
, when we receive >0x we
should leave the device configuration at its default setting.
This patch fixes a bug and ensures that configuration 0x isn't
mistakenly written when the intention was to keep the default one.
Reported-by: Heather Lomond
Signed-off-by: Charles Keepax
st it's harder
> to add later than it would be with a struct.
Seems that it could be useful to change the supply name, I will
add this in as well.
Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
Signed-off-by: Charles Keepax
---
drivers/mfd/wm5110-tables.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
index 2a79723..92c6ea6 100644
--- a/drivers/mfd/wm5110-tables.c
+++ b/drivers/mfd
No problem sorry the commit message was a little vague there.
Seems I accidentally generated the first version of this patch
against the ASoC tree, but this got me thinking now you are
looking after MFD patches which tree should I be generating them
against?
Thanks,
Charles
On Tue, Sep 17, 2013
DSPx_CONTROL_1 and DSPx_CLOCKING_1 are not volatile registers and are
incorrectly marked as such, fix this. Also add the DSP scratch
registers, which are frequently used to output debug info from the DSP
core.
Signed-off-by: Charles Keepax
---
Version 2 of the patch, improved commit message and
The default value for the noise gate control register is changed in the
patch file, we need to reflect this in the defaults array, this patch
does so.
Signed-off-by: Charles Keepax
---
drivers/mfd/wm5110-tables.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers
Signed-off-by: Charles Keepax
---
A bit of confusion with merging this last time because I
messed up the CCs, is safe to merge this patch on its own
now.
drivers/gpio/gpio-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers
get
that works it's way up the tree but this felt rather invasive and
most places the user code does the regulator get rather than a
framework so the issue is only really likely to crop up with
regards to ASoC.
Thanks,
Charles
---
include/sound/soc-dapm.h |2 ++
sound/soc/codecs/wm5
extcon driver.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index ec9a14e..178454d 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b
rly intended to have a sub-node for each device.
For example, the GPIO driver has a similar issue if anything else
wishes to use an Arizona devices GPIO, because the GPIO driver
is on a different device to the MFD so again it can't locate it.
I haven't checked yet but I am guessing t
dev->of_node;
Looking around there seem to be quite a few drivers that copy
of_node pointers like this are we sure this isn't an acceptable
solution? I mean the arizona driver we know the components will
always be loaded as part of the MFD and thus will be freed before
the parent node.
Tha
On Sun, Sep 29, 2013 at 06:52:36PM +0100, Mark Brown wrote:
> On Sun, Sep 29, 2013 at 03:11:37PM +0100, Charles Keepax wrote:
>
> > There is currently only one other MFD driver (tps65910) which defines
> > the GPIOs on the main MFD node as we do in the Arizona driver and it
We need to use the of_node from the main Arizona device as that
holds our configuration.
Signed-off-by: Charles Keepax
---
drivers/gpio/gpio-arizona.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index
parse any data for the extcon
driver but without this patch we will attempt to use a NULL
pointer on device tree systems.
I would also be happy to implement this as a NULL check on the
pdata when we use it if that is preferable? But since we have the
cached pdata seems we might as well use it.
On Tue, Oct 01, 2013 at 08:04:09AM +0900, Chanwoo Choi wrote:
> On 09/30/2013 06:52 PM, Charles Keepax wrote:
> > On Mon, Sep 30, 2013 at 08:37:30AM +0900, Chanwoo Choi wrote:
> >> No, extcon-arizona driver don't currently support DT to get platform data.
> >> I
We had specified the mask twice for FLL2_SYNC_BW change the first mask
definition in a bit definition to match the other fields.
Signed-off-by: Charles Keepax
---
include/linux/mfd/arizona/registers.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mfd
Every other pdata field is specified unshifted the patch handles
shifting for the MICBIAS from the microphone detection polarity
configurations in the extcon driver rather than demanding it in
pdata to match other fields.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |9
We should move range when the measured value is greater than or equal to
the max value not when greater than.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers
Add device tree bindings for the pdata that configures the microphone
button detection and microphone detection polarity configurations.
Signed-off-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/arizona.txt | 26 +
drivers/mfd/arizona-core.c| 116
Add device tree bindings for the pdata max_channels_clocked, that allows
the user to limit the number of channels clocked on a single AIF.
Signed-off-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/arizona.txt |7 +++
drivers/mfd/arizona-core.c|5
Factor out reading of specific device tree bindings into seperate
functions in preperation for adding more of them. Whilst we are at is
fixup a couple of small issues in the existing binding documentation.
Signed-off-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/arizona.txt
Add device tree bindings for the pdata needed to configure the MICBIAS
generators.
Signed-off-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/arizona.txt | 15
drivers/mfd/arizona-core.c| 25 +
2 files changed, 40
Add device tree bindings for several of simpler microphone detection
pdata fields.
Signed-off-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/arizona.txt | 23 +
drivers/mfd/arizona-core.c| 22
2 files changed, 45
On Mon, Sep 23, 2013 at 03:36:36PM -0600, Stephen Warren wrote:
> On 09/23/2013 12:30 PM, Charles Keepax wrote:
> > - - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply,
> > CPVDD-supply,
> > + - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-su
On Tue, Sep 24, 2013 at 12:28:32AM +0100, Mark Brown wrote:
> On Mon, Sep 23, 2013 at 03:38:10PM -0600, Stephen Warren wrote:
> > On 09/23/2013 12:30 PM, Charles Keepax wrote:
>
> > > + - wlf,max-channels-clocked : The maximum number of channels to be
> > >
here using the of_compatible field on the mfd_cell.
Signed-off-by: Charles Keepax
---
Hi,
Another issue with the Arizona bindings, I am not sure
exactly what the best approach is this patch seems like the
"correct" fix, but it does require a change to the binding,
although the current
On 10/05/2012 09:39 AM, Jonathan Nieder wrote:
Peter Zijlstra wrote:
I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c
contains both hunks, but in that case the fixup 749c8814f0 doesn't make
sense, not can I find anything in merge commits using:
git log -S calc_load_exit
On 10/06/2012 01:23 AM, Peter Zijlstra wrote:
On Fri, 2012-10-05 at 10:10 -0700, Jonathan Nieder wrote:
Peter Zijlstra wrote:
On Thu, 2012-10-04 at 15:27 -0700, Greg Kroah-Hartman wrote:
I'm puzzled as well. Any ideas if I should do anything here or not?
So I think the current v3.5.5 code
: Charles Keepax
---
drivers/mfd/arizona-core.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 1b48f20..1d241ea 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -366,6
On Tue, Nov 13, 2012 at 02:56:20PM +0900, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 05:56:48PM +0000, Charles Keepax wrote:
> > In the absence of a physical reset line the chip is reset by writing the
> > first register, this was done after the register patch was applied which
holding the mutex, replacing the aforementioned
call.
Signed-off-by: Charles Keepax
Cc: Laxman Dewangan
---
I hope this isn't bad etiquette but I took the liberaty of fixing up
the patch as per the comments and taking into account the removal of
my original patch. Apologies if this is no
support multiplexed single input blocks into the Arizona
platform.
Signed-off-by: Charles Keepax
---
sound/soc/codecs/arizona.h | 40
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h
There is no mixer attached to the ASRC on the wm5102 only a multiplexer
to select the source for the single input line. This change correctly
defines this in the wm5102 CODEC driver.
Signed-off-by: Charles Keepax
---
sound/soc/codecs/wm5102.c | 24
1 files changed, 12
There is no mixer attached to the ASRC on the wm5110 only a multiplexer
to select the source for the single input line. This change correctly
defines this in the wm5110 CODEC driver.
Signed-off-by: Charles Keepax
---
sound/soc/codecs/wm5110.c | 24
1 files changed, 12
aforementioned call.
Signed-off-by: Charles Keepax
Cc: Laxman Dewangan
---
drivers/regulator/core.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1a35251..390e173 100644
--- a/drivers
On Wed, Nov 14, 2012 at 10:20:09AM +0900, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 01:12:19PM +0000, Charles Keepax wrote:
> > On Tue, Nov 13, 2012 at 02:56:20PM +0900, Mark Brown wrote:
>
> > > No, we should never write to the chip until we have successfully
> > >
In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.
Signed-off-by: Charles Keepax
In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.
Signed-off-by: Charles Keepax
In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.
Signed-off-by: Charles Keepax
On Tue, Nov 06, 2012 at 04:04:09PM +0530, Laxman Dewangan wrote:
> When regulator_register() failed due to non availability of
> mutex_unlock(®ulator_list_mutex);
...
> }
> EXPORT_SYMBOL_GPL(regulator_put);
> @@ -3453,11 +3460,10 @@ scrub:
> gpio_free(rdev->ena_gpio);
>
device pointer.
This patch defines a device_type for mfd devices and checks this is
present from mfd_remove_devices_fn before processing the device.
Signed-off-by: Charles Keepax
---
drivers/mfd/mfd-core.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a
device pointer.
This patch defines a device_type for mfd devices and checks this is
present from mfd_remove_devices_fn before processing the device.
Signed-off-by: Charles Keepax
---
drivers/mfd/mfd-core.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a
; and "load_entity.c"?
Thanks,
Charles
On Thu, Apr 18, 2013 at 4:13 PM, Paul Gortmaker
wrote:
[Re: [RFC PATCH 0/2] sched: move content out of core files for load average] On
18/04/2013 (Thu 23:06) Rakib Mullick wrote:
On Thu, Apr 18, 2013 at 9:54 PM, Paul Gortmaker
wrote:
On 13-04-18
The pci-me.c code contains 2 dev_err() calls which are apparently left
over from debugging; they do not represent actual error conditions.
They do produce messages in a "quiet" kernel, and add ERROR entries to
the logger.
Signed-off-by: "charles anthony"
Linux 3.10-rc6
duplicate detection code path.
Reported-by: Ryo Tsutsui
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 7a1b4a7..4df68de 100644
--- a
We should move range when the measured value is greater than or equal to
the max value not when greater than.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers
Signed-off-by: Charles Keepax
---
drivers/regulator/core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e3661c2..0218a93 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2535,7 +2535,7
From: Charles Wang
Positive load weight of rq.cfs can not represent positive load weight
of se->cfs_rq. And when se->cfs_rq's load is 0, the slice calculated
by sched_slice is not that sensible.
Use se->cfs_rq for load checking instead of rq->cfs. And correct the
comments.
Cc
This patch clears the DMA flags when a DMA channel is requested. This is
necessary because otherwise the channel may inherit incompatible
settings from its last usage.
Signed-off-by: Charles Keepax
---
arch/arm/mach-s3c64xx/dma.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
>From Charles Wang
Azat Khuzhin reported "high loadavg in linux-3.6"
After checking for upstream's code, I found Peter's patch
(Commit id:5167e8d5417bf5c322a703d2927daec727ea40dd) not be
fully applied, missing the call for calc_load_exit_idle.
After that idle exit in samp
No email address provided by Azat Khuzhin, so I don't know
how to let him know this. - -!
On 08/20/2012 04:02 PM, Charles Wang wrote:
From Charles Wang
Azat Khuzhin reported "high loadavg in linux-3.6"
After checking for upstream's code, I found Pete
Verbose output variable is unnecessary because the command's echo is
already surpressed. Additionally because the block defines skip-makefile
the variable Q is not defined within the makefile, which can cause
problems if Q is defined in the users environment.
Signed-off-by: Charles K
On Sat, Feb 23, 2008 at 02:08:35PM +0100, J.C. Pizarro wrote:
>
> But if the repos are aggressively repacked then the bit to bit differences
> are not ~2 MiB.
It shouldn't matter how aggressively the repositories are packed or what
the binary differences are between the pack files are. git clone
On Sat, Feb 23, 2008 at 02:36:59PM +0100, J.C. Pizarro wrote:
> On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote:
> >
> > It shouldn't matter how aggressively the repositories are packed or what
> > the binary differences are between the pack files are.
(The ultimate cause of what I'm about to tell you may well be a chipset
problem, but I think I've uncovered a tiny bit of kernel weirdness none
the less)
Using 2.4.0
modprobe agpgart.o
/var/log/messages says
>Jan 10 14:11:56 x kernel: Linux agpgart interface v0.99 (c) Jeff
> Hartmann
> Jan 10
My problem was that I didn't pay enough attention to the configuration
options. I opted for *both* the 440LX/BX/GX, 815, 840, 850 support
(CONFIG_AGP_INTEL) *and* I810/I815 (on-board) support (CONFIG_AGP_I810).
The latter was taking precedence over the former, and getting confused.
Petr Vandrov
r such) -- voila, no more problem, no broken kernel patches.
Charles
--
------
Charles Cazabon <[EMAIL PROTECTED]>
My opinions do not necessarily represent those of my employer.
for patching.
Would anybody happen to have a current list of
working patches for a decent implementation of software raid1 using the 2.2.18
kernel that employs some level of read performance that exceeds that of 1
harddisk?
Regards,
Charles
I can confirm this problem exists in Mandrake-7.2 as well with kernel
2.2.17-21.
- Original Message -
From: "John Covici" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 21, 2000 1:37 PM
Subject: strange nfs behavior in 2.2.18 and 2.4.0-test12
> Hi. I am having str
I have been running with the 2 onboard VIA ide hd
controllers (ide 0 and ide 1) along with a creative labs ide contoller on a SB32
soundcard (ide 3). This has had the cdrom and zip drive.
I just added a Promise Ultra100 and it has assumed
the role of ide 3 and ide 4. The onboard controllers
> "Charles Wilkins wrote:"
> > I have been running with the 2 onboard VIA ide hd controllers (ide 0 and
=
> > ide 1) along with a creative labs ide contoller on a SB32 soundcard (ide
=
> > 2). This has had the cdrom and zip drive.
> >
> > I just adde
> > Charles Wilkins wrote:
> >
> > Is there a max number of ide controllers that linux-2.2.18 can
> > support?
>
Andrzej M. Krzysztofowicz says,
>"Linux supports up to 10 IDE channels, however channel numbers of PCI
controllers seem to be assigned first.&q
Here is what worked.
append="ide6=0x168,0x36e,10"
Thanks all for your help.
Merry Christmas : )
> > Charles Wilkins writes:
> > > I have ide.2.2.18.1209.patch applied. The kernel is 2.2.18.
> > > So what is the answer? 4 controllers max or 10 for my kernel?
&
The cciss driver is for our next generation of array controllers.
Besides adding the complexity of a single driver, there is also a question
of regression testing a single driver. The cpqarray driver has support for
all our controllers back to the EISA based controllers.
---
here it doesn't matter if they where
> improperly closed (if possible).
Mount the filesystem read-only if you want this.
> 3. Swap may not contain anything which can't be discarded. Otherwise
> swap has to be treated as ordinary disk space.
The kernel doesn'
x27;s an interested novice out there who wants to
learn how to configure a kernel, they'll be sufficiently interested to invest
an hour or two in learning how the whole process works. Make it as simple as
it needs to be, and no simpler.
Charles
--
-
to worry about shipping three or four modular kernels. Any user
who cares about the minor performance benefits of a custom-configured kernel
is going to reconfigure and recompile regardless of how dumbed-down the
interface is.
Charles
--
--
rpose. Many workstation CPUs have a similar feature, and the other x86
manufacturers either do or have plans to include such a beast.
Charles
--
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed softw
into the kernel would allow us to have a
consistent and reliable way of passing the data we need from kernel
space into user space.
In essence, relayfs is a basic infrastructure upon which other tools can
be built - whether that's profiling, debugging, logging, etc.
-- charles
> -Ori
retty clearly in the GPL itself.
Charles
--
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:
.
Sorry if this is a bit vague, but I'm not sure what type of
information you require to locate the bug.
Regards
Charles Mydlak
-
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://
> The flags field in struct nfs_inode is protected by the BKL. The
> following two code paths (there may be more, but my test program only
> hits these two) modify the flags without obtaining the lock:
>
> nfs_end_data_update
> nfs_release
> nfs_file_release
> __fput
> fput
>
For those interested, there is a discussion regarding pmu usage and
kernel functionality requirements happening on the perfctr mailing list
([EMAIL PROTECTED]). The goal is to understand what
functionality people need so that we can eventually have better support
for pmu's in the kernel.
-
To unsub
e that might be some help to you.
Good luck,
Charles
--
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/
ally, not if you mention the licence of the code clearly.
I'm not sure that's the case. Inclusion of significant chunks of source code
(not just a dozen lines or whatever) might bring the book into "derived work"
territory, and your publisher is almost certainl
oard trace complexity (and therefore number of layers) goes up. Add to
that that the potential market goes down as CPUs goes up.
You can buy 4-, 8-, and 16-way motherboards for Intel CPUs (don't know about
more). But the 16-way ones will cost as
J.D. Bakker <[EMAIL PROTECTED]> wrote:
> At 13:42 -0600 20-06-2001, Charles Cazabon wrote:
> >Rodrigo Ventura <[EMAIL PROTECTED]> wrote:
> > > BTW, I have a question: Can the availability of dual-CPU boards for
> > > intel and amd processors, ra
To: White, Charles; [EMAIL PROTECTED]; Alan
Cox; Arrays
Subject:PATCH: cciss small pci id table patch
Hi,
The cciss driver in 2.4.5-ac19 is missing the terminating
{0,}.
Ciao, Marcus
Index: drivers
it's possible (and common) to see problems in one OS
where another appears to run fine.
Download memtest86 and test your system with 256MB in it -- if it reports any
problems, it's definitely hardware.
Charles
--
------
1 - 100 of 2017 matches
Mail list logo
