Re: [GIT PULL] MMC updates
On Wed, 12 Dec 2007 20:12:47 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: > Linus, please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus > *ping* -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- 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/
Re: [PATCH] arch/ia64/: Spelling fixes
Joe, I'm curious, do you have a patch that actually fixes something and adds value to the code? Maybe you could include the spelling fix with that to improve the S/N ratio? In addition, posting a patch with no commit comment is no good, please read through Documentation/SubmittingPatches before posting an update to this. Thanks, Jes Joe Perches wrote: Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- arch/ia64/sn/pci/tioce_provider.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ia64/sn/pci/tioce_provider.c b/arch/ia64/sn/pci/tioce_provider.c index cee9379..e1a3e19 100644 --- a/arch/ia64/sn/pci/tioce_provider.c +++ b/arch/ia64/sn/pci/tioce_provider.c @@ -41,7 +41,7 @@ * } else * do desired mmr access * - * According to hw, we can use reads instead of writes to the above addres + * According to hw, we can use reads instead of writes to the above address * * Note this WAR can only to be used for accessing internal MMR's in the * TIOCE Coretalk Address Range 0x0 - 0x07ff_. This includes the -- 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/
Re: [rfc][patch 1/3] block: non-atomic queue_flags prep
On Sat, Dec 15 2007, Nick Piggin wrote: > Hi, > > This is just an idea I had, which might make request processing a little > bit cheaper depending on queue behaviour. For example if it is getting plugged > unplugged frequently (as I think is the case for some database workloads), > then we might save one or two atomic operations per request. > > Anyway, I'm not completely sure if I have ensured all queue_flags users are > safe (I think md may need a bit of help). But overall it seems quite doable. Looks ok to me, I'll throw it into the testing mix. Thanks Nick! -- Jens Axboe -- 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/
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, Dec 17, 2007 at 08:28:00PM -0800, Andrew Morton wrote: >... > I'd suggest that you find out if Adrian is still running the trivial tree > and if so, patchbomb him. I do. Simply Cc [EMAIL PROTECTED] for trivial patches and they might magically appear in Linus' tree during the next merge window. :) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/
Re: [PATCH -mm -v3] x86 boot : export boot_params via sysfs
On Mon, 2007-12-17 at 21:34 -0700, Eric W. Biederman wrote: > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > > This is directly analogous to how we treat identity information in IDE, or > > PCI > > configuration space -- some fields are pre-digested, but the entire raw > > information is also available. > > Add to that a totally unchanged value can just be easier to get correct. > > Still the kexec code as much as it can should not look there, as we may > get the same basic information in a couple of different ways. > > EFI memmap vs. e820 for example. If/when that is the case /sbin/kexec > should get the information and spit it out into whatever format makes > sense for the destination kernel. My sense is just passing through > values is brittleness where we don't want it. > > However I think being able to get at the raw boot information overall > sounds useful. I just don't know if it is generally useful or just > useful when debugging bootloaders though. If struct boot_params as a whole is useless for kexec, I can move it to debugfs, because kexec is the only normal user now. Then which fields of struct boot_params do you think is useful for kexec? Refer to include/asm-x86/bootparam.h edid_info? e820_entries and e820_map? maybe useful for kdump edd related fields (eddbuf, edd_mbr_sig_buffer, etc)? split fields until fundamental types? Best Regards, Huang Ying -- 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/
Re: [PATCH]: Atmel Serial Console interrupt handler splitup
Hello Haavard,
> > Yep. All calls that block on a Mutex somehow on Preempt-RT. (such as
> > spinlocks, wakeup_interruptible() and many of its friends.)
> Right. Looks like the DMA patch call these functions from irq context
> too...I guess it'll need the same treatment?
That is correct. DMA code does do that, but the DMA code is not used
for DBGU, and _only_ the interrupt handler of DBGU runs in
IRQF_NODELAY context (because it is part of the System-IRQ and thus
shared with the timer-irq). The DMA code always runs in IRQ-thread
context, where it is safe to block on a mutex.
So, it is not mandatory to change that also. (It may be nice to do it anyway)
> > > > +struct atmel_uart_char {
> > > > + unsigned int status;
> > > > + unsigned int overrun;
> > > > + unsigned int ch;
> > > > + unsigned int flg;
> > > > +};
> > >
> > > Hmm. 16 bytes per char is a bit excessive, isn't it? How about
> > >
> > > struct atmel_uart_char {
> > > u16 ch;
> > > u16 status;
> > > };
> > >
> > > where ch is the received character (up to 9 bits) and status is the
> > > lowest 16 bits of the status register?
> > I used the NODELAY patch for the 8250 serial port as reference, it
> > contains similar code, and I tried to make both look the same.
> Ok, I see. But...
> > > > +#define ATMEL_SERIAL_RINGSIZE 1024
> This means that the buffer ends up at 16K. Since the buffer itself is
> kept in a struct along with a few other pieces of data, we end up
> kmalloc()ing 32KB of memory...
Oops... 32kB on X86 is not much, relatively, on ARM it is somewhat different.
We can also decrease the total RingSize, 128 would be good enough also.
I can look at it later this week.
> I'm a bit tempted to just go ahead and do the changes we agree on and
> post the result. Then I'll see if I can make the DMA stuff behave. I've
> got a different driver lying around which is DMA-only and has a few
> problems on its own.
Beware that, according to several older discussions, DBGU cannot make
use of DMA... (If I understood it correctly, it was because the buffer
first have to be full, before an interupt is generated. That would be
very annoying while typing 1 character at the time ;-)
> Also, I think the DMA patch needs to be more integrated with your
> "interrupt handler splitup" patch. No point in keeping two RX buffers
> around, and the DMA code needs to obey the same rules as the rest of
> the driver if it's going to work in -rt.
As mentioned, not necessarily...
> And I'd really like to have working DMA support on avr32 before
> christmas ;-)
Me too ;-)
Kind Regards,
Remy
--
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/
Re: [RFC/PATCH 2/8] revoke: inode revoke lock V7
Hi Serge,
(Thanks for looking at this. I appreciate the review!)
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
> > struct vfsmount *mnt = nd->mnt;
> > - struct dentry *dentry = __d_lookup(nd->dentry, name);
> > + struct dentry *dentry;
> >
> > +again:
> > + dentry = __d_lookup(nd->dentry, name);
> > if (!dentry)
> > goto need_lookup;
> > +
> > + if (dentry->d_inode && IS_REVOKE_LOCKED(dentry->d_inode)) {
>
> not sure whether this is a problem or not, but dentry->d_inode isn't
> locked here, right? So nothing is keeping do_lookup() returning
> with an inode which gets revoked between here and the return 0
> a few lines down?
I assume you mean S_REVOKE_LOCK and not ->i_mutex, right?
The caller is supposed to block open(2) with chmod(2)/chattr(2) so while
revoke is in progress, you can get references to the _revoked inode_,
which is fine (operations on it will fail with EBADFS). The
->i_revoke_wait bits are there to make sure that while we revoke, you
can't get a _new reference_ to the inode until we're done.
Pekka
--
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/
[PATCH RFC] hrtimers: add slop parameter
(I don't really like this patch yet, but wanted to get something out there)
After discussion with Thomas Gleixner, we came up with the idea of
introducing a new parameter to hrtimers (and probably eventually all
timers in the kernel, then onto userspace). I call it "slop", and it
is an indication of how precise a timer should be.
The idea is that this "slop" can be used to calculate what timers can
be batched, and maybe even eventually unify normal and high res timers.
A timer should fire no earlier than its expiry, but we don't care if it's
delayed until after expiry+slop.
For this patch, DEFAULT_SLOP (currently 0) is used everywhere, and
the parameter is unused.
diff -r 0eabf082c13a drivers/kvm/lapic.c
--- a/drivers/kvm/lapic.c Tue Dec 18 13:51:13 2007 +1100
+++ b/drivers/kvm/lapic.c Tue Dec 18 15:04:33 2007 +1100
@@ -968,7 +968,8 @@ int kvm_create_lapic(struct kvm_vcpu *vc
memset(apic->regs, 0, PAGE_SIZE);
apic->vcpu = vcpu;
- hrtimer_init(&apic->timer.dev, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ hrtimer_init(&apic->timer.dev, CLOCK_MONOTONIC, HRTIMER_MODE_ABS,
+DEFAULT_SLOP);
apic->timer.dev.function = apic_timer_fn;
apic->base_address = APIC_DEFAULT_PHYS_BASE;
vcpu->apic_base = APIC_DEFAULT_PHYS_BASE;
diff -r 0eabf082c13a drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Tue Dec 18 13:51:13 2007 +1100
+++ b/drivers/net/virtio_net.c Tue Dec 18 15:04:33 2007 +1100
@@ -403,7 +403,8 @@ static int virtnet_probe(struct virtio_d
netif_napi_add(dev, &vi->napi, virtnet_poll, 16);
vi->dev = dev;
vi->vdev = vdev;
- hrtimer_init(&vi->tx_timer, CLOCK_REALTIME, HRTIMER_MODE_REL);
+ hrtimer_init(&vi->tx_timer, CLOCK_REALTIME, HRTIMER_MODE_REL,
+DEFAULT_SLOP);
vi->tx_timer.function = kick_xmit;
vi->tx_timer.cb_mode = HRTIMER_CB_SOFTIRQ;
vi->out_max = -1U;
diff -r 0eabf082c13a include/linux/hrtimer.h
--- a/include/linux/hrtimer.h Tue Dec 18 13:51:13 2007 +1100
+++ b/include/linux/hrtimer.h Tue Dec 18 15:04:33 2007 +1100
@@ -100,6 +100,7 @@ enum hrtimer_cb_mode {
* @cb_mode: high resolution timer feature to select the callback execution
* mode
* @cb_entry: list head to enqueue an expired timer into the callback list
+ * @slop: how much extra delay can be added (eg. for deferring wakeups)
* @start_site:timer statistics field to store the site where the timer
* was started
* @start_comm: timer statistics field to store the name of the process which
@@ -118,6 +119,7 @@ struct hrtimer {
#ifdef CONFIG_HIGH_RES_TIMERS
enum hrtimer_cb_modecb_mode;
struct list_headcb_entry;
+ ktime_t slop;
#endif
#ifdef CONFIG_TIMER_STATS
void*start_site;
@@ -256,8 +258,9 @@ extern ktime_t ktime_get_real(void);
/* Exported timer functions: */
/* Initialize timers: */
+#define DEFAULT_SLOP ((ktime_t) { .tv64 = 0 })
extern void hrtimer_init(struct hrtimer *timer, clockid_t which_clock,
-enum hrtimer_mode mode);
+enum hrtimer_mode mode, ktime_t slop);
/* Basic timer operations: */
extern int hrtimer_start(struct hrtimer *timer, ktime_t tim,
diff -r 0eabf082c13a kernel/fork.c
--- a/kernel/fork.c Tue Dec 18 13:51:13 2007 +1100
+++ b/kernel/fork.c Tue Dec 18 15:04:33 2007 +1100
@@ -874,7 +874,8 @@ static int copy_signal(unsigned long clo
init_sigpending(&sig->shared_pending);
INIT_LIST_HEAD(&sig->posix_timers);
- hrtimer_init(&sig->real_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&sig->real_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL,
+DEFAULT_SLOP);
sig->it_real_incr.tv64 = 0;
sig->real_timer.function = it_real_fn;
sig->tsk = tsk;
diff -r 0eabf082c13a kernel/futex.c
--- a/kernel/futex.cTue Dec 18 13:51:13 2007 +1100
+++ b/kernel/futex.cTue Dec 18 15:04:33 2007 +1100
@@ -1247,7 +1247,8 @@ static int futex_wait(u32 __user *uaddr,
if (!abs_time)
schedule();
else {
- hrtimer_init(&t.timer, CLOCK_MONOTONIC,
HRTIMER_MODE_ABS);
+ hrtimer_init(&t.timer, CLOCK_MONOTONIC,
HRTIMER_MODE_ABS,
+DEFAULT_SLOP);
hrtimer_init_sleeper(&t, current);
t.timer.expires = *abs_time;
@@ -1344,7 +1345,8 @@ static int futex_lock_pi(u32 __user *uad
if (time) {
to = &timeout;
- hrtimer_init(&to->timer, CLOCK_REALTIME, HRTIMER_MODE_ABS);
+ hrtimer_init(&to->timer, CLOCK_REALTIME, HRTIMER_MODE_ABS,
+DEFAULT_SLOP);
hrtimer_init_sleeper(to, current);
to->timer.expires = *time;
}
dif
Re: [RFC] [patch 1/2] add non_init_kernel_text_address
On Tuesday 18 December 2007 17:46:15 Srinivasa Ds wrote: > Rusty Russell wrote: > > On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote: > >> On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote: > >>> regular_kernel_text_address()? Dunno. > >> > >> Sounds better :-) > > > > The better answer was to invert it and use > > "discarded_kernel_text_address()", which is what you actually care about > > (rather than the details of whether it was init or not). > > Requirement is to ensure the address is really a kernel_text address and > doesn't lie in __init section. Hence I used > persistent_kernel_text_address(). Hi Srinivasa! That's not my point. What you care about is that the text still be there. The fact that it's the __init section which is discarded is a detail; if some other text section were discarded you'd want that excluded too. Hence non_init_ was a bad name; persistent is a bad name because it usually means something else in operating systems... > > However, you have, in fact, located a potential bug. If someone were to > > kmalloc module text, then symbol_put() could fail. > > I don't think so, symbol_put() makes use of lookup_symbol() within > __start_ksymtab and stop_ksymtab. Sorry, I meant symbol_put_addr(). > > How's this? > > --- > > Don't report discarded init pages as kernel text. > > > > In theory this could cause a bug in symbol_put() if an arch used for > > a module: we might think the symbol belongs to the core kernel. > > Yes, usage of symbol_put_addr() cause the BUG() if it fails > to find the address in core kernel. No, symbol_put_addr() will fail to decrement the module count, thinking it's part of the (now-discarded) init section. > > The downside is that this might make backtraces through (discarded) > > init functions harder to read on some archs. > > I think it is better to make use of new function than sacrificing > __init function symbol information in backtrace. Perhaps, but two new functions is v. ugly. I'll try to come up with something neater, and audit all the callers. Thanks, Rusty. -- 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/
About mounting the sysfs
Hi all,
Currently, I'm studying the code of the sysfs. But I got the
following questions:
1. What is the d_alloc_root used for? Actually, the question should
be: why we have to call d_alloc_root. I think the root already has its
dentry, why we have to allocate another while we mounting a file
system?
2. Why we call d_alloc_root to allocate a dentry for the mount point
while the usual mount point of sysfs is defined by the user (something
like /sysfs but not /). See below:
root = d_alloc_root(inode);
if (!root) {
pr_debug("%s: could not get root dentry!\n",__FUNCTION__);
iput(inode);
return -ENOMEM;
}
root->d_fsdata = &sysfs_root;
sb->s_root = root;
does this means settting the sysfs' mount point to "/" but not "/sysfs".
Thanks.
--Zhanhua
--
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/
Re: [PATCH] drivers/parisc/: Spelling fixes
Andrew,
ditto - thanks
On Mon, Dec 17, 2007 at 11:40:10AM -0800, Joe Perches wrote:
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
thanks again,
grant
> ---
> drivers/parisc/ccio-dma.c |4 ++--
> drivers/parisc/hppb.c |2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
> index 7c60cbd..ca52307 100644
> --- a/drivers/parisc/ccio-dma.c
> +++ b/drivers/parisc/ccio-dma.c
> @@ -363,7 +363,7 @@ ccio_alloc_range(struct ioc *ioc, size_t size)
> if (pages_needed <= 8) {
> /*
>* LAN traffic will not thrash the TLB IFF the same NIC
> - * uses 8 adjacent pages to map seperate payload data.
> + * uses 8 adjacent pages to map separate payload data.
>* ie the same byte in the resource bit map.
>*/
> #if 0
> @@ -1589,7 +1589,7 @@ static int __init ccio_probe(struct parisc_device *dev)
> }
>
> /**
> - * ccio_init - ccio initalization procedure.
> + * ccio_init - ccio initialization procedure.
> *
> * Register this driver.
> */
> diff --git a/drivers/parisc/hppb.c b/drivers/parisc/hppb.c
> index a728a7c..65eee67 100644
> --- a/drivers/parisc/hppb.c
> +++ b/drivers/parisc/hppb.c
> @@ -95,7 +95,7 @@ static struct parisc_driver hppb_driver = {
> };
>
> /**
> - * hppb_init - HP-PB bus initalization procedure.
> + * hppb_init - HP-PB bus initialization procedure.
> *
> * Register this driver.
> */
> --
> 1.5.3.7.949.g2221a6
--
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/
Re: [PATCH 1/5] power: RFC: introduce a new power API
On Mon, 17 Dec 2007 14:24:16 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 02:41:39AM -0500, Andres Salomon wrote:
> [...]
> > > > On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
> > > > > This API has the power_supply drivers device their own
> > > > > device_attribute
> > > > > list; I find this to be a lot more flexible and cleaner.
> > >
> > > I don't see how this is more flexible and cleaner. See below.
> > >
> > > > > For example,
> > > > > rather than having a function with a huge switch statement (as
> > > > > olpc_battery
> > > > > currently has), we have separate callback functions.
> > >
> > > Is this an improvement? Look into ds2760_battery.c. I scared to
> > > imagine what it will look like after conversion.
> >
[...]
>
> I see your point now. Basically, now I'm encourage to think just one
> more time: is there third (better) option in addition to current and
> this? I still hope there is some not obvious, but elegant solution.
> If there isn't, I'm ready to surrender and will help with everything
> I can.
>
Hm. It occurs to me that there's nothing keeping us from having a
single callback for the driver properties. Keeping the other patches
the same, do you prefer the following approach versus what was originally
in patch#3?
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index af7a231..1c63dcb 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -50,50 +50,71 @@
* Power
*/
-static int olpc_ac_get_prop(struct power_supply *psy,
- enum power_supply_property psp,
- union power_supply_propval *val)
+static ssize_t olpc_ac_is_online(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
- int ret = 0;
+ int ret;
uint8_t status;
- switch (psp) {
- case POWER_SUPPLY_PROP_ONLINE:
- ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, &status, 1);
- if (ret)
- return ret;
-
- val->intval = !!(status & BAT_STAT_AC);
- break;
- default:
- ret = -EINVAL;
- break;
- }
+ ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, &status, 1);
+ if (!ret)
+ sprintf(buf, "%d\n", !!(status & BAT_STAT_AC));
return ret;
}
-static enum power_supply_property olpc_ac_props[] = {
- POWER_SUPPLY_PROP_ONLINE,
+static struct device_attribute olpc_ac_props[] = {
+ POWER_SUPPLY_ONLINE(olpc_ac_is_online),
+ POWER_SUPPLY_END
};
static struct power_supply olpc_ac = {
.name = "olpc-ac",
.type = POWER_SUPPLY_TYPE_MAINS,
- .properties = olpc_ac_props,
- .num_properties = ARRAY_SIZE(olpc_ac_props),
- .get_property = olpc_ac_get_prop,
+ .props = (struct device_attribute **) &olpc_ac_props,
};
/*
* Battery properties
*/
-static int olpc_bat_get_property(struct power_supply *psy,
-enum power_supply_property psp,
-union power_supply_propval *val)
+
+enum olpc_props {
+ /* should retain the same order as olpc_bat_props */
+ OLPC_PROP_STATUS = 0,
+ OLPC_PROP_PRESENT,
+ OLPC_PROP_HEALTH,
+ OLPC_PROP_TECHNOLOGY,
+ OLPC_PROP_VOLTAGE_AVG,
+ OLPC_PROP_CURRENT_AVG,
+ OLPC_PROP_CAPACITY,
+ OLPC_PROP_TEMP,
+ OLPC_PROP_TEMP_AMBIENT,
+ OLPC_PROP_MANUFACTURER,
+}
+
+static int olpc_bat_get_property(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static struct device_attribute olpc_bat_props[] = {
+ POWER_SUPPLY_STATUS(olpc_bat_get_property),
+ POWER_SUPPLY_PRESENT(olpc_bat_get_property),
+ POWER_SUPPLY_HEALTH(olpc_bat_get_property),
+ POWER_SUPPLY_TECHNOLOGY(olpc_bat_get_property),
+ POWER_SUPPLY_VOLT_AVG(olpc_bat_get_property),
+ POWER_SUPPLY_CURR_AVG(olpc_bat_get_property),
+ POWER_SUPPLY_CAPACITY(olpc_bat_get_property),
+ POWER_SUPPLY_TEMP(olpc_bat_get_property),
+ POWER_SUPPLY_TEMP_AMB(olpc_bat_get_property),
+ POWER_SUPPLY_MFR(olpc_bat_get_property),
+ POWER_SUPPLY_END
+};
+
+static int olpc_bat_get_property(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
int ret = 0;
int16_t ec_word;
uint8_t ec_byte;
+ ptrdiff_t prop = attr - olpc_bat_props;
ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, &ec_byte, 1);
if (ret)
@@ -105,37 +126,38 @@ static int olpc_bat_get_property(struct power_supply *psy,
It doesn't matter though -- the EC will return the last-known
information, and it's as if
Re: [PATCH 24/28] AFS: Add a function to excise a rejected write from the pagecache [try #2]
On Tuesday 18 December 2007 09:54, David Howells wrote: > Nick Piggin <[EMAIL PROTECTED]> wrote: > > This reintroduces the fault vs truncate race window, which must be fixed. > > Hmmm... perhaps. What do you mean by perhaps? > I remember that cropped up in NFS, but I'm doing things > a bit differently to NFS. Remind me again how that worked please. How what worked? NFS is using invalidate inode pages quite frequently so it ran into the race more often. > > Also, it is adding a fair bit of complexity in an area where we should > > instead be reducing it. I think your filesystem should not be doing > > writeback caching of dirty data in the cases where it is so problematic > > (or at least, disallow mmap and read on the dirty data until it has been > > written back or failed). > > Eh? It's a stateless network filesystem. There's a gap between writing to > a file (perhaps though an mmap) and the pagecache pages being written back > in which someone may change the security on a file and block the writeback. > There's nothing I can do to prevent it, so I have to instead deal with the > consequences should they arise. See the description of patch 25 for > examples. > > So you say I shouldn't do any writeback caching at all? No, you could do writeback caching but disallow read of dirty data. But yeah, a coherent mmap isn't possible then, I guess. > > But otherwise I guess if you really want to discard the dirty data after > > a failed writeback attempt, what's wrong with just > > invalidate_inode_pages2? > > Erm... Because it deadlocks? Why don't you call it after calling end_page_writeback? -- 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/
Re: [PATCH] include/asm-parisc/: Spelling fixes
Andrew, Please include in -mm. "Cosmetic" - but I appreciate correct spelling too. On Mon, Dec 17, 2007 at 11:30:11AM -0800, Joe Perches wrote: > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Signed-off-by: Grant Grundler <[EMAIL PROTECTED]> thanks, grant > --- > include/asm-parisc/elf.h |2 +- > include/asm-parisc/linkage.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/asm-parisc/elf.h b/include/asm-parisc/elf.h > index f628ac7..8e7946a 100644 > --- a/include/asm-parisc/elf.h > +++ b/include/asm-parisc/elf.h > @@ -28,7 +28,7 @@ > #define EFA_PARISC_1_1 0x0210 /* PA-RISC 1.1 big-endian. > */ > #define EFA_PARISC_2_0 0x0214 /* PA-RISC 2.0 big-endian. > */ > > -/* Additional section indeces. */ > +/* Additional section indices. */ > > #define SHN_PARISC_ANSI_COMMON 0xff00 /* Section for tenatively > declared > symbols in ANSI C. */ > diff --git a/include/asm-parisc/linkage.h b/include/asm-parisc/linkage.h > index ad8cd0d..0b19a72 100644 > --- a/include/asm-parisc/linkage.h > +++ b/include/asm-parisc/linkage.h > @@ -8,7 +8,7 @@ > > /* > * In parisc assembly a semicolon marks a comment while a > - * exclamation mark is used to seperate independent lines. > + * exclamation mark is used to separate independent lines. > */ > #ifdef __ASSEMBLY__ > > -- > 1.5.3.7.949.g2221a6 > > - > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/
Re: [PATCH 09/28] FS-Cache: Release page->private after failed readahead [try #2]
On Tuesday 18 December 2007 09:42, David Howells wrote: > Nick Piggin <[EMAIL PROTECTED]> wrote: > > This is pretty nasty. > > Why? If the fs doesn't set PG_private or PG_fscache on any pages before > calling read_cache_pages(), there's no difference. It is conceptually wrong. > Furthermore, the differences only crop up in the error handling paths. That doesn't make it any better. > > I would suggest either to have the function return the number of pages > > that were added to pagecache, > > Which helps how? So the caller can do their own error handling / cleanup. > > or just open code it. > > Well, I could give an alternative read_cache_pages(), I suppose, for just > this situation, but that means there are two parallel functions which then > both need to be maintained. I would be OK with that. -- 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/
Re: [PATCH 10/28] FS-Cache: Recruit a couple of page flags for cache management [try #2]
On Tuesday 18 December 2007 09:36, David Howells wrote: > Nick Piggin <[EMAIL PROTECTED]> wrote: > > I'd much prefer if you would handle this in the filesystem, and have it > > set PG_private whenever fscache needs to receive a callback, and DTRT > > depending on whether PG_fscache etc. is set or not. > > That's tricky and slower[*]. One of the things I want to do is to modify > iso9660 to do be able to do caching, but PG_private is 'owned' by the > generic buffer cache code. Maybe it is harder, but it is the right way to do it. So you should modify the filesystems rather than core code. -- 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/
Re: Top kernel oopses/warnings this week
Theodore Tso wrote: On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote: which also gets bonus points for being totally unreadable, and thus 100% in the spirit of uuid's. Heh. UUID's don't have to be readable; just universally unique. Code on the other hand should be readable. :-) Linus' suggested... improvement should either be done in all 3 places or none ;) Since you're the maintainer... what's your suggestion? If you want something more readable, you could print the MAC address and boot time. Of course some crazy people seem to think leaking the MAC address will somehow be a privacy violation. And printing a random UUID is a lot simpler boot UUID is nice in that it's different each boot, so that an oops that happens twice will have a different UUID even if it's the same machine, while repeat-reports of the same oops will have the same UUID. So I very much like to use some form of UUID; since the boot UUID has the same properties I was happy to share this; if it gets too ugly or evil code wise I can always pick something else ;-) -- 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/
[GIT PULL] XFS update for 2.6.24-rc6
Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_file.c |4 ++-- fs/xfs/xfs_dir2_block.c |6 ++ fs/xfs/xfs_dir2_leaf.c |2 +- fs/xfs/xfs_dir2_sf.c|9 +++-- fs/xfs/xfs_inode.c |6 -- 5 files changed, 12 insertions(+), 15 deletions(-) through these commits: commit 041388b54ed95cd169546bd83bacd08ee32bd7ea Author: Lachlan McIlroy <[EMAIL PROTECTED]> Date: Tue Dec 18 16:19:34 2007 +1100 [XFS] Put the correct offset in dirent d_off The recent filldir regression fix was not putting the correct d_off in each dirent. This was resulting in incorrect cookies being passed to dmapi ioctls and the wrong offset appearing in the dirents. readdir was unaffected as the filp->f_pos was being updated with the correct offset and this was being written into the last dirent in each buffer. Fix the XFS code to do the right thing. SGI-PV: 973746 SGI-Modid: xfs-linux-melb:xfs-kern:30240a Signed-off-by: David Chinner <[EMAIL PROTECTED]> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Lachlan McIlroy <[EMAIL PROTECTED]> commit c734c79bc397eace039bea406997efa89f879c14 Author: Lachlan McIlroy <[EMAIL PROTECTED]> Date: Tue Dec 18 16:17:41 2007 +1100 [XFS] Don't wait for pending I/Os when purging blocks beyond eof. On last close of a file we purge blocks beyond eof. The same code is used when we truncate the file size down. In this case we need to wait for any pending I/Os for dirty pages beyond the new eof. For the last close case we are not changing the file size and therefore do not need to wait for any I/Os to complete. This fixes a performance bottleneck where writes into the page cache and cache flushes can become mutually exclusive. SGI-PV: 964002 SGI-Modid: xfs-linux-melb:xfs-kern:30220a Signed-off-by: Lachlan McIlroy <[EMAIL PROTECTED]> Signed-off-by: Peter Leckie <[EMAIL PROTECTED]> -- 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/
Re: [PATCH] sysctl: Fix ax25 checks
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Mon, 17 Dec 2007 15:44:08 -0700 > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Applied, thanks Eric. -- 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/
Re: [RFC] [patch 1/2] add non_init_kernel_text_address
Rusty Russell wrote: On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote: On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote: regular_kernel_text_address()? Dunno. Sounds better :-) The better answer was to invert it and use "discarded_kernel_text_address()", which is what you actually care about (rather than the details of whether it was init or not). Requirement is to ensure the address is really a kernel_text address and doesn't lie in __init section. Hence I used persistent_kernel_text_address(). However, you have, in fact, located a potential bug. If someone were to kmalloc module text, then symbol_put() could fail. I don't think so, symbol_put() makes use of lookup_symbol() within __start_ksymtab and stop_ksymtab. How's this? --- Don't report discarded init pages as kernel text. In theory this could cause a bug in symbol_put() if an arch used for a module: we might think the symbol belongs to the core kernel. Yes, usage of symbol_put_addr() cause the BUG() if it fails to find the address in core kernel. The downside is that this might make backtraces through (discarded) init functions harder to read on some archs. I think it is better to make use of new function than sacrificing __init function symbol information in backtrace. Thanks Srinivasa DS -- 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/
[PATCH] eCryptfs: Change the type of cipher_code from u16 to u8
Only one byte of cipher_code is being written to the file header so it should be of type u8. Trevor 0001-Change-the-type-of-cipher_code-from-u16-to-u8.txt Description: application/mbox
Re: [PATCH] ia64: Avoid unnecessary TLB flushes when allocating memory
On Tue, 18 Dec 2007 01:00:15 -0500
Kyle McMartin <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 18, 2007 at 10:05:45AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 13 Dec 2007 15:03:07 +
> >
> > > + if (mm != active_mm) {
> > > + /* Restore region IDs for mm */
> > > + if (mm && active_mm) {
> > > + activate_context(mm);
> > > + } else {
> > > + flush_tlb_all();
> > > + return;
> > > + }
> > > }
> > should be
> >
>
> platform_global_tlb_purge is already (and afaict, only) called under
> preempt_disable already. then again, the sn2 global_tlb_purge
> does it, so possibly for completeness sake it should be added here as
> well?
>
Thank you. I see. flush_tlb_range() is the only caller.
...maybe adding comment is helpful (for me :).
Thanks,
-Kame
--
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/
[PATCH] eCryptfs: Load each file decryption key only once
There is no need to set the decryption key every time eCryptfs decrypts an extent. Trevor 0001-eCryptfs-Load-each-file-decryption-key-only-once.patch Description: application/mbox
Re: init_timer_deferrable conversion
On Dec 17, 2007 9:29 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote: > Parag, could you please try this patch ? > > [NET] ARP : Convert neigh garbage collection from softirq to workqueue > I will - a little later. Thanks Parag -- 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/
[PATCH x86/mm] x86: TLS desc_struct cleanup
This cleans up the x86 TLS code to use desc_struct in place of hand-coded
bit-twiddling, and cleans up a few of the inlines for the type too.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/tls.c | 89
include/asm-x86/desc.h | 16 ++-
include/asm-x86/processor_32.h | 18 +++-
include/asm-x86/processor_64.h | 48 +
4 files changed, 86 insertions(+), 85 deletions(-)
diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c
index 98f428b..f11c92a 100644
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -24,6 +24,29 @@ static int get_free_idx(void)
return -ESRCH;
}
+static void set_tls_desc(struct task_struct *p, int idx,
+const struct user_desc *info)
+{
+ struct thread_struct *t = &p->thread;
+ struct desc_struct *desc = &t->tls_array[idx - GDT_ENTRY_TLS_MIN];
+ int cpu;
+
+ /*
+* We must not get preempted while modifying the TLS.
+*/
+ cpu = get_cpu();
+
+ if (LDT_empty(info))
+ desc->a = desc->b = 0;
+ else
+ fill_ldt(desc, info);
+
+ if (t == ¤t->thread)
+ load_TLS(t, cpu);
+
+ put_cpu();
+}
+
/*
* Set a given TLS descriptor:
*/
@@ -31,10 +54,7 @@ int do_set_thread_area(struct task_struc
struct user_desc __user *u_info,
int can_allocate)
{
- struct thread_struct *t = &p->thread;
struct user_desc info;
- u32 *desc;
- int cpu;
if (copy_from_user(&info, u_info, sizeof(info)))
return -EFAULT;
@@ -57,23 +77,8 @@ int do_set_thread_area(struct task_struc
if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
return -EINVAL;
- desc = (u32 *) &t->tls_array[idx - GDT_ENTRY_TLS_MIN];
-
- /*
-* We must not get preempted while modifying the TLS.
-*/
- cpu = get_cpu();
-
- if (LDT_empty(&info)) {
- desc[0] = 0;
- desc[1] = 0;
- } else
- fill_ldt((struct desc_struct *)desc, &info);
+ set_tls_desc(p, idx, &info);
- if (t == ¤t->thread)
- load_TLS(t, cpu);
-
- put_cpu();
return 0;
}
@@ -87,21 +92,29 @@ asmlinkage int sys_set_thread_area(struc
* Get the current Thread-Local Storage area:
*/
-#define GET_LIMIT(desc)(((desc)[0] & 0x0) | ((desc)[1] &
0xf))
-#define GET_32BIT(desc)(((desc)[1] >> 22) & 1)
-#define GET_CONTENTS(desc) (((desc)[1] >> 10) & 3)
-#define GET_WRITABLE(desc) (((desc)[1] >> 9) & 1)
-#define GET_LIMIT_PAGES(desc) (((desc)[1] >> 23) & 1)
-#define GET_PRESENT(desc) (((desc)[1] >> 15) & 1)
-#define GET_USEABLE(desc) (((desc)[1] >> 20) & 1)
-#define GET_LONGMODE(desc) (((desc)[1] >> 21) & 1)
+static void fill_user_desc(struct user_desc *info, int idx,
+ const struct desc_struct *desc)
+
+{
+ memset(info, 0, sizeof(*info));
+ info->entry_number = idx;
+ info->base_addr = get_desc_base(desc);
+ info->limit = get_desc_limit(desc);
+ info->seg_32bit = desc->d;
+ info->contents = desc->type >> 2;
+ info->read_exec_only = !(desc->type & 2);
+ info->limit_in_pages = desc->g;
+ info->seg_not_present = !desc->p;
+ info->useable = desc->avl;
+#ifdef CONFIG_X86_64
+ info->lm = desc->l;
+#endif
+}
int do_get_thread_area(struct task_struct *p, int idx,
struct user_desc __user *u_info)
{
- struct thread_struct *t = &p->thread;
struct user_desc info;
- u32 *desc;
if (idx == -1 && get_user(idx, &u_info->entry_number))
return -EFAULT;
@@ -108,21 +122,8 @@ int do_get_thread_area(struct task_struc
if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
return -EINVAL;
- desc = (u32 *) &t->tls_array[idx - GDT_ENTRY_TLS_MIN];
-
- memset(&info, 0, sizeof(struct user_desc));
- info.entry_number = idx;
- info.base_addr = get_desc_base((struct desc_struct *)desc);
- info.limit = GET_LIMIT(desc);
- info.seg_32bit = GET_32BIT(desc);
- info.contents = GET_CONTENTS(desc);
- info.read_exec_only = !GET_WRITABLE(desc);
- info.limit_in_pages = GET_LIMIT_PAGES(desc);
- info.seg_not_present = !GET_PRESENT(desc);
- info.useable = GET_USEABLE(desc);
-#ifdef CONFIG_X86_64
- info.lm = GET_LONGMODE(desc);
-#endif
+ fill_user_desc(&info, idx,
+ &p->thread.tls_array[idx - GDT_ENTRY_TLS_MIN]);
if (copy_to_user(u_info, &info, sizeof(info)))
return -EFAULT;
diff --git a/include/asm-x86/desc.h b/include/asm-x86/desc.h
index 161a6d6..000 100644
--- a/include/asm-x86/desc.h
+++ b/include/asm-x86/desc.h
@@ -7,7 +7,8 @@
#include
#include
Re: [PATCH] ia64: Avoid unnecessary TLB flushes when allocating memory
On Tue, Dec 18, 2007 at 10:05:45AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 13 Dec 2007 15:03:07 +
>
> > + if (mm != active_mm) {
> > + /* Restore region IDs for mm */
> > + if (mm && active_mm) {
> > + activate_context(mm);
> > + } else {
> > + flush_tlb_all();
> > + return;
> > + }
> > }
> should be
>
platform_global_tlb_purge is already (and afaict, only) called under
preempt_disable already. then again, the sn2 global_tlb_purge
does it, so possibly for completeness sake it should be added here as
well?
regards, kyle
--
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/
[PATCH] Avoid overflows in kernel/time.c (version 5)
When the conversion factor between jiffies and milli- or microseconds is not a single multiply or divide, as for the case of HZ == 300, we currently do a multiply followed by a divide. The intervening result, however, is subject to overflows, especially since the fraction is not simplified (for HZ == 300, we multiply by 300 and divide by 1000). This is exposed to the user when passing a large timeout to poll(), for example. This patch replaces the multiply-divide with a reciprocal multiplication on 32-bit platforms. When the input is an unsigned long, there is no portable way to do this on 64-bit platforms there is no portable way to do this since it requires a 128-bit intermediate result (which gcc does support on 64-bit platforms but may generate libgcc calls, e.g. on 64-bit s390), but since the output is a 32-bit integer in the cases affected, just simplify the multiply-divide (*3/10 instead of *300/1000). The reciprocal multiply used can have off-by-one errors in the upper half of the valid output range. This could be avoided at the expense of having to deal with a potential 65-bit intermediate result. Since the intent is to avoid overflow problems and most of the other time conversions are only semiexact, the off-by-one errors were considered an acceptable tradeoff. At Ralf Baechle's suggestion, this version uses a Perl script to compute the necessary constants. We already have dependencies on Perl for kernel compiles. This does, however, require the Perl module Math::BigInt, which is included in the standard Perl distribution starting with version 5.8.0. In order to support older versions of Perl, include a table of canned constants in the script itself, and structure the script so that Math::BigInt isn't required if pulling values from said table. Running the script requires that the HZ value is available from the Makefile. Thus, this patch also adds the Kconfig variable CONFIG_HZ to the architectures which didn't already have it (alpha, cris, frv, h8300, m32r, m68k, m68knommu, sh64, sparc, v850, and xtensa.) It does *not* resolve a weird case in the sh architecture, where HZ != CONFIG_HZ if CONFIG_SH_WDT is set. Paul Mundt has been contacted about that, and has agreed to fix it up. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> --- Delta from previous version: remove redundant dependency in kernel/Makefile. arch/alpha/Kconfig|5 + arch/cris/Kconfig |4 + arch/frv/Kconfig |4 + arch/h8300/Kconfig|4 + arch/m32r/Kconfig |4 + arch/m68k/Kconfig |4 + arch/m68knommu/Kconfig|5 + arch/sh64/Kconfig |6 + arch/sparc/Kconfig|4 + arch/v850/Kconfig |7 + arch/xtensa/Kconfig |4 + include/asm-alpha/param.h | 10 +- include/asm-cris/param.h |2 +- include/asm-frv/param.h |2 +- include/asm-h8300/param.h |2 +- include/asm-m32r/param.h |2 +- include/asm-m68k/param.h |2 +- include/asm-m68knommu/param.h |8 +- include/asm-sh64/param.h |6 +- include/asm-sparc/param.h |2 +- include/asm-v850/anna.h |6 - include/asm-v850/as85ep1.h|6 - include/asm-v850/fpga85e2c.h |6 - include/asm-v850/param.h |3 +- include/asm-v850/rte_cb.h |6 - include/asm-v850/sim.h|5 - include/asm-v850/sim85e2.h|6 - include/asm-xtensa/param.h|2 +- kernel/Makefile |8 + kernel/time.c | 29 +++- kernel/timeconst.pl | 340 + 31 files changed, 431 insertions(+), 73 deletions(-) create mode 100644 kernel/timeconst.pl diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 4c002ba..442e4e7 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -616,6 +616,11 @@ config VERBOSE_MCHECK_ON Take the default (1) unless you want more control or more info. +config HZ + int + default 1200 if ALPHA_RAWHIDE + default 1024 + source "drivers/pci/Kconfig" source "drivers/eisa/Kconfig" diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index 222da15..fcc6a9e 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -55,6 +55,10 @@ config CRIS bool default y +config HZ + int + default 100 + source "init/Kconfig" menu "General setup" diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index 43153e7..57bdf2d 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -57,6 +57,10 @@ config ARCH_HAS_ILOG2_U64 bool default y +config HZ + int + default 1000 + mainmenu "Fujitsu FR-V Kernel Configuration" source "init/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index ff6a871..8a40a6f 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -79,6 +79,10 @@ config PCI bool default n +config HZ + int +
Re: [PATCH 3/21] [PATCH] move desc_empty to where they belong
> I'll have a TLS cleanup patch soon that makes the (only) use of desc_empty > pass a struct user_desc pointer. Oops, I meant struct desc_struct of course. But in fact the only use is already using the right struct pointer, so we can clean up desc_empty now (in x86/mm). Thanks, Roland -- 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/
Re: [PATCH] scripts/checkpatch.pl: add a check for the patch level (patch -p)
On Mon, Dec 17, 2007 at 08:11:05AM +0100, Borislav Petkov wrote:
A slightly microoptimized version 1.1:
---
From: Borislav Petkov <[EMAIL PROTECTED]>
Check the patch level of the single hunks in a patch file, however only when
checkpatch.pl is called from within the kernel tree.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
--
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..3eda27b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -653,6 +653,18 @@ sub CHK {
}
}
+sub check_patchlevel {
+
+ if ($tree) {
+ my ($path) = @_;
+ $path =~ s![^/]*/!!;
+
+ if (!stat($path)) {
+ WARN("Check the patchlevel (hint: patch option -p)");
+ }
+ }
+}
+
sub process {
my $filename = shift;
my @lines = @_;
@@ -713,10 +725,16 @@ sub process {
#extract the filename as it passes
if ($line=~/^\+\+\+\s+(\S+)/) {
$realfile=$1;
+
+ if ($realfile) {
+ check_patchlevel($realfile);
+ }
+
$realfile =~ [EMAIL PROTECTED]/]*/@@;
$in_comment = 0;
next;
}
+
#extract the line range in the file after the patch is applied
if ($line=~/[EMAIL PROTECTED]@ -\d+(?:,\d+)? \+(\d+)(,(\d+))?
[EMAIL PROTECTED]@/) {
$is_patch = 1;
--
Regards/Gruß,
Boris.
--
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/
Re: [PATCH] drivers/infiniband/: Spelling fixes
what the heck, applied -- 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/
Re: [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter.
Rusty Russell wrote: On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote: This patch changes the bitwise operations in bitops.h to get a void pointers as a parameter. Before this patch, a lot of warnings can be seen. They're gone after it. No, this is a backwards step! These warnings are important for non-arch-specific code: I fought hard to get them made into unsigned longs. But I'm happy for this to be applied as is, then I'll grab the git tree, revert it and fix the warnings... Yes, it's particularly nasty as it'll work fine on littleendian arches, and fail on bigendian arches... -hpa -- 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/
kobject_add failed for tts/0 (-13)-EACCES
Greetings! System details: Board: DTSP-ARM926Ej-S(new board) Cross-toolchain: ELDK4.1 Linux kernel: 2.6.18 u-boot: 1.1.6 I have been able to successfully run u-boot and linux kernel with root file system but when kernel is start the following error message come.."kobject_add failed for tts/0 (-13)" The complete log is following: U-Boot 1.1.6 (Dec 14 2007 - 19:27:49) DRAM: 64 MB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 Flash ## Booting image at 0001 ... Image Name: Linux-2.6.18-DRM Image Type: ARM Linux Kernel Image (uncompressed) Data Size:627476 Bytes = 612.8 kB Load Address: 08008000 Entry Point: 08008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.18-DRM ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #18 Fri Dec 14 18:34:58 KST 2007 CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 Machine: DTSP Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-back cache CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets Built 1 zonelists. Total pages: 16128 Kernel command line: root=/dev/ram0 mem=63M initrd=0xA00,6M ramdisk=16384 console=ttyS0,38400 init=/linuxrc PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 63MB = 63MB total Memory: 56448KB available (984K code, 248K data, 68K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 6144K dtsp_init() - platform_add_device - for serial NetWinder Floating Point Emulator V0.97 (double precision) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered serial_dtsp_init() serial_dtsp_probe() dtsp_uart.0: tts/0 at MMIO 0x2020 (irq = 2) is a ttyS kobject_add failed for tts/0 (-13) [] (dump_stack+0x0/0x14) from [] (kobject_add+0x168/0x1a4) [] (kobject_add+0x0/0x1a4) from [] (class_device_add+0x88/0x420) r8 = C0114240 r7 = 0CC00040 r6 = C3E11BC0 r5 = C0323440 r4 = C0323440 [] (class_device_add+0x0/0x420) from [] (class_device_register+0x1c/0x20) [] (class_device_register+0x0/0x20) from [] (class_device_create+0x8c/0xc4) r4 = C0323440 [] (class_device_create+0x0/0xc4) from [] (tty_register_device+0xc8/0xe8) [] (tty_register_device+0x0/0xe8) from [] (uart_add_one_port+0x22c/0x2a0) r7 = C011FAE4 r6 = 0002 r5 = r4 = 6013 [] (uart_add_one_port+0x0/0x2a0) from [] (serial_dtsp_probe+0x40/0x60) [] (serial_dtsp_probe+0x0/0x60) from [] (platform_drv_probe+0x20/0x24) r7 = C011FB84 r6 = r5 = C0114240 r4 = C0114310 [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_device+0x7c/0xcc) [] (driver_probe_device+0x0/0xcc) from [] (__driver_attach+0x84/0xe4) r7 = C011FB84 r6 = C00E9B08 r5 = C0114240 r4 = C0114310 [] (__driver_attach+0x0/0xe4) from [] (bus_for_each_dev+0x48/0x80) r5 = C01FBF18 r4 = [] (bus_for_each_dev+0x0/0x80) from [] (driver_attach+0x20/0x28) r7 = C011FB98 r6 = C011FEFC r5 = C011FB84 r4 = [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0x6c/0x128) [] (bus_add_driver+0x0/0x128) from [] (driver_register+0x90/0xa0) r8 = r7 = r6 = C01FA000 r5 = C00172D8 r4 = C011FB84 [] (driver_register+0x0/0xa0) from [] (platform_driver_register+0x6c/0x88) r4 = [] (platform_driver_register+0x0/0x88) from [] (serial_dtsp_init+0x2c/0x50) [] (serial_dtsp_init+0x0/0x50) from [] (init+0x88/0x26c) r4 = C0017814 [] (init+0x0/0x26c) from [] (do_exit+0x0/0x814) r7 = r6 = r5 = r4 = RAMDISK driver initialized: 1 RAM disks of 16384K size 1024 blocksize mice: PS/2 mouse device common for all mice RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing init memory: 68K /etc/init.d/rcS: /etc/init.d/rcS: 2: mount: not found Please press Enter to activate this console. BusyBox v1.1.3 (2007.12.13-08:41+) Built-in shell (ash) Enter 'help' for a list of built-in commands. # Please help me to sort out this problem. I have very little experience on this type of work. Thanks in Advance... Manoj Khandelwal Software Engineer -- View this message in context: http://www.nabble.com/kobject_add-failed-for-tts-0-%28-13%29-EACCES-tp14384475p14384475.html Sent from the linux-kernel mailing list archive at Nabble.com. -- To unsu
Re: [PATCH] Avoid overflows in kernel/time.c (version 4)
> diff --git a/kernel/Makefile b/kernel/Makefile > index dfa9695..749825a 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -80,3 +80,11 @@ quiet_cmd_ikconfiggz = IKCFG $@ > targets += config_data.h > $(obj)/config_data.h: $(obj)/config_data.gz FORCE > $(call if_changed,ikconfiggz) > + > +$(obj)/time.o: $(obj)/timeconst.h > + > +quiet_cmd_timeconst = TIMEC $@ > + cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@ > +targets += timeconst.h > +$(obj)/timeconst.h: $(src)/timeconst.pl $(wildcard include/config/hz.h) FORCE > + $(call if_changed,timeconst) The prerequisite $(wildcard include/config/hz.h) is not needed. You will run the perl script if: - timeconst.h is missing - if commandline changes (new CONFIG_HZ value) Otherwise it looks OK to me. Sam -- 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/
Re: [PATCH 3/21] [PATCH] move desc_empty to where they belong
I'll have a TLS cleanup patch soon that makes the (only) use of desc_empty pass a struct user_desc pointer. Thanks, Roland -- 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/
[RFC][PATCH 3/4][AGP] intel_agp: add support for graphics dma remapping on G33
[PATCH] [AGP] intel_agp: add support for graphics dma remapping on G33
When graphics dma remapping engine is active, we must fill
gart table with dma address from dmar engine, as now graphics
device access to graphics memory must go through dma remapping
table to get real physical address.
Add support on G33 chipset, which has graphics device specific
dmar engine avaiable.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/char/agp/Kconfig | 12 +++-
drivers/char/agp/intel-agp.c | 134 +-
2 files changed, 141 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
index ccb1fa8..e60c2b0 100644
--- a/drivers/char/agp/Kconfig
+++ b/drivers/char/agp/Kconfig
@@ -74,8 +74,16 @@ config AGP_INTEL
on Intel 440LX/BX/GX, 815, 820, 830, 840, 845, 850, 860, 875,
E7205 and E7505 chipsets and full support for the 810, 815, 830M,
845G, 852GM, 855GM, 865G and I915 integrated graphics chipsets.
-
-
+
+config AGP_INTEL_DMAR
+ bool
+ depends on AGP_INTEL && DMAR && !DMAR_GFX_WA
+ default y
+ help
+ This option will enable graphics address remapping with Intel
+ DMAR engine aka VT-d if you don't select graphics workaround on
+ Intel DMAR. The graphics address filled to gart table will be
+ changed by remapping within graphics DMAR engine for domain.
config AGP_NVIDIA
tristate "NVIDIA nForce/nForce2 chipset support"
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index d879619..7424667 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -9,6 +9,9 @@
#include
#include
#include "agp.h"
+#ifdef CONFIG_AGP_INTEL_DMAR
+#include
+#endif
#define PCI_DEVICE_ID_INTEL_82946GZ_HB 0x2970
#define PCI_DEVICE_ID_INTEL_82946GZ_IG 0x2972
@@ -115,6 +118,97 @@ static struct _intel_private {
int gtt_entries;/* i830+ */
} intel_private;
+static int intel_agp_require_remapping(void)
+{
+#ifdef CONFIG_AGP_INTEL_DMAR
+ return intel_iommu_gfx_remapping();
+#else
+ return 0;
+#endif
+}
+
+#ifdef CONFIG_AGP_INTEL_DMAR
+static int intel_agp_map_pages(struct agp_memory *mem, void *virt, dma_addr_t
*ret, int is_single)
+{
+ int i;
+ struct scatterlist *sg;
+
+ if (is_single) {
+ *ret = pci_map_single(intel_private.pcidev, virt, PAGE_SIZE,
+ PCI_DMA_BIDIRECTIONAL);
+ if (pci_dma_mapping_error(*ret))
+ return -EINVAL;
+ return 0;
+ }
+
+ DBG("try mapping %lu pages\n", (unsigned long)mem->page_count);
+
+ if ((mem->page_count * sizeof(*mem->sg_list)) < 2*PAGE_SIZE)
+ mem->sg_list = kcalloc(mem->page_count, sizeof(*mem->sg_list),
GFP_KERNEL);
+
+ if (mem->sg_list == NULL) {
+ mem->sg_list = vmalloc(mem->page_count * sizeof(*mem->sg_list));
+ mem->sg_vmalloc_flag = 1;
+ }
+
+ if (!mem->sg_list) {
+ mem->sg_vmalloc_flag = 0;
+ return -ENOMEM;
+ }
+ sg_init_table(mem->sg_list, mem->page_count);
+
+ sg = mem->sg_list;
+ for (i = 0 ; i < mem->page_count; i++, sg = sg_next(sg))
+ sg_set_buf(sg, gart_to_virt(mem->memory[i]), PAGE_SIZE);
+
+ mem->num_sg = pci_map_sg(intel_private.pcidev, mem->sg_list,
+ mem->page_count, PCI_DMA_BIDIRECTIONAL);
+ if (mem->num_sg == 0) {
+ if (mem->sg_vmalloc_flag)
+ vfree(mem->sg_list);
+ else
+ kfree(mem->sg_list);
+ mem->sg_list = NULL;
+ mem->sg_vmalloc_flag = 0;
+ return -ENOMEM;
+ }
+ mem->is_mapped = TRUE;
+ return 0;
+}
+
+static void intel_agp_unmap_pages(struct agp_memory *mem, dma_addr_t addr, int
is_single)
+{
+ if (is_single) {
+ pci_unmap_single(intel_private.pcidev, addr, PAGE_SIZE,
+ PCI_DMA_BIDIRECTIONAL);
+ return;
+ }
+ DBG("try unmapping %lu pages\n", (unsigned long)mem->page_count);
+
+ if (!mem->is_mapped)
+ return;
+
+ if (mem->num_sg)
+ pci_unmap_sg(intel_private.pcidev, mem->sg_list,
mem->page_count,
+ PCI_DMA_BIDIRECTIONAL);
+ if (mem->sg_vmalloc_flag)
+ vfree(mem->sg_list);
+ else
+ kfree(mem->sg_list);
+ mem->sg_vmalloc_flag = 0;
+ mem->sg_list = NULL;
+ mem->num_sg = 0;
+}
+#else
+static int intel_agp_map_pages(struct agp_memory *mem, void *virt, dma_addr_t
*ret, int is_single)
+{
+return 0;
+}
+static void intel_agp_unmap_pages(struct agp_memory *mem, dma_addr_t addr, int
is_single)
+{
+}
+#endif
+
static int intel_i810_fetch_size(void)
{
u32 smram_miscc;
@@ -
[RFC][PATCH 2/4][AGP] Add generic support for graphics dma remapping
[PATCH] [AGP] Add generic support for graphics dma remapping
New driver hooks for support graphics memory dma remapping
are introduced in this patch. It makes generic code can
tell if current device needs dma remapping, then call driver
provided interfaces for mapping and unmapping. Change has
also been made to handle scratch_page in remapping case.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/char/agp/agp.h | 14 ++
drivers/char/agp/backend.c | 21 -
drivers/char/agp/generic.c | 14 ++
include/linux/agp_backend.h |7 +++
4 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index b83824c..7806da1 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -118,6 +118,18 @@ struct agp_bridge_driver {
void *(*agp_alloc_page)(struct agp_bridge_data *);
void (*agp_destroy_page)(void *, int flags);
int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
+
+ /* Tell current graphics dma remapping engine status, there might
+* be driver or platform specific way to detect. */
+ int (*agp_require_remapping)(void);
+
+ /* This can support single page remapping via void *virt for like
+* scratch_page, or normal bunch of mem page range via struct
+* agp_memory *mem.
+*/
+ int (*agp_map_page)(struct agp_memory *mem, void *virt, dma_addr_t
*ret, int is_single);
+
+ void (*agp_unmap_page)(struct agp_memory *mem, dma_addr_t ret, int
is_single);
};
struct agp_bridge_data {
@@ -132,6 +144,8 @@ struct agp_bridge_data {
u32 *gatt_table_real;
unsigned long scratch_page;
unsigned long scratch_page_real;
+ dma_addr_t scratch_page_dma;
+ u8 scratch_page_is_mapped;
unsigned long gart_bus_addr;
unsigned long gatt_bus_addr;
u32 mode;
diff --git a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
index 832ded2..cc6d648 100644
--- a/drivers/char/agp/backend.c
+++ b/drivers/char/agp/backend.c
@@ -151,7 +151,20 @@ static int agp_backend_initialize(struct agp_bridge_data
*bridge)
bridge->scratch_page_real = virt_to_gart(addr);
bridge->scratch_page =
- bridge->driver->mask_memory(bridge,
bridge->scratch_page_real, 0);
+ bridge->driver->mask_memory(bridge,
bridge->scratch_page_real, 0);
+
+ if (bridge->driver->agp_require_remapping &&
+ bridge->driver->agp_require_remapping()) {
+ if (bridge->driver->agp_map_page(NULL, addr,
&bridge->scratch_page_dma, 1)) {
+ printk(KERN_ERR PFX "unable to map scratch
page\n");
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ bridge->scratch_page_is_mapped = TRUE;
+ bridge->scratch_page =
+ bridge->driver->mask_memory(bridge,
+ bridge->scratch_page_dma, 0);
+ }
}
size_value = bridge->driver->fetch_size();
@@ -189,6 +202,9 @@ static int agp_backend_initialize(struct agp_bridge_data
*bridge)
err_out:
if (bridge->driver->needs_scratch_page) {
+ if (bridge->scratch_page_is_mapped)
+ bridge->driver->agp_unmap_page(NULL,
bridge->scratch_page_dma, 1);
+
bridge->driver->agp_destroy_page(gart_to_virt(bridge->scratch_page_real),
AGP_PAGE_DESTROY_UNMAP);
flush_agp_mappings();
@@ -217,6 +233,9 @@ static void agp_backend_cleanup(struct agp_bridge_data
*bridge)
if (bridge->driver->agp_destroy_page &&
bridge->driver->needs_scratch_page) {
+ if (bridge->scratch_page_is_mapped)
+ bridge->driver->agp_unmap_page(NULL,
bridge->scratch_page_dma, 1);
+
bridge->driver->agp_destroy_page(gart_to_virt(bridge->scratch_page_real),
AGP_PAGE_DESTROY_UNMAP);
flush_agp_mappings();
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index 64b2f6d..8966c94 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -415,6 +415,14 @@ int agp_bind_memory(struct agp_memory *curr, off_t
pg_start)
curr->bridge->driver->cache_flush();
curr->is_flushed = TRUE;
}
+
+ if (curr->bridge->driver->agp_require_remapping &&
+ curr->bridge->driver->agp_require_remapping()) {
+ ret_val = curr->bridge->driver->agp_map_page(curr, NULL, NULL,
0);
+ if (ret_val)
+ return ret_val;
+ }
+
ret_val = curr->bridge->driver->insert_memor
Re: [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter.
On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote: > This patch changes the bitwise operations in bitops.h to get > a void pointers as a parameter. Before this patch, a lot of warnings > can be seen. They're gone after it. No, this is a backwards step! These warnings are important for non-arch-specific code: I fought hard to get them made into unsigned longs. But I'm happy for this to be applied as is, then I'll grab the git tree, revert it and fix the warnings... Rusty. -- 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/
[RFC][PATCH 1/4][intel_iommu] explicit export current graphics dmar status
[PATCH] [intel_iommu] explicit export current graphics dmar status
To make it possbile to tell other modules about curent
graphics dmar engine status, that could decide if graphics
driver should remap physical address to dma address.
Also this one trys to make dmar_disabled really present
current status of DMAR, which would be used for completely
express graphics dmar engine is active or not.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/pci/intel-iommu.c | 18 --
include/linux/dmar.h |6 ++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index e079a52..81a0abc 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -53,7 +53,7 @@
static void domain_remove_dev_info(struct dmar_domain *domain);
static int dmar_disabled;
-static int __initdata dmar_map_gfx = 1;
+static int dmar_map_gfx = 1;
static int dmar_forcedac;
#define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
@@ -86,6 +86,16 @@ static int __init intel_iommu_setup(char *str)
}
__setup("intel_iommu=", intel_iommu_setup);
+int intel_iommu_gfx_remapping(void)
+{
+#ifndef CONFIG_DMAR_GFX_WA
+ if (!dmar_disabled && iommu_detected && dmar_map_gfx)
+ return 1;
+#endif
+ return 0;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_gfx_remapping);
+
static struct kmem_cache *iommu_domain_cache;
static struct kmem_cache *iommu_devinfo_cache;
static struct kmem_cache *iommu_iova_cache;
@@ -2189,8 +2199,12 @@ static void __init iommu_exit_mempool(void)
void __init detect_intel_iommu(void)
{
- if (swiotlb || no_iommu || iommu_detected || dmar_disabled)
+ if (dmar_disabled)
+ return;
+ if (swiotlb || no_iommu || iommu_detected) {
+ dmar_disabled = 1;
return;
+ }
if (early_dmar_detect()) {
iommu_detected = 1;
}
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index ffb6439..8ae435e 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -47,6 +47,8 @@ extern int intel_iommu_init(void);
extern int dmar_table_init(void);
extern int early_dmar_detect(void);
+extern int intel_iommu_gfx_remapping(void);
+
extern struct list_head dmar_drhd_units;
extern struct list_head dmar_rmrr_units;
@@ -81,6 +83,10 @@ static inline int intel_iommu_init(void)
{
return -ENODEV;
}
+static inline int intel_iommu_gfx_remapping(void)
+{
+ return 0;
+}
#endif /* !CONFIG_DMAR */
#endif /* __DMAR_H__ */
--
1.5.3.5
--
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/
Re: [PATCH 3/21] [PATCH] move desc_empty to where they belong
On Tuesday 18 December 2007 09:52:26 Glauber de Oliveira Costa wrote:
> +static inline int desc_empty(const void *ptr)
> +{
> + const u32 *desc = ptr;
> + return !(desc[0] | desc[1]);
> +}
Erk. This really needs to be a union, not a void *. I guess we can clean it
later.
Rusty.
--
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/
[RFC][PATCH 0/4] enabling graphics memory dma remapping
Intel IOMMU (a.k.a VT-d) is under rapid deployment on desktop and mobile platforms. As platform provides multiple dma remap engines for devices like those lives on south bridge (net, sound, etc.), and we also have one engine specific to graphics device. If this engine is functioning, the access to graphics memory routine is to first look up in GART table, which return virtual dma address that will further be route to graphics DMAR engine, which then looking up DMAR table to get real physical address. Current intel iommu function in kernel is providing a graphics workaround kernel config (CONFIG_DMAR_GFX_WA) to make a 1:1 mapping initialization for graphics device, so what we fill in GART table got from agpgart page alloc is identical to virtual dma address in DMAR table. No change needs to be made for graphics driver. Following patches try to add dma remapping function to agpgart module, so we won't depend on intel iommu graphics workaround. As DMAR is only available on x86_64 now, so these patches can only work for x86_64 system. Here're three patches below: - intel_iommu-explicit-export-current-graphics-dmar-status.patch This exports current status of graphics dma remap engine, which depends on current platform iommu support, kernel config or runtime config. This info will be used in agp module for detect whether we should do remapping or not. - AGP-Add-generic-support-for-graphics-dma-remapping.patch This adds new hooks into agp bridge driver to do map/unmap when bind/unbind memory into GART table. The aim is to provide generic interfaces to let driver implement hardware specific operations. - AGP-intel_agp-add-support-for-graphics-dma-remapping.patch This implements graphics dma remapping support in intel_agp module, current only desktop chipset G33 series can use it. Thanks. -- 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/
RE: /dev/urandom uses uninit bytes, leaks user data
> Has anyone *proven* that using uninitialized data this way is safe? You can probably find dozens of things in the Linux kernel that have not been proven to be safe. That means nothing. > As > a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I > hear things like this. (Hint: most protocols are considered insecure > until proven otherwise, not the other way around.) There's no reason whatsoever to think this is unsafe. First, you can't access the pool directly. Second, even if you could, it's mixed in securely. > Now imagine a security program. It runs some forward secret protocol > and it's very safe not to leak data that would break forward secrecy > (mlockall, memset when done with stuff, etc). It runs on a freshly > booted machine (no DSA involved, so we're not automatically hosed), so > an attacker knows the initial pool state. Conveniently, some *secret* > (say an ephemeral key, or, worse, a password) gets mixed in to the pool. > There are apparently at most three bytes of extra data mixed in, but > suppose the attacker knows add the words that were supposed to get mixed > in. Now the program clears all its state to "ensure" forward secrecy, > and *then* the machine gets hacked. Now the attacker can learn (with at > most 2^24 guesses worth of computation) 24 bits worth of a secret, which > could quite easily reduce the work involved in breaking whatever forward > secret protocol was involved from intractable to somewhat easy. Or it > could leak three bytes of password. Or whatever. This is no more precise than "imagine there's some vulnerability in the RNG". Yes, if there's a vulnerability, then we're vulnerable. An attacker can always (at least in principle) get the pool out of the kernel. The RNG's design is premised on the notion that it is computationally infeasbile to get the input entropy out of the pool. If an attacker can watch data going into the pool, he needn't get it out of the pool. > Sorry for the somewhat inflammatory email, but this is absurd. I agree. DS -- 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/
Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl
Eric W. Biederman wrote: _00FD_FC00_h - _00FD_FDFF_h On a hypertransport based system should work. There is a 32MB window for it. It doesn't. The termination on MMIO and IOIO transaction is different, and poking this memory window with an MMIO transaction will lock the chipset hard (yes, I've tried it.) -hpa -- 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/
Re: [RFC] [patch 1/2] add non_init_kernel_text_address
On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote: > On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote: > > regular_kernel_text_address()? Dunno. > > Sounds better :-) The better answer was to invert it and use "discarded_kernel_text_address()", which is what you actually care about (rather than the details of whether it was init or not). However, you have, in fact, located a potential bug. If someone were to kmalloc module text, then symbol_put() could fail. How's this? --- Don't report discarded init pages as kernel text. In theory this could cause a bug in symbol_put() if an arch used for a module: we might think the symbol belongs to the core kernel. The downside is that this might make backtraces through (discarded) init functions harder to read on some archs. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> diff -r 0eabf082c13a kernel/extable.c --- a/kernel/extable.c Tue Dec 18 13:51:13 2007 +1100 +++ b/kernel/extable.c Tue Dec 18 15:53:01 2007 +1100 @@ -46,7 +46,8 @@ int core_kernel_text(unsigned long addr) addr <= (unsigned long)_etext) return 1; - if (addr >= (unsigned long)_sinittext && + if (system_state == SYSTEM_BOOTING && + addr >= (unsigned long)_sinittext && addr <= (unsigned long)_einittext) return 1; return 0; -- 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/
Re: [RFC PATCH 02/12] PAT 64b: Basic PAT implementation
Venki Pallipadi <[EMAIL PROTECTED]> writes: > Checking the manual for this. You are right, we had missed some steps here. > Actually, manual says on MP, PAT MSR on all CPUs must be consistent (even when > they are not really using it in their page tables. > So, this will change the init and shutdown parts significantly and there may > be > some challenges with CPU offline and KEXEC. We will redo this part in next > iteration. Well the normal kexec path is no worse then reboot. The kdump path is a mess but only a minor one, and with us only changing the UC- case we can probably just ignore it and leave the system started with that pat register set to WC :) What we are doing really should be no worse the MTRR setup except that disabling it at reboot is polite. CPU online and offline that is weird, but so far it is always weird, and I don't think ever quite correct. Eric -- 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/
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, 2007-12-17 at 20:28 -0800, Andrew Morton wrote: > Please: just replace all instances with plain old "Adam Fritzler" and then > ensure that the lookup key "Adam Fritzler" has an accurate (and > non-duplicated anywhere else!) entry in MAINTAINERS or CREDITS or whatever. Sure. See new patch below > btw, I cheerfully skipped all your spelling-fixes patches. No worries. I was just avoiding doing useful stuff. > Some will have > stuck via subsystem maintainers but I have a secret "no spelling fixes > unless they're end-user-visible" policy. I think there were 15-20 printks in that lot. Do you want them separately? > I'd suggest that you find out if Adrian is still running the trivial tree > and if so, patchbomb him. OK. Adrian? Do you want the spelling fixes? Back to Adam Fritzler... Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- CREDITS |3 +++ MAINTAINERS |7 --- drivers/net/eexpress.c |2 +- drivers/net/tokenring/abyss.c|2 +- drivers/net/tokenring/abyss.h|2 +- drivers/net/tokenring/madgemc.c |2 +- drivers/net/tokenring/madgemc.h |2 +- drivers/net/tokenring/proteon.c |2 +- drivers/net/tokenring/skisa.c|2 +- drivers/net/tokenring/tms380tr.c |2 +- drivers/net/tokenring/tms380tr.h |2 +- drivers/net/tokenring/tmspci.c |2 +- drivers/scsi/aha1542.c |2 +- 13 files changed, 14 insertions(+), 18 deletions(-) diff --git a/CREDITS b/CREDITS index ee909f2..449ec7f 100644 --- a/CREDITS +++ b/CREDITS @@ -1124,6 +1124,9 @@ S: 1150 Ringwood Court S: San Jose, California 95131 S: USA +N: Adam Fritzler +E: [EMAIL PROTECTED] + N: Fernando Fuganti E: [EMAIL PROTECTED] E: [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 9507b42..690f172 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3758,13 +3758,6 @@ W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/ T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git S: Maintained -TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -W: http://www.auk.cx/tms380tr/ -S: Maintained - TULIP NETWORK DRIVER L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/tulip/ diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c index 70509ed..283fc8f 100644 --- a/drivers/net/eexpress.c +++ b/drivers/net/eexpress.c @@ -9,7 +9,7 @@ * Many modifications, and currently maintained, by * Philip Blundell <[EMAIL PROTECTED]> * Added the Compaq LTE Alan Cox <[EMAIL PROTECTED]> - * Added MCA support Adam Fritzler <[EMAIL PROTECTED]> + * Added MCA support Adam Fritzler * * Note - this driver is experimental still - it has problems on faster * machines. Someone needs to sit down and go through it line by line with diff --git a/drivers/net/tokenring/abyss.c b/drivers/net/tokenring/abyss.c index 124cfd4..7a7de04 100644 --- a/drivers/net/tokenring/abyss.c +++ b/drivers/net/tokenring/abyss.c @@ -10,7 +10,7 @@ * - Madge Smart 16/4 PCI Mk2 * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler * * Modification History: * 30-Dec-99 AF Split off from the tms380tr driver. diff --git a/drivers/net/tokenring/abyss.h b/drivers/net/tokenring/abyss.h index 0ee6e4f..b0a473b 100644 --- a/drivers/net/tokenring/abyss.h +++ b/drivers/net/tokenring/abyss.h @@ -2,7 +2,7 @@ * abyss.h: Header for the abyss tms380tr module * * Authors: - * - Adam Fritzler <[EMAIL PROTECTED]> + * - Adam Fritzler */ #ifndef __LINUX_MADGETR_H diff --git a/drivers/net/tokenring/madgemc.c b/drivers/net/tokenring/madgemc.c index 5a41513..c9c5a2b 100644 --- a/drivers/net/tokenring/madgemc.c +++ b/drivers/net/tokenring/madgemc.c @@ -11,7 +11,7 @@ * - Madge Smart 16/4 Ringnode MC32 (??) * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler * * Modification History: * 16-Jan-00 AF Created diff --git a/drivers/net/tokenring/madgemc.h b/drivers/net/tokenring/madgemc.h index 2dd8222..fe88e27 100644 --- a/drivers/net/tokenring/madgemc.h +++ b/drivers/net/tokenring/madgemc.h @@ -2,7 +2,7 @@ * madgemc.h: Header for the madgemc tms380tr module * * Authors: - * - Adam Fritzler <[EMAIL PROTECTED]> + * - Adam Fritzler */ #ifndef __LINUX_MADGEMC_H diff --git a/drivers/net/tokenring/proteon.c b/drivers/net/tokenring/proteon.c index ca6b659..00ea945 100644 --- a/drivers/net/tokenring/proteon.c +++ b/drivers/net/tokenring/proteon.c @@ -12,7 +12,7 @@ * - Proteon 1392, 1392+ * * Maintainer(s): - *AFAdam Fritzler [EMAIL PROTECTED] + *AFAdam Fritzler *JF Jochen Friedrich[EMAIL PROTECTED] * * Modification History: diff --git a/drivers/net/tokenring/skisa.c b/drivers/net/tokenring/skisa.c index 32e8d5a..
xfs mknod regression
I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how long it's been there with an xfs filesystem pbuilder has an issue using device files it makes for chroot the mknod command looks to work fine the file is created however when attempting to use one of the created files you see something like the below ghoststar dev # echo "hi" > null bash: null: No such device or address ghoststar dev # ls -l null crw-rw-rw- 1 root root 1, 3 2007-12-17 20:34 null ghoststar dev # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 2007-10-05 17:29 /dev/null ghoststar dev # echo "hi" > /dev/null ghoststar dev # I have not done any bisecting yet if needed I can narrow it down the minor work around I found was to just mount an ext3 filesystem where pbuilder builds -- 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/
Re: [RFC PATCH 02/12] PAT 64b: Basic PAT implementation
Andi Kleen <[EMAIL PROTECTED]> writes: >> I do know we need to use the low 4 pat mappings to avoid most of the PAT >> errata issues. > > They don't really matter. These are all very old systems who have run > fine for many years without PAT. It is no problem to let them > continue to do so and just disable PAT for them. So just clear pat bit in > CPU initialization for any CPUs with non trivial erratas in this > area. > > PAT is only really needed on modern boxes. > > Just someone needs to go through the old errata sheets and find > out on which CPUs it is needed to clear the bit. It has been ages now, but my impression when I wrote the patch that current cores still had a few outstanding errata with using the extended pat bits. Further it was my impression was that if we just changed UC- to WC we work on essentially everything, because PAT is always enabled on the cores that support it. Therefore since we only have 3 interesting caching modes. WB, WC, UC. We should be very careful about reprogramming it and we can ignore the errors. As for the pat class errata about inconsistent mappings those are reoccurring issues, that happen across all cpu types (x86/ppc/fred), and every major core overhaul is likely to have them again. Eric -- 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/
Re: [PATCH -mm -v3] x86 boot : export boot_params via sysfs
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > This is directly analogous to how we treat identity information in IDE, or PCI > configuration space -- some fields are pre-digested, but the entire raw > information is also available. Add to that a totally unchanged value can just be easier to get correct. Still the kexec code as much as it can should not look there, as we may get the same basic information in a couple of different ways. EFI memmap vs. e820 for example. If/when that is the case /sbin/kexec should get the information and spit it out into whatever format makes sense for the destination kernel. My sense is just passing through values is brittleness where we don't want it. However I think being able to get at the raw boot information overall sounds useful. I just don't know if it is generally useful or just useful when debugging bootloaders though. Eric -- 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/
Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl
Andi Kleen <[EMAIL PROTECTED]> writes: > On Mon, Dec 17, 2007 at 08:57:50AM +1100, Paul Mackerras wrote: >> Greg KH writes: >> >> > Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs >> > devices that are mmaped, that makes a bit more sense. >> > >> > But I'd like to see what ioctl is wanted here first. >> >> I believe the ioctl would be to set whether the mapping goes to I/O or >> memory space, > > x86 cannot really access IO space through mmap so no that wasn't planned _00FD_FC00_h - _00FD_FDFF_h On a hypertransport based system should work. There is a 32MB window for it. However the I/O vs mem distinction doesn't matter anyway if we start out per bar because we already know if it is I/O or mem. > The main planned use was to get the translated bus address (after IOMMU) > for a mapping and to set the caching modes. > >> So the alternative to the ioctl would be to have multiple files in >> sysfs, one per combination of modes -- i.e., 4 files, or 3 if we >> exclude the "I/O with write combining" mode, which would be >> reasonable. > > At least for the IOMMU translation case that wouldn't work. Well the other alternative looks like having a second file per par bar. Say resource0_wc to support the write-combining mode, possibly restricted to just prefetchable bars. If that is all we have to worry about my inclination is to suggest a second file, because that feels a bit more generally useable. As that attribute could be applied to ordinary reads and writes to and from the bar. Eric -- 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/
Re: [PATCH] apm_event{,info}_t are userspace types.
On Saturday 01 December 2007 07:02:43 Adam Jackson wrote: > These types define the size of data read from /dev/apm_bios. They > should not be hidden behind #ifdef __KERNEL__. Acked-by: Rusty Russell <[EMAIL PROTECTED]> My mistake, sorry. Rusty. -- 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/
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, 17 Dec 2007 20:12:06 -0800 Joe Perches <[EMAIL PROTECTED]> wrote: > Adam isn't a maintainer anymore. > His old email address bounces. > Update to new email address. > > On Mon, Dec 17, 2007 at 01:03:48PM -0800, Joe Perches wrote: > > > You seem to have an old email address in the > > > linux-kernel MAINTAINERS file. > > > Should it be deleted or changed? > On Mon, 2007-12-17 at 19:27 -0800, Adam Fritzler wrote: > > I am no longer actively involved. If you can mark me as a former point > > of contact, that's fine, or you can just delete the entry. My name is > > still in the source, but with the old address. It'd great if the > > address in source was updated. > > ... > > -TMS380 TOKEN-RING NETWORK DRIVER > -P: Adam Fritzler > -M: [EMAIL PROTECTED] > -L: [EMAIL PROTECTED] > -W: http://www.auk.cx/tms380tr/ > -S: Maintained > > ... > > - * Added MCA support Adam Fritzler <[EMAIL PROTECTED]> > + * Added MCA support Adam Fritzler <[EMAIL PROTECTED]> This is fairly pointless - it'll just break again when Adam moves again. Every problem can be solved with another layer of... Please: just replace all instances with plain old "Adam Fritzler" and then ensure that the lookup key "Adam Fritzler" has an accurate (and non-duplicated anywhere else!) entry in MAINTAINERS or CREDITS or whatever. btw, I cheerfully skipped all your spelling-fixes patches. Some will have stuck via subsystem maintainers but I have a secret "no spelling fixes unless they're end-user-visible" policy. That means I'll take spelling fixes only if they're in printks or in Documentation/*. This is a little defense mechanism to avoid getting buried in micropatches. I'd suggest that you find out if Adrian is still running the trivial tree and if so, patchbomb him. -- 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/
Re: /dev/urandom uses uninit bytes, leaks user data
On Tue, Dec 18, 2007 at 02:39:00PM +1030, David Newall wrote: > > Thus, the entropy saved at shutdown can be known at boot-time. (You can > examine the saved entropy on disk.) > If you can examine the saved entropy on disk, you can also introduce a trojan horse kernel that logs all keystrokes and all generated entropy to the FBI carnivore server --- you can replace the gpg binary with one which ships copies of the session keys to the CIA --- and you can replace the freeswan server with one which generates emphermal keys by encrypting the current timestamp with a key known only by the NSA. So if the attacker has access to your disk between shutdown and boot up, you are *done*. /dev/random is the least of your worries. Really, why is it that people are so enamored about proposing these totally bogus scenarios? Yes, if you have direct physical access to your machine, you can compromise it. But there are far easier ways that such a vulnerability can be exploited, rather than making it easy to carry out an cryptoanalytic attack on /dev/random. (And yes, after using the saved state to load the entropy at boot-time, the saved state file is overwritten, and if you're paranoid, you can scrub the disk after it is read and mixed into the entropy pool. And yes, the saved state is *not* the entropy pool used during the previous boot, but entropy extracted using SHA-1 based CRNG.) >> If you have a server, the best thing you can do is use a hardware >> random number generator, if it exists. Fortunately a number of >> hardware platforms, such as IBM blades and Thinkpads, come with TPM >> modules that include hardware RNG's. That's ultimately the best way >> to solve these issues. > > Just how random are they? Do they turn out to be quite predictable if > you're IBM? They use a noise diode, so they are as good as any other hardware random number generator. Of course, you ultimately have to trust the supplier of your hardware not to do something screwy, and Thinkpads are now made by Lenovo, which has caused some US Government types to get paranoid --- but that's why the best way to do things is to get entropy from as many places as possible, and mix it all into /dev/random. If any one of them is unknown to the attacker, he's stuck. And if you are sufficiently paranoid, you obviously can't use commodity hardware, and how do you know that some time along time ago, someone snuck in a evil secret code into the C compiler that was designed to survive a bootstrap process[1]? And how do you know that your keyboard controller hasn't been gimmicked to record your key strokes and then send them out by adding jitter that can be read by an attacker looking at the timing of your ssh packets[2]? But seriously, if you are that paranoid, better build your hardware from scratch, and then hand assemble your compiler, and then do a line-by-line audit of all of your source code. It's going to be the only way to be sure - Ted [1] Ken Thompson, Reflections on Trusting Trust. http://cm.bell-labs.com/who/ken/trust.html [2] Gaurav Shah, Andres Molina and Matt Blaze, Keyboards and Covert Channels. http://www.usenix.org/events/sec06/tech/shah/shah_html/index.html -- 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/
[PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
Adam isn't a maintainer anymore. His old email address bounces. Update to new email address. On Mon, Dec 17, 2007 at 01:03:48PM -0800, Joe Perches wrote: > > You seem to have an old email address in the > > linux-kernel MAINTAINERS file. > > Should it be deleted or changed? On Mon, 2007-12-17 at 19:27 -0800, Adam Fritzler wrote: > I am no longer actively involved. If you can mark me as a former point > of contact, that's fine, or you can just delete the entry. My name is > still in the source, but with the old address. It'd great if the > address in source was updated. Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- MAINTAINERS |7 --- drivers/net/eexpress.c |2 +- drivers/net/tokenring/abyss.c|2 +- drivers/net/tokenring/abyss.h|2 +- drivers/net/tokenring/madgemc.c |2 +- drivers/net/tokenring/madgemc.h |2 +- drivers/net/tokenring/proteon.c |2 +- drivers/net/tokenring/skisa.c|2 +- drivers/net/tokenring/tms380tr.c |2 +- drivers/net/tokenring/tms380tr.h |2 +- drivers/net/tokenring/tmspci.c |2 +- drivers/scsi/aha1542.c |2 +- 12 files changed, 11 insertions(+), 18 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9507b42..690f172 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3758,13 +3758,6 @@ W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/ T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git S: Maintained -TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -W: http://www.auk.cx/tms380tr/ -S: Maintained - TULIP NETWORK DRIVER L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/tulip/ diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c index 70509ed..46c3c99 100644 --- a/drivers/net/eexpress.c +++ b/drivers/net/eexpress.c @@ -9,7 +9,7 @@ * Many modifications, and currently maintained, by * Philip Blundell <[EMAIL PROTECTED]> * Added the Compaq LTE Alan Cox <[EMAIL PROTECTED]> - * Added MCA support Adam Fritzler <[EMAIL PROTECTED]> + * Added MCA support Adam Fritzler <[EMAIL PROTECTED]> * * Note - this driver is experimental still - it has problems on faster * machines. Someone needs to sit down and go through it line by line with diff --git a/drivers/net/tokenring/abyss.c b/drivers/net/tokenring/abyss.c index 124cfd4..be60792 100644 --- a/drivers/net/tokenring/abyss.c +++ b/drivers/net/tokenring/abyss.c @@ -10,7 +10,7 @@ * - Madge Smart 16/4 PCI Mk2 * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler [EMAIL PROTECTED] * * Modification History: * 30-Dec-99 AF Split off from the tms380tr driver. diff --git a/drivers/net/tokenring/abyss.h b/drivers/net/tokenring/abyss.h index 0ee6e4f..93376e1 100644 --- a/drivers/net/tokenring/abyss.h +++ b/drivers/net/tokenring/abyss.h @@ -2,7 +2,7 @@ * abyss.h: Header for the abyss tms380tr module * * Authors: - * - Adam Fritzler <[EMAIL PROTECTED]> + * - Adam Fritzler <[EMAIL PROTECTED]> */ #ifndef __LINUX_MADGETR_H diff --git a/drivers/net/tokenring/madgemc.c b/drivers/net/tokenring/madgemc.c index 5a41513..b7c819f 100644 --- a/drivers/net/tokenring/madgemc.c +++ b/drivers/net/tokenring/madgemc.c @@ -11,7 +11,7 @@ * - Madge Smart 16/4 Ringnode MC32 (??) * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler [EMAIL PROTECTED] * * Modification History: * 16-Jan-00 AF Created diff --git a/drivers/net/tokenring/madgemc.h b/drivers/net/tokenring/madgemc.h index 2dd8222..b368e59 100644 --- a/drivers/net/tokenring/madgemc.h +++ b/drivers/net/tokenring/madgemc.h @@ -2,7 +2,7 @@ * madgemc.h: Header for the madgemc tms380tr module * * Authors: - * - Adam Fritzler <[EMAIL PROTECTED]> + * - Adam Fritzler <[EMAIL PROTECTED]> */ #ifndef __LINUX_MADGEMC_H diff --git a/drivers/net/tokenring/proteon.c b/drivers/net/tokenring/proteon.c index ca6b659..8fece14 100644 --- a/drivers/net/tokenring/proteon.c +++ b/drivers/net/tokenring/proteon.c @@ -12,7 +12,7 @@ * - Proteon 1392, 1392+ * * Maintainer(s): - *AFAdam Fritzler [EMAIL PROTECTED] + *AFAdam Fritzler [EMAIL PROTECTED] *JF Jochen Friedrich[EMAIL PROTECTED] * * Modification History: diff --git a/drivers/net/tokenring/skisa.c b/drivers/net/tokenring/skisa.c index 32e8d5a..74eae3c 100644 --- a/drivers/net/tokenring/skisa.c +++ b/drivers/net/tokenring/skisa.c @@ -13,7 +13,7 @@ * - SysKonnect TR4/16(+) ISA (SK-4190) * * Maintainer(s): - *AFAdam Fritzler [EMAIL PROTECTED] + *AFAdam Fritzler [EMAIL PROTECTED] *JF Jochen Friedrich[EMAIL PROTECTED] * * Modification History: diff --git a/drivers/net/toke
Re: /dev/urandom uses uninit bytes, leaks user data
Theodore Tso wrote: On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote: On a server, keyboard and mouse are rarely used. As you've described it, that leaves only the disk, and during the boot process, disk accesses and timing are somewhat predictable. Whether this is sufficient to break the RNG is (clearly) a matter of debate. In normal operaiton, entropy is accumlated on the system, extracted via /dev/urandom at shutdown, and then loaded back into the system when it boots up. Thus, the entropy saved at shutdown can be known at boot-time. (You can examine the saved entropy on disk.) If you have a server, the best thing you can do is use a hardware random number generator, if it exists. Fortunately a number of hardware platforms, such as IBM blades and Thinkpads, come with TPM modules that include hardware RNG's. That's ultimately the best way to solve these issues. Just how random are they? Do they turn out to be quite predictable if you're IBM? -- 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/
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Please apply the attached patch and try to use cdrom w/o specifying any
parameter and report kernel log.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4753a18..acaa8b8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4537,6 +4537,10 @@ static void ata_fill_sg(struct ata_queued_cmd *qc)
* Note h/w doesn't support 64-bit, so we unconditionally
* truncate dma_addr_t to u32.
*/
+ if (sg_dma_address(sg) & ~DMA_BIT_MASK(32))
+ ata_dev_printk(qc->dev, KERN_WARNING,
+ "XXX DMA address %llx is above 32bit\n",
+ sg_dma_address(sg));
addr = (u32) sg_dma_address(sg);
sg_len = sg_dma_len(sg);
@@ -6628,6 +6632,10 @@ int ata_port_start(struct ata_port *ap)
if (rc)
return rc;
+ ata_port_printk(ap, KERN_INFO, "XXX: prd %p/%llx pad %p/%llx\n",
+ ap->prd, (unsigned long long)ap->prd_dma,
+ ap->pad, (unsigned long long)ap->pad_dma);
+
DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd,
(unsigned long long)ap->prd_dma);
return 0;
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index ed5dc7c..c55d2ae 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -247,6 +247,7 @@ struct nv_adma_port_priv {
void __iomem*ctl_block;
void __iomem*gen_block;
void __iomem*notifier_clear_block;
+ u64 adma_dma_mask;
u8 flags;
int last_issue_ncq;
};
@@ -748,7 +749,7 @@ static int nv_adma_slave_config(struct scsi_device *sdev)
adma_enable = 0;
nv_adma_register_mode(ap);
} else {
- bounce_limit = *ap->dev->dma_mask;
+ bounce_limit = pp->adma_dma_mask;
segment_boundary = NV_ADMA_DMA_BOUNDARY;
sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN;
adma_enable = 1;
@@ -1134,10 +1135,20 @@ static int nv_adma_port_start(struct ata_port *ap)
void *mem;
dma_addr_t mem_dma;
void __iomem *mmio;
+ struct pci_dev *pdev = to_pci_dev(dev);
u16 tmp;
VPRINTK("ENTER\n");
+ /* Ensure DMA mask is set to 32-bit before allocating legacy PRD and
+ pad buffers */
+ rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ if (rc)
+ return rc;
+ rc = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
+ if (rc)
+ return rc;
+
rc = ata_port_start(ap);
if (rc)
return rc;
@@ -1153,6 +1164,15 @@ static int nv_adma_port_start(struct ata_port *ap)
pp->notifier_clear_block = pp->gen_block +
NV_ADMA_NOTIFIER_CLEAR + (4 * ap->port_no);
+ /* Now that the legacy PRD and padding buffer are allocated we can
+ safely raise the DMA mask to allocate the CPB/APRD table.
+ These are allowed to fail since we store the value that ends up
+ being used to set as the bounce limit in slave_config later if
+ needed. */
+ pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+ pp->adma_dma_mask = *dev->dma_mask;
+
mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
&mem_dma, GFP_KERNEL);
if (!mem)
@@ -2418,12 +2438,6 @@ static int nv_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
hpriv->type = type;
host->private_data = hpriv;
- /* set 64bit dma masks, may fail */
- if (type == ADMA) {
- if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
- pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
- }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1 << NV_MMIO_BAR, DRV_NAME);
if (rc)
diff --git a/include/linux/libata.h b/include/linux/libata.h
Re: /dev/urandom uses uninit bytes, leaks user data
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote: > On a server, keyboard and mouse are rarely used. As you've described it, > that leaves only the disk, and during the boot process, disk accesses and > timing are somewhat predictable. Whether this is sufficient to break the > RNG is (clearly) a matter of debate. In normal operaiton, entropy is accumlated on the system, extracted via /dev/urandom at shutdown, and then loaded back into the system when it boots up. So this will help in everything but the freshly installed system case (and in that case things will get better as the system has a chance to operate). If you have a system with insufficent entropy inputs, you're in trouble, of course. There are "catastrophic reseeds" that attempt to mitigrate some of worse attacks, but at the end of the day, /dev/random isn't magic. In any case, the problem if you have insufficent entropy is not esoteric attacks that presume an attacker can break into the system and read out kernel memory. The problem will be /dev/random's entropy output. And there are techniques that cryptographic applications can do to help. For example, if it is about to encrypt data, it can SHA-1 hash data that it is about to be sent out encrypted, and feed the SHA-1 hash into /dev/random. This won't increase entropy credit counter, but if the attacker doesn't have access to the unecrypted plaintext, mixing in the SHA-1 hash into /dev/random can only help. If you have a server, the best thing you can do is use a hardware random number generator, if it exists. Fortunately a number of hardware platforms, such as IBM blades and Thinkpads, come with TPM modules that include hardware RNG's. That's ultimately the best way to solve these issues. - Ted -- 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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. Serge E. Hallyn wrote: > Nope, try > > touch /root/hda1 > ls -l /root/hda1 > mount --bind /dev/hda1 /root/hda1 > ls -l /root/hda1 [EMAIL PROTECTED] ~]# touch /root/hda1 [EMAIL PROTECTED] ~]# ls -l /root/hda1 -rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1 [EMAIL PROTECTED] ~]# mount --bind /dev/hda1 /root/hda1 [EMAIL PROTECTED] ~]# ls -l /root/hda1 brw-r- 1 root disk 3, 1 Dec 18 2007 /root/hda1 Oh, surprising. I didn't know mount() accepts non-directory for mount-point. But I think this is not a mount operation because I can't see the contents of /dev/hda1 through /root/hda1 . Can I see the contents of /dev/hda1 through /root/hda1 ? > Then it sounds like this filesystem is something Tomoyo can use. I had / partition mounted for read-only so that the admin can't do 'mknod /root/hda1 b 3 1' in 2003, and I named it "Security Advancement Know-how Upon Readonly Approach for Linux" or SAKURA Linux. This filesystem (SYAORAN) is developed to make /dev writable and tamper-proof when / partition is read-only or protected by MAC. TOMOYO is a pathname-based MAC implementation, and SAKURA and SYAORAN were merged into TOMOYO Linux. ;-) Regards. -- 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/
[PATCH 3/7] Modify several rtc drivers to use the alias names list property of i2c
This patch modifies the ds1307, ds1374, and rs5c372 i2c drivers to support
device tree names using the new i2c mod alias support
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 44
drivers/rtc/rtc-ds1307.c | 20 +-
drivers/rtc/rtc-ds1374.c |9 ++
drivers/rtc/rtc-m41t80.c | 57 -
drivers/rtc/rtc-rs5c372.c | 16 ++--
5 files changed, 85 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..268638a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,48 +320,12 @@ arch_initcall(gfar_of_init);
#ifdef CONFIG_I2C_BOARDINFO
#include
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
- {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
- {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
- {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
- {"dallas,ds1307", "rtc-ds1307", "ds1307",},
- {"dallas,ds1337", "rtc-ds1307", "ds1337",},
- {"dallas,ds1338", "rtc-ds1307", "ds1338",},
- {"dallas,ds1339", "rtc-ds1307", "ds1339",},
- {"dallas,ds1340", "rtc-ds1307", "ds1340",},
- {"stm,m41t00", "rtc-ds1307", "m41t00"},
- {"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
-struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
- strlcpy(info->type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) >= I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
static void __init of_register_i2c_devices(struct device_node *adap_node,
int bus_num)
{
struct device_node *node = NULL;
+ const char *compatible;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info = {};
@@ -378,8 +342,12 @@ static void __init of_register_i2c_devices(struct
device_node *adap_node,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, &info) < 0)
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing
compatible attribute\n");
continue;
+ }
+ strncpy(info.driver_name, compatible, sizeof(info.driver_name));
info.addr = *addr;
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index bc1c7fe..d4874ff 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -139,6 +139,17 @@ static inline const struct chip_desc *find_chip(const char
*s)
return NULL;
}
+static struct i2c_device_id ds1307_id[] = {
+ OF_I2C_ID("dallas,ds1307", ds_1307)
+ OF_I2C_ID("dallas,ds1337", ds_1337)
+ OF_I2C_ID("dallas,ds1338", ds_1338)
+ OF_I2C_ID("dallas,ds1339", ds_1339)
+ OF_I2C_ID("dallas,ds1340", ds_1340)
+ OF_I2C_ID("stm,m41t00", m41t00)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ds1307_id);
+
static int ds1307_get_time(struct device *dev, struct rtc_time *t)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
@@ -326,7 +337,7 @@ static struct bin_attribute nvram = {
static struct i2c_driver ds1307_driver;
-static int __devinit ds1307_probe(struct i2c_client *client)
+static int __devinit ds1307_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct ds1307 *ds1307;
int err = -ENODEV;
@@ -334,7 +345,11 @@ static int __devinit ds1307_probe(struct i2c_client
*client)
const struct chip_desc *chip;
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
- chip = find_chip(client->name);
+ if (id)
+ chip = &chips[id->driver_data];
+ else
+ chip = find_chip(client->name);
+
if (!chip) {
dev_err(&client->dev, "unknown chip type '%s'\n",
client->name);
@@ -537,6 +552,7 @@ static struct i2c_driver ds1307_driver = {
},
[PATCH 6/7] Convert pfc8563 i2c driver from old style to new style
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/rtc/rtc-pcf8563.c | 107 +++--
1 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..e1ea2a0 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST10x00 /* status */
#define PCF8563_REG_ST20x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,52 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ OF_I2C_ID("philips,pcf8563", 0)
+ OF_I2C_ID("epson,rtc8564", 0)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
--
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
Re: [PATCH] sched: dynamically update the root-domain span/online maps
Gregory Haskins wrote: Hi Steven, I posted a suspend-to-ram fix to sched-devel earlier today: http://lkml.org/lkml/2007/12/17/445 This fix should also be applied to -rt as I introduced the same regression there. Here is a version of the fix for 23-rt13. I can submit a version for 24-rc5-rt1 at your request. Thanks Gregory, I'll put this into the 2.6.23.11-rt14 queue. I have someone that tells me that suspend to RAM breaks. I'll have him try the new update and let me know if it fixes his issue before releasing it. I'll also let everyone know the results as well. -- Steve -- 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/
Re: "ip neigh show" not showing arp cache entries?
Chris Friesen <[EMAIL PROTECTED]> wrote:
>
> However, if I specifically try to print out one of the missing entries,
> it shows up:
>
> [EMAIL PROTECTED]:/root> /tmp/ip neigh show 192.168.24.81
> 192.168.24.81 dev bond2 lladdr 00:01:af:14:e9:8a REACHABLE
What about
ip -4 neigh show
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/
Re: /dev/urandom uses uninit bytes, leaks user data
Theodore Tso wrote: On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote: It runs on a freshly booted machine (no DSA involved, so we're not automatically hosed), so an attacker knows the initial pool state. Not just a freshly booted system. The system has to be a freshly booted, AND freshly installed system. Normally you mix in a random seed at boot time. And during the boot sequence, the block I/O will be mixing randomness into the entropy pool, and as the user logs in, the keyboard and mouse will be mixing more entropy into the pool. So you'll have to assume that all entropy inputs have somehow been disabled as well. On a server, keyboard and mouse are rarely used. As you've described it, that leaves only the disk, and during the boot process, disk accesses and timing are somewhat predictable. Whether this is sufficient to break the RNG is (clearly) a matter of debate. -- 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/
[PATCH] x86: kprobes use stack_addr() macro
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Replacement for the last patch in the kprobes series I just sent.
arch/x86/kernel/kprobes.c | 45 +
1 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 6f52c5e..c9df6fb 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -44,6 +44,20 @@ struct kretprobe_blackpoint kretprobe_blacklist[] = {
};
const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
+/*
+ * "®s->sp" looks wrong, but it's correct for x86_32. x86_32 CPUs
+ * don't save the ss and esp registers if the CPU is already in kernel
+ * mode when it traps. So for kprobes, regs->sp and regs->ss are not
+ * the [nonexistent] saved stack pointer and ss register, but rather
+ * the top 8 bytes of the pre-int3 stack. So ®s->sp happens to
+ * point to the top of the pre-int3 stack.
+ */
+#ifdef CONFIG_X86_32
+# define stack_addr(regs) ((unsigned long *)®s->sp)
+#else
+# define stack_addr(regs) ((unsigned long *)regs->sp)
+#endif
+
#define W(r, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf) \
(((b0##UL << 0x0)|(b1##UL << 0x1)|(b2##UL << 0x2)|(b3##UL << 0x3) | \
(b4##UL << 0x4)|(b5##UL << 0x5)|(b6##UL << 0x6)|(b7##UL << 0x7) | \
@@ -409,11 +423,8 @@ static void __kprobes prepare_singlestep(struct kprobe *p,
struct pt_regs *regs)
void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
struct pt_regs *regs)
{
-#ifdef CONFIG_X86_32
- unsigned long *sara = (unsigned long *)®s->sp;
-#else
- unsigned long *sara = (unsigned long *)regs->sp;
-#endif
+ unsigned long *sara = stack_addr(regs);
+
ri->ret_addr = (kprobe_opcode_t *) *sara;
/* Replace the return addr with trampoline addr */
*sara = (unsigned long) &kretprobe_trampoline;
@@ -751,11 +762,8 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
static void __kprobes resume_execution(struct kprobe *p,
struct pt_regs *regs, struct kprobe_ctlblk *kcb)
{
-#ifdef CONFIG_X86_32
- unsigned long *tos = (unsigned long *)®s->sp;
-#else
- unsigned long *tos = (unsigned long *)regs->sp;
-#endif
+
+ unsigned long *tos = stack_addr(regs);
unsigned long copy_ip = (unsigned long)p->ainsn.insn;
unsigned long orig_ip = (unsigned long)p->addr;
kprobe_opcode_t *insn = p->ainsn.insn;
@@ -984,11 +992,7 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct
pt_regs *regs)
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
kcb->jprobe_saved_regs = *regs;
-#ifdef CONFIG_X86_32
- kcb->jprobe_saved_sp = ®s->sp;
-#else
- kcb->jprobe_saved_sp = (long *) regs->sp;
-#endif
+ kcb->jprobe_saved_sp = (long *)stack_addr(regs);
addr = (unsigned long)(kcb->jprobe_saved_sp);
/*
* As Linus pointed out, gcc assumes that the callee
@@ -1033,17 +1037,10 @@ int __kprobes longjmp_break_handler(struct kprobe *p,
struct pt_regs *regs)
struct jprobe *jp = container_of(p, struct jprobe, kp);
if ((addr > (u8 *) jprobe_return) && (addr < (u8 *) jprobe_return_end))
{
-#ifdef CONFIG_X86_32
- if (®s->sp != kcb->jprobe_saved_sp) {
+ if (stack_addr(regs) != kcb->jprobe_saved_sp) {
struct pt_regs *saved_regs = &kcb->jprobe_saved_sp;
printk("current sp %p does not match saved sp %p\n",
- ®s->sp, kcb->jprobe_saved_sp);
-#else
- if ((long *)regs->sp != kcb->jprobe_saved_sp) {
- struct pt_regs *saved_regs = &kcb->jprobe_saved_sp;
- printk("current sp %p does not match saved sp %p\n",
- (long *)regs->sp, kcb->jprobe_saved_sp);
-#endif
+ stack_addr(regs), kcb->jprobe_saved_sp);
printk("Saved registers for jprobe %p\n", jp);
show_registers(saved_regs);
printk("Current registers\n");
--
1.5.4.rc0.1083.gf568
--
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/
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
On Tue, 18 Dec 2007, Stefan Richter wrote: It's a 100% reproducible oops on Sparc (with FireWire controller) for 2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that the bug also happens How do you achieve a sparc system with firewire ? AFAIK there is no SBUS firewire card. Only sparc64 and some rare javastations have PCI slots. -- 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/
Re: [PATCH 1/2 2.6.25] cxgb3 - parity initialization for T3C adapters.
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Add parity initialization for T3C adapters. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> applied 1-2 to #upstream -- 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/
Re: /dev/urandom uses uninit bytes, leaks user data
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote: > It runs on a freshly booted machine (no > DSA involved, so we're not automatically hosed), so an attacker knows the > initial pool state. Not just a freshly booted system. The system has to be a freshly booted, AND freshly installed system. Normally you mix in a random seed at boot time. And during the boot sequence, the block I/O will be mixing randomness into the entropy pool, and as the user logs in, the keyboard and mouse will be mixing more entropy into the pool. So you'll have to assume that all entropy inputs have somehow been disabled as well. BUT --- if the pool state is totally known, you're really, REALLY, REALLY hosed, since normally /dev/random might get used to initialize a CRNG to *generate* the ephmeral key. So the danger is not *3* *bytes* of the empheral key accidentally getting mixed into the entropy pool, followed by an attacker managing to crack the system so bad that he or she has read access into kernel memory (without managing to mix more entropy into the pool), and then doing sophisticated cryptoanalytic attacks with an O(2**24) order time, to try to leak the *3* *bytes* of emphemeral key. No, the problem is that the attacker, with access to the known initial state of the pool, will be able to find out *THE* *ENTIRE* *EMPHERAL* *KEY*, since it was probably generated via /dev/random --- and without needing to break into the system with sufficient privs to be able to read kernel memory. So it is your argument which is absurd. If you're going to assume a completely known pool state, and then assume some program is using /dev/random, the danger is not in change that some previous kernel stack state might contain something secret that could theoretically be revealed after an attacker manages to break into machine as root. No, the real danger is in what this presumably cryptographically sensitive program did with the predictable data from /dev/random. So the real answer is that there needs to be sufficient randomness mixed into /dev/random. For a typical Linux system, it's there. There are some potential configuration (say a pure diskless system with NFS remote filesystems and no keyboard or mouse) being used in some kind of security-sensitive system. Now, someone who wanted to say, run a remote certificate signing server or IPSEC key management system on such a system would arguably be performing security malpractice, and the lack of entropy for /dev/random is probably the least of such a system's security problems. But in any case, instead of trying to worry about these sorts of hypothetical worries, the much better use of time and energy is the userspace daemon that can sample entropy from a sound device, or some other hardware entropy available to the system. The real issue is being able to make sure the pool is *not* knowable to an attacker. - Ted -- 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/
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Chris Newport <[EMAIL PROTECTED]> Date: Tue, 18 Dec 2007 02:58:29 + (GMT) > On Tue, 18 Dec 2007, Stefan Richter wrote: > > > It's a 100% reproducible oops on Sparc (with FireWire controller) for > > 2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that > > the bug also happens > > How do you achieve a sparc system with firewire ? > AFAIK there is no SBUS firewire card. He means sparc64, which have PCI firewire onboard many systems. -- 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/
[PATCH] sched: dynamically update the root-domain span/online maps
Hi Steven,
I posted a suspend-to-ram fix to sched-devel earlier today:
http://lkml.org/lkml/2007/12/17/445
This fix should also be applied to -rt as I introduced the same regression
there. Here is a version of the fix for 23-rt13. I can submit a version for
24-rc5-rt1 at your request.
Regards,
-Greg
-
The baseline code statically builds the span maps when the domain is formed.
Previous attempts at dynamically updating the maps caused a suspend-to-ram
regression, which should now be fixed.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
CC: Gautham R Shenoy <[EMAIL PROTECTED]>
---
kernel/sched.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 244c4b5..95b8c99 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -281,8 +281,6 @@ struct rt_rq {
* exclusive cpuset is created, we also create and attach a new root-domain
* object.
*
- * By default the system creates a single root-domain with all cpus as
- * members (mimicking the global state we have today).
*/
struct root_domain {
atomic_t refcount;
@@ -300,6 +298,10 @@ struct root_domain {
#endif
};
+/*
+ * By default the system creates a single root-domain with all cpus as
+ * members (mimicking the global state we have today).
+ */
static struct root_domain def_root_domain;
#endif
@@ -6066,6 +6068,10 @@ static void rq_attach_root(struct rq *rq, struct
root_domain *rd)
atomic_inc(&rd->refcount);
rq->rd = rd;
+ cpu_set(rq->cpu, rd->span);
+ if (cpu_isset(rq->cpu, cpu_online_map))
+ cpu_set(rq->cpu, rd->online);
+
for (class = sched_class_highest; class; class = class->next) {
if (class->join_domain)
class->join_domain(rq);
@@ -6074,12 +6080,12 @@ static void rq_attach_root(struct rq *rq, struct
root_domain *rd)
spin_unlock_irqrestore(&rq->lock, flags);
}
-static void init_rootdomain(struct root_domain *rd, const cpumask_t *map)
+static void init_rootdomain(struct root_domain *rd)
{
memset(rd, 0, sizeof(*rd));
- rd->span = *map;
- cpus_and(rd->online, rd->span, cpu_online_map);
+ cpus_clear(rd->span);
+ cpus_clear(rd->online);
cpupri_init(&rd->cpupri);
@@ -6087,13 +6093,11 @@ static void init_rootdomain(struct root_domain *rd,
const cpumask_t *map)
static void init_defrootdomain(void)
{
- cpumask_t cpus = CPU_MASK_ALL;
-
- init_rootdomain(&def_root_domain, &cpus);
+ init_rootdomain(&def_root_domain);
atomic_set(&def_root_domain.refcount, 1);
}
-static struct root_domain *alloc_rootdomain(const cpumask_t *map)
+static struct root_domain *alloc_rootdomain(void)
{
struct root_domain *rd;
@@ -6101,7 +6105,7 @@ static struct root_domain *alloc_rootdomain(const
cpumask_t *map)
if (!rd)
return NULL;
- init_rootdomain(rd, map);
+ init_rootdomain(rd);
return rd;
}
@@ -6523,7 +6527,7 @@ static int build_sched_domains(const cpumask_t *cpu_map)
sched_group_nodes_bycpu[first_cpu(*cpu_map)] = sched_group_nodes;
#endif
- rd = alloc_rootdomain(cpu_map);
+ rd = alloc_rootdomain();
if (!rd) {
printk(KERN_WARNING "Cannot alloc root domain\n");
return -ENOMEM;
@@ -7021,7 +7025,6 @@ void __init sched_init(void)
#ifdef CONFIG_SMP
rq->sd = NULL;
rq->rd = NULL;
- rq_attach_root(rq, &def_root_domain);
rq->active_balance = 0;
rq->next_balance = jiffies;
rq->push_cpu = 0;
@@ -7030,6 +7033,7 @@ void __init sched_init(void)
INIT_LIST_HEAD(&rq->migration_queue);
rq->rt.highest_prio = MAX_RT_PRIO;
rq->rt.overloaded = 0;
+ rq_attach_root(rq, &def_root_domain);
#endif
atomic_set(&rq->nr_iowait, 0);
--
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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Serge E. Hallyn wrote: > Quoting Oren Laadan ([EMAIL PROTECTED]): >> I hate to bring this again, but what if the admin in the container >> mounts an external file system (eg. nfs, usb, loop mount from a file, >> or via fuse), and that file system already has a device that we would >> like to ban inside that container ? > > Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > then mnt->mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. > > But that's been pulled out of -mm! ? Crap. > >> Since anyway we will have to keep a white- (or black-) list of devices >> that are permitted in a container, and that list may change even change >> per container -- why not enforce the access control at the VFS layer ? >> It's safer in the long run. > > By that you mean more along the lines of Pavel's patch than my whitelist > LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that > by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren. > > thanks, > -serge -- 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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > Hello. > > Serge E. Hallyn wrote: > > But your requirements are to ensure that an application accessing a > > device at a well-known location get what it expect. > > Yes. That's the purpose of this filesystem. > > > > So then the main quesiton is still the one I think Al had asked - what > > keeps a rogue CAP_SYS_MOUNT process from doing > > mount --bind /dev/hda1 /dev/null ? > > Excuse me, but I guess you meant "mount --bind /dev/ /root/" or something > because mount operation requires directories. Nope, try touch /root/hda1 ls -l /root/hda1 mount --bind /dev/hda1 /root/hda1 ls -l /root/hda1 But I see tomoyo prevents that > MAC can prevent a rogue CAP_SYS_MOUNT process from doing > "mount --bind /dev/ /root/". > For example, regarding TOMOYO Linux, you need to give > "allow_mount /dev/ /root/ --bind 0" permission > to permit "mount --bind /dev/ /root/" request. Ok, that answers my question. Thanks. (I won't go into "who gets to say allow_mount" :) > Did you mean "ln -s /dev/hda1 /dev/null" or "ln /dev/hda1 /dev/null"? > No problem. MAC can prevent such requests too. Then it sounds like this filesystem is something Tomoyo can use. thanks, -serge -- 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/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Tue, 18 Dec 2007 10:37:32 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> > On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
> >
> > (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> > doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
> > actually does that code?)
> >
> > > > I try it again, and it reports it died at the same exact place, but in
> > > > about
> > > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
> > > > didn't
> > > > think that blocks read from /dev/cdrom would get cached, but OK.
> > >
> > > It'll remain cached if something is holding the device open.
> >
> > Does it need to be "device open", or are there other things as well? If the
> > drop_cache was hosed, that would result in the same symptoms, no?
> >
> > > Something's holding s_umount for writing I guess. Possibly busted error
> > > handling somewhere totally different.
> >
> > Aha - found what was holding it - an attempt to loopback mount the truncated
> > file (before I realized it was truncated) had failed - I had gotten a
> > 'Killed'
> > back from the mount, but I didn't realize it had pulled an actual oops:
> >
> > Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access
> > beyond end of device
> > Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
> > want=1284500, limit=314240
> > Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
> > i-node block
> > Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle
> > kernel NULL pointer dereference at 010b RIP:
> > Dec 17 15:54:33 turing-police kernel: [14503.402440] []
> > iput+0x11/0x80
> > ...
> > Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
> > Dec 17 15:54:33 turing-police kernel: [14503.403026] []
> > isofs_fill_super+0x7e9/0xa6b
> > Dec 17 15:54:33 turing-police kernel: [14503.403045] []
> > __down_write_nested+0x3d/0xa1
> > Dec 17 15:54:33 turing-police kernel: [14503.403061] []
> > __down_write+0xb/0xd
> > Dec 17 15:54:33 turing-police kernel: [14503.403076] []
> > sget+0x397/0x3a9
> > Dec 17 15:54:33 turing-police kernel: [14503.403090] []
> > set_bdev_super+0x0/0x14
> > Dec 17 15:54:33 turing-police kernel: [14503.403106] []
> > get_sb_bdev+0x109/0x157
> > Dec 17 15:54:33 turing-police kernel: [14503.403120] []
> > isofs_fill_super+0x0/0xa6b
> > Dec 17 15:54:33 turing-police kernel: [14503.403138] []
> > isofs_get_sb+0x13/0x15
> > Dec 17 15:54:33 turing-police kernel: [14503.403151] []
> > vfs_kern_mount+0x90/0x11a
> > Dec 17 15:54:33 turing-police kernel: [14503.403167] []
> > do_kern_mount+0x47/0xe3
> > Dec 17 15:54:33 turing-police kernel: [14503.403183] []
> > do_mount+0x717/0x78a
> > Dec 17 15:54:33 turing-police kernel: [14503.403199] []
> > _read_lock_irq+0x9/0xb
> > Dec 17 15:54:33 turing-police kernel: [14503.403212] []
> > find_lock_page+0x8c/0x97
> > Dec 17 15:54:33 turing-police kernel: [14503.403227] []
> > filemap_fault+0x1fa/0x3c6
> > Dec 17 15:54:33 turing-police kernel: [14503.403241] []
> > unlock_page+0x2d/0x31
> > Dec 17 15:54:33 turing-police kernel: [14503.403254] []
> > __do_fault+0x38d/0x3c3
> > Dec 17 15:54:33 turing-police kernel: [14503.403274] []
> > handle_mm_fault+0x36d/0x6e9
> > Dec 17 15:54:33 turing-police kernel: [14503.403293] []
> > __alloc_pages+0x68/0x2f6
> > Dec 17 15:54:33 turing-police kernel: [14503.403314] []
> > sys_mount+0x89/0xcb
> > Dec 17 15:54:33 turing-police kernel: [14503.403328] []
> > syscall_trace_enter+0x97/0x9b
> > Dec 17 15:54:33 turing-police kernel: [14503.403344] []
> > tracesys+0xdc/0xe1
> > Dec 17 15:54:33 turing-police kernel: [14503.403359]
> > Dec 17 15:54:33 turing-police kernel: [14503.403366]
> > Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01
> > 00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
> >
> > I don't mind it failing the mount, but the oops seems excessive. I suspect
> > that *somewhere* in that stack trace, we're wanting something like a
> >
> > if (!foo_ptr)
> > return -EIO;
> >
> > but I admit not being competent enough to decide where that should be.
> >
>
> Hi,
> Could you please try the below patch:
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> fs/isofs/inode.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
> --- linux/fs/isofs/inode.c2007-12-18 10:31:12.0 +0800
> +++ linux.new/fs/isofs/inode.c2007-12-18 10:31:56.0 +0800
> @@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
> ret = isofs_read_inode(inode);
> if (ret < 0) {
> iget_failed(inode);
> - inode = ERR_PTR(ret);
> + return NULL;
> } else {
>
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Hello,
[EMAIL PROTECTED] wrote:
> --- sata_nv.c.orig2007-12-17 21:08:12.0 +0530
> +++ sata_nv.c 2007-12-17 21:08:25.0 +0530
> @@ -2407,6 +2407,12 @@
> type = GENERIC;
> }
>
> + /* set 64bit dma masks, may fail */
> + if (type == ADMA) {
> + if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> + pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> + }
> +
> ppi[0] = &nv_port_info[type];
> rc = ata_pci_prepare_sff_host(pdev, ppi, &host);
> if (rc)
> @@ -2418,12 +2424,6 @@
> hpriv->type = type;
> host->private_data = hpriv;
>
> - /* set 64bit dma masks, may fail */
> - if (type == ADMA) {
> - if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> - pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> - }
> -
This is weird. IIRC, the problem is caused by allocating consistent
memory for legacy DMA over 32bit limit. Your patch moves setting 64bit
DMA mask upward but it doesn't affect anything because
ata_pci_prepare_sff_host() and hpriv allocation are not DMA memory
allocations and thus unaffected by DMA mask.
Robert's last patch seems correct to me. I have no idea why it doesn't
work for you tho. Another interesting point is that you are reporting
data corruption instead of time out or HSM violation, which indicates
that the PRD table is accessible but what it contains is incorrect.
I guess it's time to print out some memory addresses. I'll prep a debug
patch soon.
Thanks.
--
tejun
--
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/
[PATCH 1/2 2.6.25] cxgb3 - parity initialization for T3C adapters.
From: Divy Le Ray <[EMAIL PROTECTED]>
Add parity initialization for T3C adapters.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |1
drivers/net/cxgb3/cxgb3_main.c| 82
drivers/net/cxgb3/cxgb3_offload.c | 15 ++
drivers/net/cxgb3/regs.h | 248 +
drivers/net/cxgb3/sge.c | 24 +++-
drivers/net/cxgb3/t3_hw.c | 131 +---
6 files changed, 472 insertions(+), 29 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index 60a62f5..eb305a0 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -71,6 +71,7 @@ enum {/* adapter flags */
USING_MSI = (1 << 1),
USING_MSIX = (1 << 2),
QUEUES_BOUND = (1 << 3),
+ TP_PARITY_INIT = (1 << 4),
};
struct fl_pg_chunk {
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 944423c..d1aa777 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -306,6 +306,77 @@ static int request_msix_data_irqs(struct adapter *adap)
return 0;
}
+static int await_mgmt_replies(struct adapter *adap, unsigned long init_cnt,
+ unsigned long n)
+{
+ int attempts = 5;
+
+ while (adap->sge.qs[0].rspq.offload_pkts < init_cnt + n) {
+ if (!--attempts)
+ return -ETIMEDOUT;
+ msleep(10);
+ }
+ return 0;
+}
+
+static int init_tp_parity(struct adapter *adap)
+{
+ int i;
+ struct sk_buff *skb;
+ struct cpl_set_tcb_field *greq;
+ unsigned long cnt = adap->sge.qs[0].rspq.offload_pkts;
+
+ t3_tp_set_offload_mode(adap, 1);
+
+ for (i = 0; i < 16; i++) {
+ struct cpl_smt_write_req *req;
+
+ skb = alloc_skb(sizeof(*req), GFP_KERNEL | __GFP_NOFAIL);
+ req = (struct cpl_smt_write_req *)__skb_put(skb, sizeof(*req));
+ memset(req, 0, sizeof(*req));
+ req->wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+ OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_SMT_WRITE_REQ, i));
+ req->iff = i;
+ t3_mgmt_tx(adap, skb);
+ }
+
+ for (i = 0; i < 2048; i++) {
+ struct cpl_l2t_write_req *req;
+
+ skb = alloc_skb(sizeof(*req), GFP_KERNEL | __GFP_NOFAIL);
+ req = (struct cpl_l2t_write_req *)__skb_put(skb, sizeof(*req));
+ memset(req, 0, sizeof(*req));
+ req->wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+ OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_L2T_WRITE_REQ, i));
+ req->params = htonl(V_L2T_W_IDX(i));
+ t3_mgmt_tx(adap, skb);
+ }
+
+ for (i = 0; i < 2048; i++) {
+ struct cpl_rte_write_req *req;
+
+ skb = alloc_skb(sizeof(*req), GFP_KERNEL | __GFP_NOFAIL);
+ req = (struct cpl_rte_write_req *)__skb_put(skb, sizeof(*req));
+ memset(req, 0, sizeof(*req));
+ req->wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+ OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_RTE_WRITE_REQ, i));
+ req->l2t_idx = htonl(V_L2T_W_IDX(i));
+ t3_mgmt_tx(adap, skb);
+ }
+
+ skb = alloc_skb(sizeof(*greq), GFP_KERNEL | __GFP_NOFAIL);
+ greq = (struct cpl_set_tcb_field *)__skb_put(skb, sizeof(*greq));
+ memset(greq, 0, sizeof(*greq));
+ greq->wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+ OPCODE_TID(greq) = htonl(MK_OPCODE_TID(CPL_SET_TCB_FIELD, 0));
+ greq->mask = cpu_to_be64(1);
+ t3_mgmt_tx(adap, skb);
+
+ i = await_mgmt_replies(adap, cnt, 16 + 2048 + 2048 + 1);
+ t3_tp_set_offload_mode(adap, 0);
+ return i;
+}
+
/**
* setup_rss - configure RSS
* @adap: the adapter
@@ -817,6 +888,7 @@ static int cxgb_up(struct adapter *adap)
if (err)
goto out;
+ t3_set_reg_field(adap, A_TP_PARA_REG5, 0, F_RXDDPOFFINIT);
t3_write_reg(adap, A_ULPRX_TDDP_PSZ, V_HPZ0(PAGE_SHIFT - 12));
err = setup_sge_qsets(adap);
@@ -856,6 +928,16 @@ static int cxgb_up(struct adapter *adap)
t3_sge_start(adap);
t3_intr_enable(adap);
+ if (adap->params.rev >= T3_REV_C && !(adap->flags & TP_PARITY_INIT) &&
+ is_offload(adap) && init_tp_parity(adap) == 0)
+ adap->flags |= TP_PARITY_INIT;
+
+ if (adap->flags & TP_PARITY_INIT) {
+ t3_write_reg(adap, A_TP_INT_CAUSE,
+F_CMCACHEPERR | F_ARPLUTPERR);
+ t3_write_reg(adap, A_TP_INT_ENABLE, 0x7fbf);
+ }
+
if ((adap->flags & (USING_MSIX | QUEUES_BOUND)) == USING_MSIX)
bind_qsets(adap);
adap->flags |= QUEUES_BOUND;
diff --git a/drive
[PATCH 2/2 2.6.25] cxgb3 - Fix EEH, missing softirq blocking
From: Divy Le Ray <[EMAIL PROTECTED]>
set_pci_drvdata() stores a pointer to the adapter,
not the net device.
Add missing softirq blocking in t3_mgmt_tx.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 14 --
drivers/net/cxgb3/sge.c|7 ++-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index d1aa777..0e3dcbf 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2408,9 +2408,7 @@ void t3_fatal_err(struct adapter *adapter)
static pci_ers_result_t t3_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct port_info *pi = netdev_priv(dev);
- struct adapter *adapter = pi->adapter;
+ struct adapter *adapter = pci_get_drvdata(pdev);
int i;
/* Stop all ports */
@@ -2444,9 +2442,7 @@ static pci_ers_result_t t3_io_error_detected(struct
pci_dev *pdev,
*/
static pci_ers_result_t t3_io_slot_reset(struct pci_dev *pdev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct port_info *pi = netdev_priv(dev);
- struct adapter *adapter = pi->adapter;
+ struct adapter *adapter = pci_get_drvdata(pdev);
if (pci_enable_device(pdev)) {
dev_err(&pdev->dev,
@@ -2469,9 +2465,7 @@ static pci_ers_result_t t3_io_slot_reset(struct pci_dev
*pdev)
*/
static void t3_io_resume(struct pci_dev *pdev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct port_info *pi = netdev_priv(dev);
- struct adapter *adapter = pi->adapter;
+ struct adapter *adapter = pci_get_drvdata(pdev);
int i;
/* Restart the ports */
@@ -2491,7 +2485,7 @@ static void t3_io_resume(struct pci_dev *pdev)
if (is_offload(adapter)) {
__set_bit(OFFLOAD_DEVMAP_BIT, &adapter->registered_device_map);
- if (offload_open(dev))
+ if (offload_open(adapter->port[0]))
printk(KERN_WARNING
"Could not bring back offload capabilities\n");
}
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index cef153d..6367cee 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1364,7 +1364,12 @@ static void restart_ctrlq(unsigned long data)
*/
int t3_mgmt_tx(struct adapter *adap, struct sk_buff *skb)
{
- return ctrl_xmit(adap, &adap->sge.qs[0].txq[TXQ_CTRL], skb);
+ int ret;
+ local_bh_disable();
+ ret = ctrl_xmit(adap, &adap->sge.qs[0].txq[TXQ_CTRL], skb);
+ local_bh_enable();
+
+ return ret;
}
/**
--
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/
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote: > On Sun, 16 Dec 2007 21:55:20 + Mel Gorman wrote: > > > > > Just using cp to read the file is enough to cause problems but I > > > > included > > > > a very basic program below that produces the BUG_ON checks. Is this a > > > > known > > > > issue or am I using the interface incorrectly? > > > > > > I'd say you're using it correctly but you've found a hitherto unknown > > > bug. > > > On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map() > > > takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it > > > presently does. > > > > > > Drat. > > > > > > Still, that shouldn't really disrupt the testing which you're doing. You > > > could disable CONFIG_HIGHPTE to shut it up. > > > > > > > Yes, that did the trick. Using pagemap, it was trivial to show that the > > 2.6.24-rc5-mm1 kernel was placing pages in reverse physical order like > > the following output shows > > > > b: 32763 v: 753091 p:65559 . 65558 contig: 1 > > b: 32764 v: 753092 p:65558 . 65557 contig: 1 > > b: 32765 v: 753093 p:65557 . 65556 contig: 1 > > b: 32766 v: 753094 p:65556 . 6 contig: 1 > > b: 32767 v: 753095 p:6 . 6 contig: 1 > > > > p: is the PFN of the page v: is the page offset within an anonymous > > mapping and b: is the number of non-contiguous blocks in the anonymous > > mapping. With the patch applied, it looks more like; > > > > b: 1232 v: 752964 p:58944 87328 contig: 15 > > b: 1233 v: 752980 p:87328 91200 contig: 15 > > b: 1234 v: 752996 p:91200 40272 contig: 15 > > b: 1235 v: 753012 p:40272 85664 contig: 15 > > b: 1236 v: 753028 p:85664 87312 contig: 15 > > > > so mappings are using contiguous pages again. This was the final test > > program I used in case it's of any interest. > > > > Thanks > > > > /* > > * showcontiguous.c > > * > > * Use the /proc/pid/pagemap interface to give an indication of how > > contiguous > > * physical memory is in an anonymous virtual memory mapping > > */ > > Matt, > Did you ever make your python pagemap scripts available? > If not, would you? There's a collection of them at http://selenic.com/repo/pagemap. They're largely proof of concept, and I'm not sure I finished adapting them all to the final 64-bit interface. As it happens, the above regression I actually spotted immediately by doing a simple hexdump on my very first test of the interface - lots of pfns counting backwards. Mentioned it a few times to various people in the cc: list and on lkml but never got around to tracking it down myself.. -- Mathematics is the supreme nostalgia of our time. -- 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/
Re: [PATCH 7/7] Makefile
Ignore this patch, I forgot to remove it before mailing the series.
On 12/17/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
>
> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
> ---
>
> Makefile |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/Makefile b/Makefile
> index c1825aa..15ada3f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -35,6 +35,9 @@ MAKEFLAGS += -rR --no-print-directory
> # To put more focus on warnings, be less verbose as default
> # Use 'make V=1' to see the full commands
>
> +ARCH=powerpc
> +CROSS_COMPILE=powerpc-603e-linux-gnu-
> +
> ifdef V
>ifeq ("$(origin V)", "command line")
> KBUILD_VERBOSE = $(V)
>
> --
> 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/
>
--
Jon Smirl
[EMAIL PROTECTED]
--
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/
[PATCH 7/7] Makefile
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
Makefile |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index c1825aa..15ada3f 100644
--- a/Makefile
+++ b/Makefile
@@ -35,6 +35,9 @@ MAKEFLAGS += -rR --no-print-directory
# To put more focus on warnings, be less verbose as default
# Use 'make V=1' to see the full commands
+ARCH=powerpc
+CROSS_COMPILE=powerpc-603e-linux-gnu-
+
ifdef V
ifeq ("$(origin V)", "command line")
KBUILD_VERBOSE = $(V)
--
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/
[PATCH] update module-init-tools to support the i2c subsystem
Follow on to: "Series to add device tree naming to i2c"
Teach module-init-tools about the i2c subsystem.
diff --git a/depmod.c b/depmod.c
index 0281c79..209eb0c 100644
--- a/depmod.c
+++ b/depmod.c
@@ -793,6 +793,7 @@ static struct depfile depfiles[] = {
{ "modules.inputmap", output_input_table },
{ "modules.ofmap", output_of_table },
{ "modules.seriomap", output_serio_table },
+ { "modules.i2cmap", output_i2c_table },
{ "modules.alias", output_aliases },
{ "modules.symbols", output_symbols },
};
diff --git a/depmod.h b/depmod.h
index 6cea36e..1040214 100644
--- a/depmod.h
+++ b/depmod.h
@@ -55,6 +55,8 @@ struct module
unsigned int input_table_size;
unsigned int serio_size;
void *serio_table;
+ unsigned int i2c_size;
+ void *i2c_table;
unsigned int of_size;
void *of_table;
diff --git a/moduleops_core.c b/moduleops_core.c
index 56c85d3..a7ca350 100644
--- a/moduleops_core.c
+++ b/moduleops_core.c
@@ -230,6 +230,11 @@ static void PERBIT(fetch_tables)(struct module *module)
"__mod_serio_device_table",
NULL, module->conv);
+ module->i2c_size = PERBIT(I2C_DEVICE_SIZE);
+ module->i2c_table = PERBIT(deref_sym)(module->data,
+ "__mod_i2c_device_table",
+ NULL, module->conv);
+
module->of_size = PERBIT(OF_DEVICE_SIZE);
module->of_table = PERBIT(deref_sym)(module->data,
"__mod_of_device_table",
diff --git a/tables.c b/tables.c
index 6dfd165..82e162d 100644
--- a/tables.c
+++ b/tables.c
@@ -496,6 +496,35 @@ void output_serio_table(struct module *modules, FILE *out)
}
+static void output_i2c_entry(struct i2c_device_id *i2c, char *name, FILE *out)
+{
+ fprintf(out,
+ "%-20s %-20s\n",
+ name,
+ i2c->name);
+}
+
+
+void output_i2c_table(struct module *modules, FILE *out)
+{
+ struct module *i;
+
+ fprintf(out, "# i2c module name\n");
+
+ for (i = modules; i; i = i->next) {
+ struct i2c_device_id *e;
+ char shortname[strlen(i->pathname) + 1];
+
+ if (!i->i2c_table)
+ continue;
+
+ make_shortname(shortname, i->pathname);
+ for (e = i->i2c_table; e->name[0]; e = (void *)e + i->i2c_size)
+ output_i2c_entry(e, shortname, out);
+ }
+}
+
+
static void
strip_whitespace (char *str, char chr)
{
diff --git a/tables.h b/tables.h
index e5f6f35..263369d 100644
--- a/tables.h
+++ b/tables.h
@@ -164,6 +164,12 @@ struct serio_device_id {
#define SERIO_DEVICE_SIZE32 (4 * 1)
#define SERIO_DEVICE_SIZE64 (4 * 1 + 4)
+struct i2c_device_id {
+ char name[48];
+};
+#define I2C_DEVICE_SIZE32 (48 + 4)
+#define I2C_DEVICE_SIZE64 (48 + 8)
+
struct of_device_id {
char name[32];
char type[32];
@@ -182,6 +188,7 @@ void output_ccw_table(struct module *modules, FILE *out);
void output_isapnp_table(struct module *modules, FILE *out);
void output_input_table(struct module *modules, FILE *out);
void output_serio_table(struct module *modules, FILE *out);
+void output_i2c_table(struct module *modules, FILE *out);
void output_of_table(struct module *modules, FILE *out);
#endif /* MODINITTOOLS_TABLES_H */
--
Jon Smirl
[EMAIL PROTECTED]
--
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/
[PATCH 2/7] Implement module aliasing for i2c to translate from device tree names
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/i2c/i2c-core.c | 32 ++--
include/linux/i2c.h |9 -
include/linux/mod_devicetable.h | 20
scripts/mod/file2alias.c| 19 +++
4 files changed, 69 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..fce06fd 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,10 +47,25 @@ static DEFINE_IDR(i2c_adapter_idr);
/* - */
-static int i2c_device_match(struct device *dev, struct device_driver *drv)
+static const struct i2c_device_id *i2c_device_match(const struct i2c_device_id
*id, struct i2c_client *client)
+{
+ /* only powerpc drivers implement the id_table,
+* it is empty on other platforms */
+ if (id) {
+ while (id->name[0]) {
+ if (strcmp(client->driver_name, id->name) == 0)
+ return id;
+ id++;
+ }
+ }
+ return NULL;
+}
+
+static int i2c_bus_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
+ const struct i2c_device_id *found_id;
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
@@ -58,9 +73,11 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
if (!is_newstyle_driver(driver))
return 0;
- /* new style drivers use the same kind of driver matching policy
-* as platform devices or SPI: compare device and driver IDs.
-*/
+ /* match on an id table if there is one */
+ found_id = i2c_device_match(driver->id_table, client);
+ if (found_id)
+ return 1;
+
return strcmp(client->driver_name, drv->name) == 0;
}
@@ -89,12 +106,15 @@ static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(dev->driver);
+ const struct i2c_device_id *id;
if (!driver->probe)
return -ENODEV;
client->driver = driver;
dev_dbg(dev, "probe\n");
- return driver->probe(client);
+
+ id = i2c_device_match(driver->id_table, client);
+ return driver->probe(client, id);
}
static int i2c_device_remove(struct device *dev)
@@ -189,7 +209,7 @@ static struct device_attribute i2c_dev_attrs[] = {
static struct bus_type i2c_bus_type = {
.name = "i2c",
.dev_attrs = i2c_dev_attrs,
- .match = i2c_device_match,
+ .match = i2c_bus_match,
.uevent = i2c_device_uevent,
.probe = i2c_device_probe,
.remove = i2c_device_remove,
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a100c9f..49fc682 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -126,7 +126,7 @@ struct i2c_driver {
* With the driver model, device enumeration is NEVER done by drivers;
* it's done by infrastructure. (NEW STYLE DRIVERS ONLY)
*/
- int (*probe)(struct i2c_client *);
+ int (*probe)(struct i2c_client *, const struct i2c_device_id *id);
int (*remove)(struct i2c_client *);
/* driver model interfaces that don't relate to enumeration */
@@ -141,11 +141,10 @@ struct i2c_driver {
struct device_driver driver;
struct list_head list;
+ struct i2c_device_id *id_table;
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
-#define I2C_NAME_SIZE 20
-
/**
* struct i2c_client - represent an I2C slave device
* @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
@@ -179,7 +178,7 @@ struct i2c_client {
/* to the client*/
struct device dev; /* the device structure */
int irq;/* irq issued by device (or -1) */
- char driver_name[KOBJ_NAME_LEN];
+ char driver_name[I2C_NAME_SIZE];
struct list_head list;
struct completion released;
};
@@ -223,7 +222,7 @@ static inline void i2c_set_clientdata (struct i2c_client
*dev, void *data)
* with the adapter already known.
*/
struct i2c_board_info {
- chardriver_name[KOBJ_NAME_LEN
[PATCH 4/7] Clean up error returns
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-mpc.c | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..7c35a8f 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -321,9 +325,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0) {
@@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
platform_set_drvdata(pdev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
iounmap(i2c->base);
--
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/
[PATCH 5/7] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
Convert MPC i2c driver from being a platform_driver to an open firmware
version. Error returns were improved. Routine names were changed from fsl_ to
mpc_ to make them match the file name.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 96
drivers/i2c/busses/i2c-mpc.c | 167 +
2 files changed, 119 insertions(+), 144 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 268638a..d6ef264 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -318,102 +318,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
- const char *compatible;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_soc.c: invalid i2c device
entry\n");
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- compatible = of_get_property(node, "compatible", &len);
- if (!compatible) {
- printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing
compatible attribute\n");
- continue;
- }
- strncpy(info.driver_name, compatible, sizeof(info.driver_name));
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, &info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *i2c_dev;
- int ret;
-
- for (np = NULL, i = 0;
-(np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
-i++) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(&r, 0, sizeof(r));
- memset(&i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, &r[1]);
-
- i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, "dfsrr", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, "fsl5200-clocking", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, &i2c_data,
-sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
-
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
{
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7c35a8f..fc46207 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -25,13 +25,13 @@
#include
#include
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME "mpc-i2c"
+
#define MPC_I2C_FDR0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -316,105 +316,176 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
-static int fsl_i2c_probe(struct platform_device *pdev)
+struct i2c_driver_device {
+ char*of_device;
+ char*i2c_driver;
+ char*i2c_type;
+};
+
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+
[PATCH 1/7] Copy mpc-i2c to preserve support for ARCH=ppc and allow changes on ARCH=powerpc
Temporarily copy the mpc-i2c driver to continue support for the ppc architecture until it is removed in mid-2008. This file should be deleted as part of ppc's final removal. Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> --- arch/ppc/configs/TQM8540_defconfig |2 arch/ppc/configs/TQM8541_defconfig |2 arch/ppc/configs/TQM8555_defconfig |2 arch/ppc/configs/TQM8560_defconfig |2 arch/ppc/configs/mpc834x_sys_defconfig |2 arch/ppc/configs/mpc8540_ads_defconfig |2 arch/ppc/configs/mpc8548_cds_defconfig |2 arch/ppc/configs/mpc8555_cds_defconfig |2 arch/ppc/configs/mpc8560_ads_defconfig |2 drivers/i2c/busses/Kconfig | 16 + drivers/i2c/busses/Makefile|1 drivers/i2c/busses/i2c-mpc-ppc.c | 418 12 files changed, 443 insertions(+), 10 deletions(-) create mode 100644 drivers/i2c/busses/i2c-mpc-ppc.c diff --git a/arch/ppc/configs/TQM8540_defconfig b/arch/ppc/configs/TQM8540_defconfig index f33f0e7..7098ed0 100644 --- a/arch/ppc/configs/TQM8540_defconfig +++ b/arch/ppc/configs/TQM8540_defconfig @@ -684,7 +684,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set diff --git a/arch/ppc/configs/TQM8541_defconfig b/arch/ppc/configs/TQM8541_defconfig index e00cd62..2137d01 100644 --- a/arch/ppc/configs/TQM8541_defconfig +++ b/arch/ppc/configs/TQM8541_defconfig @@ -687,7 +687,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_MPC8260 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set diff --git a/arch/ppc/configs/TQM8555_defconfig b/arch/ppc/configs/TQM8555_defconfig index 43a0d9d..f2317b6 100644 --- a/arch/ppc/configs/TQM8555_defconfig +++ b/arch/ppc/configs/TQM8555_defconfig @@ -687,7 +687,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set diff --git a/arch/ppc/configs/TQM8560_defconfig b/arch/ppc/configs/TQM8560_defconfig index a814d17..6c19121 100644 --- a/arch/ppc/configs/TQM8560_defconfig +++ b/arch/ppc/configs/TQM8560_defconfig @@ -694,7 +694,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_MPC8260 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set diff --git a/arch/ppc/configs/mpc834x_sys_defconfig b/arch/ppc/configs/mpc834x_sys_defconfig index d90c8a7..cd568d2 100644 --- a/arch/ppc/configs/mpc834x_sys_defconfig +++ b/arch/ppc/configs/mpc834x_sys_defconfig @@ -562,7 +562,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set diff --git a/arch/ppc/configs/mpc8540_ads_defconfig b/arch/ppc/configs/mpc8540_ads_defconfig index bf676eb..5819835 100644 --- a/arch/ppc/configs/mpc8540_ads_defconfig +++ b/arch/ppc/configs/mpc8540_ads_defconfig @@ -452,7 +452,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set diff --git a/arch/ppc/configs/mpc8548_cds_defconfig b/arch/ppc/configs/mpc8548_cds_defconfig index f36fc5d..e5b5071 100644 --- a/arch/ppc/configs/mpc8548_cds_defconfig +++ b/arch/ppc/configs/mpc8548_cds_defconfig @@ -413,7 +413,7 @@ CONFIG_I2C_CHARDEV=y # # I2C Hardware Bus support # -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PCA_ISA is not set diff --git a/arch/ppc/configs/mpc8555_cds_defconfig b/arch/ppc/configs/mpc8555_cds_defconfig index 4f1e320..08dbab0 100644 --- a/arch/ppc/configs/mpc8555_cds_defconfig +++ b/arch/ppc/configs/mpc8555_cds_defconfig @@ -518,7 +518,7 @@ CONFIG_I2C_CHARDEV=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_MPC=y +CONFIG_I2C_MPC_PPC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set diff --git a/arch/ppc/configs/mpc8560_ads_defconfig b/arch/ppc/configs/mpc8560_ads_defconfig index f12d48f..0e0080b 100644 --- a/arch/ppc/configs/mpc8560_ads_defconfig +++ b/arc
[PATCH 0/7] Series to add device tree naming to i2c
Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. Since the i2c-mpc driver also supports the ppc architecture the i2c-mpc driver was copied to i2c-mpc-ppc before changes were made. The i2c-mpc-ppc driver should be deleted in six months when the rest of the ppc architecture is removed. The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. -- Jon Smirl [EMAIL PROTECTED] -- 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/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
>
> (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
> actually does that code?)
>
> > > I try it again, and it reports it died at the same exact place, but in
> > > about
> > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I
> > > didn't
> > > think that blocks read from /dev/cdrom would get cached, but OK.
> >
> > It'll remain cached if something is holding the device open.
>
> Does it need to be "device open", or are there other things as well? If the
> drop_cache was hosed, that would result in the same symptoms, no?
>
> > Something's holding s_umount for writing I guess. Possibly busted error
> > handling somewhere totally different.
>
> Aha - found what was holding it - an attempt to loopback mount the truncated
> file (before I realized it was truncated) had failed - I had gotten a 'Killed'
> back from the mount, but I didn't realize it had pulled an actual oops:
>
> Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond
> end of device
> Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0,
> want=1284500, limit=314240
> Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read
> i-node block
> Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel
> NULL pointer dereference at 010b RIP:
> Dec 17 15:54:33 turing-police kernel: [14503.402440] []
> iput+0x11/0x80
> ...
> Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace:
> Dec 17 15:54:33 turing-police kernel: [14503.403026] []
> isofs_fill_super+0x7e9/0xa6b
> Dec 17 15:54:33 turing-police kernel: [14503.403045] []
> __down_write_nested+0x3d/0xa1
> Dec 17 15:54:33 turing-police kernel: [14503.403061] []
> __down_write+0xb/0xd
> Dec 17 15:54:33 turing-police kernel: [14503.403076] []
> sget+0x397/0x3a9
> Dec 17 15:54:33 turing-police kernel: [14503.403090] []
> set_bdev_super+0x0/0x14
> Dec 17 15:54:33 turing-police kernel: [14503.403106] []
> get_sb_bdev+0x109/0x157
> Dec 17 15:54:33 turing-police kernel: [14503.403120] []
> isofs_fill_super+0x0/0xa6b
> Dec 17 15:54:33 turing-police kernel: [14503.403138] []
> isofs_get_sb+0x13/0x15
> Dec 17 15:54:33 turing-police kernel: [14503.403151] []
> vfs_kern_mount+0x90/0x11a
> Dec 17 15:54:33 turing-police kernel: [14503.403167] []
> do_kern_mount+0x47/0xe3
> Dec 17 15:54:33 turing-police kernel: [14503.403183] []
> do_mount+0x717/0x78a
> Dec 17 15:54:33 turing-police kernel: [14503.403199] []
> _read_lock_irq+0x9/0xb
> Dec 17 15:54:33 turing-police kernel: [14503.403212] []
> find_lock_page+0x8c/0x97
> Dec 17 15:54:33 turing-police kernel: [14503.403227] []
> filemap_fault+0x1fa/0x3c6
> Dec 17 15:54:33 turing-police kernel: [14503.403241] []
> unlock_page+0x2d/0x31
> Dec 17 15:54:33 turing-police kernel: [14503.403254] []
> __do_fault+0x38d/0x3c3
> Dec 17 15:54:33 turing-police kernel: [14503.403274] []
> handle_mm_fault+0x36d/0x6e9
> Dec 17 15:54:33 turing-police kernel: [14503.403293] []
> __alloc_pages+0x68/0x2f6
> Dec 17 15:54:33 turing-police kernel: [14503.403314] []
> sys_mount+0x89/0xcb
> Dec 17 15:54:33 turing-police kernel: [14503.403328] []
> syscall_trace_enter+0x97/0x9b
> Dec 17 15:54:33 turing-police kernel: [14503.403344] []
> tracesys+0xdc/0xe1
> Dec 17 15:54:33 turing-police kernel: [14503.403359]
> Dec 17 15:54:33 turing-police kernel: [14503.403366]
> Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00
> 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75
>
> I don't mind it failing the mount, but the oops seems excessive. I suspect
> that *somewhere* in that stack trace, we're wanting something like a
>
> if (!foo_ptr)
> return -EIO;
>
> but I admit not being competent enough to decide where that should be.
>
Hi,
Could you please try the below patch:
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
fs/isofs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c 2007-12-18 10:31:12.0 +0800
+++ linux.new/fs/isofs/inode.c 2007-12-18 10:31:56.0 +0800
@@ -1414,7 +1414,7 @@ struct inode *isofs_iget(struct super_bl
ret = isofs_read_inode(inode);
if (ret < 0) {
iget_failed(inode);
- inode = ERR_PTR(ret);
+ return NULL;
} else {
unlock_new_inode(inode);
}
--
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/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 8:16 PM, Larry Finger <[EMAIL PROTECTED]> wrote: > > I hope that you have now convinced yourself that you should be using b43 and > not messing around > forcing b43legacy to use a device for which it was not intended. > I was convinced the moment I realized it worked exactly the same as b43 (if they work the same, I'd rather use the intended driver). The b43legacy test was more out of desperation than anything serious. I thought I should share though, since my original question was about the firmware and because the difference between versions (or lack thereof) had been discussed in this thread. > You should concentrate on what in your environment changed when you rebooted. > If you can get the 200 > kBs rate back, please note the noise and signal levels as compared to the > values when you are > restricted to 40 kBs. > Really, the only thing that might have changed is some things that may have caused noise were turned off -- in other words, there should have been more noise with the 200 kB/s, but of course that doesn't make sense. It should be noted though that even at 200 kB/s, the b43 driver was operating at less than half the speed of bcm43xx. That being said, I've been trying very hard to repeat this, but cannot. I'll keep trying though, and make sure to note everything possible if it ever happens again. > Is it possible for you to test your laptop on another AP? > Not currently, but I'll try to find a way to do so -- not sure how long it'll take. -- 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/
Re: Top kernel oopses/warnings this week
On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote: > which also gets bonus points for being totally unreadable, and thus 100% > in the spirit of uuid's. Heh. UUID's don't have to be readable; just universally unique. Code on the other hand should be readable. :-) If you want something more readable, you could print the MAC address and boot time. Of course some crazy people seem to think leaking the MAC address will somehow be a privacy violation. And printing a random UUID is a lot simpler - Ted -- 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/
RE: [PATCH] drivers/scsi/: Spelling fixes
On Mon, 17 Dec 2007, Joe Perches wrote: > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > drivers/scsi/qla4xxx/ql4_def.h|2 +- > drivers/scsi/qla4xxx/ql4_init.c |2 +- Acked-by: David Somayajulu <[EMAIL PROTECTED]> -- 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/
BAN CAN HO CAO CAP V-STAR (SAIGON) -CHI CON 2 CAN -GIA DAC BIET
Chao cac ban, Ban nhan duoc email nay la do ban hoac mot ai do da dang ky dia chi email cua ban tai trang web: www.nhaban.net.tf, www.nhaban.vnn.bz, www.nhadep.us de nhan cac thong tin nha dat moi nhat cua chung toi. Nay chung toi han hanh thong bao voi cac ban cac can ho cao cap chung toi dang chao ban (CHI CON CO 2 CAN- DEP NHAT -GIA TOT NHAT). Chung toi can ban mot so can ho cao cap V-Star cua Han Quoc xay dung o quan 7 (RAT GAN PHU MY HUNG), TP.HCM Vi tri tuyet voi, cac can ho thiet ke rat dep, hien dai, tien nghi, an ninh...va rat nhieu cac tien ich khac. Ban co the xem bai viet cua BAO SAI GON GIAI PHONG (20/05/2007) o Website: http://www.canhocaocap.net/page.asp?nha=21 Can ho rat thich hop voi moi doi tuong, co the dung de o hoac dau tu... TOA NHA V-STAR DA HOAN THIEN PHAN MONG VA TANG HAM Moi quy khach vao xem chi tiet cu the o website: http://www.canhocaocap.net Ban co the xem cac hinh anh toa nha, phong oc, cac tien ich, ban do... email: [EMAIL PROTECTED] Ngoai ra ban co the xem cac hinh kien truc nha dep o Sai Gon ( http://nhadep.us ) Xin cam on da xem tin *** V-Star- Vstar- vstar - vsta - vta - korea -- 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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. Serge E. Hallyn wrote: > But your requirements are to ensure that an application accessing a > device at a well-known location get what it expect. Yes. That's the purpose of this filesystem. > So then the main quesiton is still the one I think Al had asked - what > keeps a rogue CAP_SYS_MOUNT process from doing > mount --bind /dev/hda1 /dev/null ? Excuse me, but I guess you meant "mount --bind /dev/ /root/" or something because mount operation requires directories. MAC can prevent a rogue CAP_SYS_MOUNT process from doing "mount --bind /dev/ /root/". For example, regarding TOMOYO Linux, you need to give "allow_mount /dev/ /root/ --bind 0" permission to permit "mount --bind /dev/ /root/" request. Did you mean "ln -s /dev/hda1 /dev/null" or "ln /dev/hda1 /dev/null"? No problem. MAC can prevent such requests too. Regards. -- 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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Oren Laadan ([EMAIL PROTECTED]): > > I hate to bring this again, but what if the admin in the container > mounts an external file system (eg. nfs, usb, loop mount from a file, > or via fuse), and that file system already has a device that we would > like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt->mnt_flags |= MNT_NODEV. So that's no problem. But that's been pulled out of -mm! ? Crap. > Since anyway we will have to keep a white- (or black-) list of devices > that are permitted in a container, and that list may change even change > per container -- why not enforce the access control at the VFS layer ? > It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? thanks, -serge -- 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/
[PATCH 1/3]pci: fix typo in pci_save_pcix_state
pci_save/store_state has multiple bugs, which will cause cap can't be
saved/restored correctly. Below 3 patches fix them.
fix the typo in pci_save_pcix_state
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/pci.c
===
--- linux.orig/drivers/pci/pci.c2007-12-18 09:35:00.0 +0800
+++ linux/drivers/pci/pci.c 2007-12-18 09:35:38.0 +0800
@@ -602,7 +602,7 @@ static int pci_save_pcix_state(struct pc
if (pos <= 0)
return 0;
- save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+ save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
if (!save_state)
save_state = kzalloc(sizeof(*save_state) + sizeof(u16),
GFP_KERNEL);
if (!save_state) {
--
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/
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said: (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever actually does that code?) > > I try it again, and it reports it died at the same exact place, but in about > > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't > > think that blocks read from /dev/cdrom would get cached, but OK. > > It'll remain cached if something is holding the device open. Does it need to be "device open", or are there other things as well? If the drop_cache was hosed, that would result in the same symptoms, no? > Something's holding s_umount for writing I guess. Possibly busted error > handling somewhere totally different. Aha - found what was holding it - an attempt to loopback mount the truncated file (before I realized it was truncated) had failed - I had gotten a 'Killed' back from the mount, but I didn't realize it had pulled an actual oops: Dec 17 15:54:33 turing-police kernel: [14503.402385] attempt to access beyond end of device Dec 17 15:54:33 turing-police kernel: [14503.402391] loop1: rw=0, want=1284500, limit=314240 Dec 17 15:54:33 turing-police kernel: [14503.402395] ISOFS: unable to read i-node block Dec 17 15:54:33 turing-police kernel: [14503.402428] Unable to handle kernel NULL pointer dereference at 010b RIP: Dec 17 15:54:33 turing-police kernel: [14503.402440] [] iput+0x11/0x80 ... Dec 17 15:54:33 turing-police kernel: [14503.403008] Call Trace: Dec 17 15:54:33 turing-police kernel: [14503.403026] [] isofs_fill_super+0x7e9/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403045] [] __down_write_nested+0x3d/0xa1 Dec 17 15:54:33 turing-police kernel: [14503.403061] [] __down_write+0xb/0xd Dec 17 15:54:33 turing-police kernel: [14503.403076] [] sget+0x397/0x3a9 Dec 17 15:54:33 turing-police kernel: [14503.403090] [] set_bdev_super+0x0/0x14 Dec 17 15:54:33 turing-police kernel: [14503.403106] [] get_sb_bdev+0x109/0x157 Dec 17 15:54:33 turing-police kernel: [14503.403120] [] isofs_fill_super+0x0/0xa6b Dec 17 15:54:33 turing-police kernel: [14503.403138] [] isofs_get_sb+0x13/0x15 Dec 17 15:54:33 turing-police kernel: [14503.403151] [] vfs_kern_mount+0x90/0x11a Dec 17 15:54:33 turing-police kernel: [14503.403167] [] do_kern_mount+0x47/0xe3 Dec 17 15:54:33 turing-police kernel: [14503.403183] [] do_mount+0x717/0x78a Dec 17 15:54:33 turing-police kernel: [14503.403199] [] _read_lock_irq+0x9/0xb Dec 17 15:54:33 turing-police kernel: [14503.403212] [] find_lock_page+0x8c/0x97 Dec 17 15:54:33 turing-police kernel: [14503.403227] [] filemap_fault+0x1fa/0x3c6 Dec 17 15:54:33 turing-police kernel: [14503.403241] [] unlock_page+0x2d/0x31 Dec 17 15:54:33 turing-police kernel: [14503.403254] [] __do_fault+0x38d/0x3c3 Dec 17 15:54:33 turing-police kernel: [14503.403274] [] handle_mm_fault+0x36d/0x6e9 Dec 17 15:54:33 turing-police kernel: [14503.403293] [] __alloc_pages+0x68/0x2f6 Dec 17 15:54:33 turing-police kernel: [14503.403314] [] sys_mount+0x89/0xcb Dec 17 15:54:33 turing-police kernel: [14503.403328] [] syscall_trace_enter+0x97/0x9b Dec 17 15:54:33 turing-police kernel: [14503.403344] [] tracesys+0xdc/0xe1 Dec 17 15:54:33 turing-police kernel: [14503.403359] Dec 17 15:54:33 turing-police kernel: [14503.403366] Dec 17 15:54:33 turing-police kernel: [14503.403367] Code: 48 8b 87 10 01 00 00 48 83 bf 38 02 00 00 40 48 8b 40 38 75 I don't mind it failing the mount, but the oops seems excessive. I suspect that *somewhere* in that stack trace, we're wanting something like a if (!foo_ptr) return -EIO; but I admit not being competent enough to decide where that should be. pgp96V9uaXsyW.pgp Description: PGP signature
[patch 2/3] pci: correctly initialize a structure
save_state->cap_nr should be correctly set, otherwise we can't find the saved cap at resume. Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> Index: linux/drivers/pci/pci.c === --- linux.orig/drivers/pci/pci.c2007-12-18 09:35:52.0 +0800 +++ linux/drivers/pci/pci.c 2007-12-18 09:36:40.0 +0800 @@ -569,6 +569,7 @@ static int pci_save_pcie_state(struct pc pci_read_config_word(dev, pos + PCI_EXP_LNKCTL, &cap[i++]); pci_read_config_word(dev, pos + PCI_EXP_SLTCTL, &cap[i++]); pci_read_config_word(dev, pos + PCI_EXP_RTCTL, &cap[i++]); + save_state->cap_nr = PCI_CAP_ID_EXP; pci_add_saved_cap(dev, save_state); return 0; } @@ -612,6 +613,7 @@ static int pci_save_pcix_state(struct pc cap = (u16 *)&save_state->data[0]; pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]); + save_state->cap_nr = PCI_CAP_ID_PCIX; pci_add_saved_cap(dev, save_state); return 0; } -- 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/
[git patches] net driver fixes
A couple serious fixes (wireless, e100, sky2) and a bevy of minor ones.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS|6 ++
drivers/net/e100.c |5 ++-
drivers/net/hamachi.c | 70 +---
drivers/net/ibm_newemac/debug.c|2 +-
drivers/net/ixgb/ixgb_main.c | 16 +-
drivers/net/pcmcia/pcnet_cs.c |1 +
drivers/net/s2io.c |4 +-
drivers/net/sis190.c | 10 ++--
drivers/net/sky2.c |9 +++-
drivers/net/smc911x.h |2 +-
drivers/net/starfire.c |2 +-
drivers/net/sundance.c | 34 ++--
drivers/net/ucc_geth.c |2 +-
drivers/net/ucc_geth_mii.h |2 +-
drivers/net/wireless/Kconfig |1 +
drivers/net/wireless/b43/leds.c|4 ++
drivers/net/wireless/b43/main.c| 22
drivers/net/wireless/b43/rfkill.c | 37 +++--
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |2 +-
drivers/net/wireless/ipw2200.c |7 ++-
drivers/net/wireless/iwlwifi/iwl3945-base.c|5 ++-
drivers/net/wireless/iwlwifi/iwl4965-base.c|5 ++-
drivers/net/wireless/zd1211rw/zd_mac.c | 10 +++-
net/mac80211/ieee80211_rate.c |1 +
24 files changed, 168 insertions(+), 91 deletions(-)
Adrian Bunk (3):
drivers/net/sis190.c section fix
drivers/net/s2io.c section fixes
wireless/ipw2200.c: add __dev{init,exit} annotations
Al Viro (4):
sundance fixes
starfire VLAN fix
hamachi endianness fixes
sis190 endianness
Andrew Morton (2):
ucc_geth: minor whitespace fix
bcm43xx_debugfs sscanf fix
Anton Vorontsov (1):
ucc_geth: really fix section mismatch
Auke Kok (1):
e100: free IRQ to remove warningwhenrebooting
Cyrill Gorcunov (2):
ieee80211_rate: missed unlock
iwlwifi3945/4965: fix rate control algo reference leak
Dan Williams (1):
libertas: select WIRELESS_EXT
Jiri Slaby (1):
Net: ibm_newemac, remove SPIN_LOCK_UNLOCKED
Komuro (1):
pcnet_cs: add new id
Larry Finger (1):
b43: Fix rfkill radio LED
Matheos Worku (1):
ixgb: make sure jumbos stay enabled after reset
Paul Mundt (1):
net: smc911x: shut up compiler warnings
Stefano Brivio (1):
libertas: add Dan Williams as maintainer
Stephen Hemminger (1):
sky2: RX lockup fix
Ulrich Kunitz (1):
zd1211rw: Fix alignment problems
Zhu Yi (1):
iwlwifi: fix rf_kill state inconsistent during suspend and resume
diff --git a/MAINTAINERS b/MAINTAINERS
index 9507b42..c331ba3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2489,6 +2489,12 @@ M: [EMAIL PROTECTED]
W: ftp://ftp.kernel.org/pub/linux/docs/manpages
S: Maintained
+MARVELL LIBERTAS WIRELESS DRIVER
+P: Dan Williams
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
+
MARVELL MV643XX ETHERNET DRIVER
P: Dale Farnsworth
M: [EMAIL PROTECTED]
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index e1c8a0d..2b06e4b 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2737,8 +2737,9 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- pci_disable_device(pdev);
free_irq(pdev->irq, netdev);
+
+ pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -2780,6 +2781,8 @@ static void e100_shutdown(struct pci_dev *pdev)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
+ free_irq(pdev->irq, netdev);
+
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
}
diff --git a/drivers/net/hamachi.c b/drivers/net/hamachi.c
index ed407c8..b53f6b6 100644
--- a/drivers/net/hamachi.c
+++ b/drivers/net/hamachi.c
@@ -204,8 +204,10 @@ KERN_INFO " Further modifications by Keith Underwood
<[EMAIL PROTECTED]>
/* Condensed bus+endian portability operations. */
#if ADDRLEN == 64
#define cpu_to_leXX(addr) cpu_to_le64(addr)
+#define leXX_to_cpu(addr) le64_to_cpu(addr)
#else
#define cpu_to_leXX(addr) cpu_to_le32(addr)
+#define leXX_to_cpu(addr) le32_to_cpu(addr)
#endif
@@ -465,12 +467,12 @@ enum intr_status_bits {
/* The Hamachi Rx and Tx buffer descriptors. */
struct hamachi_desc {
- u32 status_n_length;
+ __le32 status_n_length;
#if ADDRLEN == 64
u32 pad;
- u64 addr;
+ __le64 addr;
#else
- u32 addr;
+ __le32 addr;
#endif
};
@@ -874,13 +876,13 @@ sta
[git patches] libata fixes
In 2.6.24, we turned on ACPI support in libata. This is needed in order
to support suspend/resume and BIOS passworded drives, but it inevitably
brought with it a host of new regressions -- which is what happens
anytime you blindly accept ATA commands the BIOS has decided to toss
your way. :)
It is bigger than I would like for -rc5, but the bulk of these
changes are Tejun addressing regressions from 2.6.23, most of which
are ACPI-related.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-acpi.c | 387 +++--
drivers/ata/libata-core.c | 101 +
drivers/ata/libata-eh.c |4 +-
drivers/ata/libata.h |8 +-
drivers/ata/sata_mv.c | 30 +++-
drivers/ata/sata_sil.c| 18 +--
include/linux/ata.h | 15 ++
include/linux/libata.h| 29 +++-
8 files changed, 419 insertions(+), 173 deletions(-)
Mark Lord (1):
sata_mv: improve warnings about Highpoint RocketRAID 23xx cards
Tejun Heo (15):
sata_sil: fix spurious IRQ handling
libata: clear link->eh_info.serror from ata_std_postreset()
libata: add ST3160023AS / 3.42 to NCQ blacklist
libata-acpi: adjust constness in ata_acpi_gtm/stm() parameters
libata: update ata_*_printk() macros such that level can be a variable
libata: add more opcodes to ata.h
libata: ata_dev_disable() should be called from EH context
libata-acpi: add new hooks ata_acpi_dissociate() and ata_acpi_on_disable()
libata-acpi: implement and use ata_acpi_init_gtm()
libata-acpi: implement dev->gtf_cache and evaluate _GTF right after _STM
during resume
libata-acpi: improve ACPI disabling
libata-acpi: improve _GTF execution error handling and reporting
libata-acpi: implement _GTF command filtering
libata: update atapi_eh_request_sense() such that lbam/lbah contains
buffer size
libata: fix ATAPI draining
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 545ea86..7bf4bef 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -6,6 +6,7 @@
* Copyright (C) 2006 Randy Dunlap
*/
+#include
#include
#include
#include
@@ -25,6 +26,18 @@
#include
#include
+enum {
+ ATA_ACPI_FILTER_SETXFER = 1 << 0,
+ ATA_ACPI_FILTER_LOCK= 1 << 1,
+
+ ATA_ACPI_FILTER_DEFAULT = ATA_ACPI_FILTER_SETXFER |
+ ATA_ACPI_FILTER_LOCK,
+};
+
+static unsigned int ata_acpi_gtf_filter = ATA_ACPI_FILTER_DEFAULT;
+module_param_named(acpi_gtf_filter, ata_acpi_gtf_filter, int, 0644);
+MODULE_PARM_DESC(acpi_gtf_filter, "filter mask for ACPI _GTF commands, set to
filter out (0x1=set xfermode, 0x2=lock/freeze lock)");
+
#define NO_PORT_MULT 0x
#define SATA_ADR(root, pmp)(((root) << 16) | (pmp))
@@ -41,6 +54,12 @@ static int is_pci_dev(struct device *dev)
return (dev->bus == &pci_bus_type);
}
+static void ata_acpi_clear_gtf(struct ata_device *dev)
+{
+ kfree(dev->gtf_cache);
+ dev->gtf_cache = NULL;
+}
+
/**
* ata_acpi_associate_sata_port - associate SATA port with ACPI objects
* @ap: target SATA port
@@ -94,6 +113,9 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
dev->acpi_handle = acpi_get_child(ap->acpi_handle, i);
}
+
+ if (ata_acpi_gtm(ap, &ap->__acpi_init_gtm) == 0)
+ ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
}
static void ata_acpi_handle_hotplug(struct ata_port *ap, struct kobject *kobj,
@@ -188,6 +210,32 @@ void ata_acpi_associate(struct ata_host *host)
}
/**
+ * ata_acpi_dissociate - dissociate ATA host from ACPI objects
+ * @host: target ATA host
+ *
+ * This function is called during driver detach after the whole host
+ * is shut down.
+ *
+ * LOCKING:
+ * EH context.
+ */
+void ata_acpi_dissociate(struct ata_host *host)
+{
+ int i;
+
+ /* Restore initial _GTM values so that driver which attaches
+* afterward can use them too.
+*/
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+ const struct ata_acpi_gtm *gtm = ata_acpi_init_gtm(ap);
+
+ if (ap->acpi_handle && gtm)
+ ata_acpi_stm(ap, gtm);
+ }
+}
+
+/**
* ata_acpi_gtm - execute _GTM
* @ap: target ATA port
* @gtm: out parameter for _GTM result
@@ -200,7 +248,7 @@ void ata_acpi_associate(struct ata_host *host)
* RETURNS:
* 0 on success, -ENOENT if _GTM doesn't exist, -errno on failure.
*/
-int ata_acpi_gtm(const struct ata_port *ap, struct ata_acpi_gtm *gtm)
+int ata_acpi_gtm(struct ata_port *ap, struct ata_acpi_gtm *gtm)
{
struct acpi_buffer output = { .length = ACPI_ALLOCATE_BUFFER };
union acpi_object *out_obj;
@@ -259,15 +307,16 @@ EXPORT_SYMBOL_GPL(ata_acpi_gtm);
* RETURNS:
* 0 o
[patch 3/3]pci: avoid save the same type of cap multiple times
Avoid adding the same type of cap multiple times, otherwise we will see dead
loop.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/pci.c
===
--- linux.orig/drivers/pci/pci.c2007-12-18 09:37:12.0 +0800
+++ linux/drivers/pci/pci.c 2007-12-18 09:41:26.0 +0800
@@ -551,6 +551,7 @@ static int pci_save_pcie_state(struct pc
int pos, i = 0;
struct pci_cap_saved_state *save_state;
u16 *cap;
+ int found = 0;
pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
if (pos <= 0)
@@ -559,6 +560,8 @@ static int pci_save_pcie_state(struct pc
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
if (!save_state)
save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4,
GFP_KERNEL);
+ else
+ found = 1;
if (!save_state) {
dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
return -ENOMEM;
@@ -570,7 +573,8 @@ static int pci_save_pcie_state(struct pc
pci_read_config_word(dev, pos + PCI_EXP_SLTCTL, &cap[i++]);
pci_read_config_word(dev, pos + PCI_EXP_RTCTL, &cap[i++]);
save_state->cap_nr = PCI_CAP_ID_EXP;
- pci_add_saved_cap(dev, save_state);
+ if (!found)
+ pci_add_saved_cap(dev, save_state);
return 0;
}
@@ -598,6 +602,7 @@ static int pci_save_pcix_state(struct pc
int pos, i = 0;
struct pci_cap_saved_state *save_state;
u16 *cap;
+ int found = 0;
pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
if (pos <= 0)
@@ -606,6 +611,8 @@ static int pci_save_pcix_state(struct pc
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
if (!save_state)
save_state = kzalloc(sizeof(*save_state) + sizeof(u16),
GFP_KERNEL);
+ else
+ found = 1;
if (!save_state) {
dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
return -ENOMEM;
@@ -614,7 +621,8 @@ static int pci_save_pcix_state(struct pc
pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
save_state->cap_nr = PCI_CAP_ID_PCIX;
- pci_add_saved_cap(dev, save_state);
+ if (!found)
+ pci_add_saved_cap(dev, save_state);
return 0;
}
--
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/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Quoting Tetsuo Handa ([EMAIL PROTECTED]): > > Hello. > > > > Serge E. Hallyn wrote: > > > CAP_MKNOD will be removed from its capability > > I think it is not enough because the root can rename/unlink device files > > (mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2). > > Sure but that doesn't bother us :) > > The admin in the container has his own /dev directory and can do what he > likes with the devices he's allowed to have. He just shouldn't have > access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's > his choice. > > > > To use your approach, i guess we would have to use selinux (or tomoyo) > > > to enforce that devices may only be created under /dev? > > Everyone can use this filesystem alone. > > Sure but it is worthless alone. > > No? Oh, no, I'm sorry - I was thinking in terms of my requirements again. But your requirements are to ensure that an application accessing a device at a well-known location get what it expect. So then the main quesiton is still the one I think Al had asked - what keeps a rogue CAP_SYS_MOUNT process from doing mount --bind /dev/hda1 /dev/null ? thanks, -serge > What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? > > > But use with MAC (or whatever access control mechanisms that prevent > > attackers from unmounting/overlaying this filesystem) is recomennded. > > -serge -- 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/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Well, I guess it would be a smooth path if we rename the drivers/i2c/chips/pca9539.c since that's old style I2C driver, which means the driver name is not so useful external so the impact is actually minimum. On Dec 18, 2007 4:29 AM, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi David, > > > On Mon, 17 Dec 2007 10:09:53 -0800, David Brownell wrote: > > > Date: Mon, 17 Dec 2007 14:33:27 +0800 > > > From: "eric miao" <[EMAIL PROTECTED]> > > > > > > for the following reasons: > > > > > > 1. there is currently no known users of this driver > > > > > > 2. the functionality of this driver is well supported with the recent > > >proposed drivers/gpio/pca9539.c, using GPIO_LIB > > > > > > Signed-off-by: eric miao <[EMAIL PROTECTED]> > > > Acked-by: Ben Gardner <[EMAIL PROTECTED]> > > > --- > > > Documentation/i2c/chips/pca9539 | 47 > > > drivers/i2c/chips/Kconfig | 10 -- > > > drivers/i2c/chips/Makefile |1 - > > > drivers/i2c/chips/pca9539.c | 196 -- > > > > Jean, do you sign off on this? In any case I think this should > > be going through your I2C patches. > > > > I'd be a trifle uneasy just deleting this, because it's possible > > there are *unknown* users ... and also because nobody's yet done > > a userspace interface to the gpiolib infrastructure. (It seems > > to be the usual case of nobody wanting such a thing quite enough > > to write the code.) > > > > I'd be more comfortable marking it as obsolete and flagging it > > for removal a release or two after Eric's new version merges ... > > though maybe that's just paranoia. > > I'm fine with this and I agree that it would be safer, however please > note that both drivers are mutually exclusive because they have the > same name, meaning that deprecating the old driver is not enough, you > also need Kconfig magic to make sure that both drivers aren't built at > the same time. Or alternatively the old driver could be renamed... I > don't really care myself, I'll take whatever patch you or Eric submit. > > -- > Jean Delvare > -- Cheers - eric -- 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/
[PATCH 19/21] [PATCH] unify asm nops
There's only one difference between the NOPs used in asm code for i386 and x86_64: i386 has a lot more variants. The code is moved to processor.h, and adjusted accordingly. Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- include/asm-x86/processor.h| 85 include/asm-x86/processor_32.h | 85 include/asm-x86/processor_64.h | 44 3 files changed, 85 insertions(+), 129 deletions(-) Index: linux-2.6-x86/include/asm-x86/processor.h === --- linux-2.6-x86.orig/include/asm-x86/processor.h +++ linux-2.6-x86/include/asm-x86/processor.h @@ -588,6 +588,91 @@ extern int bootloader_type; extern char ignore_fpu_irq; #define cache_line_size() (boot_cpu_data.x86_cache_alignment) +/* generic versions from gas */ +#define GENERIC_NOP1 ".byte 0x90\n" +#define GENERIC_NOP2 ".byte 0x89,0xf6\n" +#define GENERIC_NOP3".byte 0x8d,0x76,0x00\n" +#define GENERIC_NOP4".byte 0x8d,0x74,0x26,0x00\n" +#define GENERIC_NOP5GENERIC_NOP1 GENERIC_NOP4 +#define GENERIC_NOP6 ".byte 0x8d,0xb6,0x00,0x00,0x00,0x00\n" +#define GENERIC_NOP7 ".byte 0x8d,0xb4,0x26,0x00,0x00,0x00,0x00\n" +#define GENERIC_NOP8 GENERIC_NOP1 GENERIC_NOP7 + +/* Opteron nops */ +#define K8_NOP1 GENERIC_NOP1 +#define K8_NOP2".byte 0x66,0x90\n" +#define K8_NOP3".byte 0x66,0x66,0x90\n" +#define K8_NOP4".byte 0x66,0x66,0x66,0x90\n" +#define K8_NOP5K8_NOP3 K8_NOP2 +#define K8_NOP6K8_NOP3 K8_NOP3 +#define K8_NOP7K8_NOP4 K8_NOP3 +#define K8_NOP8K8_NOP4 K8_NOP4 + +/* K7 nops */ +/* uses eax dependencies (arbitary choice) */ +#define K7_NOP1 GENERIC_NOP1 +#define K7_NOP2".byte 0x8b,0xc0\n" +#define K7_NOP3".byte 0x8d,0x04,0x20\n" +#define K7_NOP4".byte 0x8d,0x44,0x20,0x00\n" +#define K7_NOP5K7_NOP4 ASM_NOP1 +#define K7_NOP6".byte 0x8d,0x80,0,0,0,0\n" +#define K7_NOP7".byte 0x8D,0x04,0x05,0,0,0,0\n" +#define K7_NOP8K7_NOP7 ASM_NOP1 + +/* P6 nops */ +/* uses eax dependencies (Intel-recommended choice) */ +#define P6_NOP1GENERIC_NOP1 +#define P6_NOP2".byte 0x66,0x90\n" +#define P6_NOP3".byte 0x0f,0x1f,0x00\n" +#define P6_NOP4".byte 0x0f,0x1f,0x40,0\n" +#define P6_NOP5".byte 0x0f,0x1f,0x44,0x00,0\n" +#define P6_NOP6".byte 0x66,0x0f,0x1f,0x44,0x00,0\n" +#define P6_NOP7".byte 0x0f,0x1f,0x80,0,0,0,0\n" +#define P6_NOP8".byte 0x0f,0x1f,0x84,0x00,0,0,0,0\n" + +#ifdef CONFIG_MK7 +#define ASM_NOP1 K7_NOP1 +#define ASM_NOP2 K7_NOP2 +#define ASM_NOP3 K7_NOP3 +#define ASM_NOP4 K7_NOP4 +#define ASM_NOP5 K7_NOP5 +#define ASM_NOP6 K7_NOP6 +#define ASM_NOP7 K7_NOP7 +#define ASM_NOP8 K7_NOP8 +#elif defined(CONFIG_M686) || defined(CONFIG_MPENTIUMII) || \ + defined(CONFIG_MPENTIUMIII) || defined(CONFIG_MPENTIUMM) || \ + defined(CONFIG_MCORE2) || defined(CONFIG_PENTIUM4) || \ + defined(CONFIG_MPSC) +#define ASM_NOP1 P6_NOP1 +#define ASM_NOP2 P6_NOP2 +#define ASM_NOP3 P6_NOP3 +#define ASM_NOP4 P6_NOP4 +#define ASM_NOP5 P6_NOP5 +#define ASM_NOP6 P6_NOP6 +#define ASM_NOP7 P6_NOP7 +#define ASM_NOP8 P6_NOP8 +#elif defined(CONFIG_MK8) || defined(CONFIG_X86_64) +#define ASM_NOP1 K8_NOP1 +#define ASM_NOP2 K8_NOP2 +#define ASM_NOP3 K8_NOP3 +#define ASM_NOP4 K8_NOP4 +#define ASM_NOP5 K8_NOP5 +#define ASM_NOP6 K8_NOP6 +#define ASM_NOP7 K8_NOP7 +#define ASM_NOP8 K8_NOP8 +#else +#define ASM_NOP1 GENERIC_NOP1 +#define ASM_NOP2 GENERIC_NOP2 +#define ASM_NOP3 GENERIC_NOP3 +#define ASM_NOP4 GENERIC_NOP4 +#define ASM_NOP5 GENERIC_NOP5 +#define ASM_NOP6 GENERIC_NOP6 +#define ASM_NOP7 GENERIC_NOP7 +#define ASM_NOP8 GENERIC_NOP8 +#endif + +#define ASM_NOP_MAX 8 + #define HAVE_ARCH_PICK_MMAP_LAYOUT 1 #define ARCH_HAS_PREFETCHW #define ARCH_HAS_SPINLOCK_PREFETCH Index: linux-2.6-x86/include/asm-x86/processor_32.h === --- linux-2.6-x86.orig/include/asm-x86/processor_32.h +++ linux-2.6-x86/include/asm-x86/processor_32.h @@ -18,7 +18,6 @@ #include #include - /* * the following now lives in the per cpu area: * extern int cpu_llc_id[NR_CPUS]; @@ -144,88 +143,4 @@ extern unsigned long thread_saved_pc(str #define KSTK_ESP(task) (task_pt_regs(task)->sp) -/* generic versions from gas */ -#define GENERIC_NOP1 ".byte 0x90\n" -#define GENERIC_NOP2 ".byte 0x89,0xf6\n" -#define GENERIC_NOP3".byte 0x8d,0x76,0x00\n" -#define GENERIC_NOP4".byte 0x8d,0x74,0x26,0x00\n" -#define GENERIC_NOP5GENERIC_NOP1 GENERIC_NOP4 -#define GENERIC_NOP6 ".byte 0x8d,0xb6,0x00,0x00,0x00,0x00\n" -#define GENERIC_NOP7 ".byte 0x8d,0xb4,0x26,0x00,0x00,0x00,0x00\n" -#define GENERIC_NOP8 GENERIC_NOP1 GENERIC_NOP7 - -/* Opteron nops */ -#define K8_NOP1 GENERIC_NOP1 -#define K8_NOP2".byte 0x66,0x90\n" -#define K
Re: swapping in 2.6.24-rc5-git3
On Tue, 18 Dec 2007 10:38:13 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > > Is there a way to avoid it except turning off the swap? > > > Maybe...no. > Ah, sorry. If too much dirty page by ftp is trouble, tuning /proc/sys/vm/dirty_ratio /proc/sys/vm/dirty_writeback/centisecs etc.. may work for you. Thanks, -Kame -- 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/
