-stable review patch. If anyone has any objections, please let us know.
--
From: Roland Dreier <[EMAIL PROTECTED]>
When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context. However,
this leaves a window where a r
On Thu, Nov 09, 2006 at 10:43:25AM +0100, Segher Boessenkool wrote:
> >You don't have any TTL in the while loop below, neither in the while
> >loop in pci_find_next_ht_capability(). It's paranoid, but I'd rather
> >keep a TTL in both loops (a brain-damaged capability chain in the PCI
> >config spac
On Wed, Aug 23, 2006 at 04:25:38PM -0700, Roland Dreier wrote:
> Greg, please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> for-linus
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/
On Wed, Jul 26, 2006 at 07:32:26PM +0300, Michael S. Tsirkin wrote:
> Quoting r. Greg KH <[EMAIL PROTECTED]>:
> > I think pci_restore_state() already restores the msi and msix state,
> > take a look at the latest kernel version :)
>
> Yes, I know :)
> but I am not
On Wed, Jul 26, 2006 at 01:29:44PM +0300, Michael S. Tsirkin wrote:
> Quoting r. Greg KH <[EMAIL PROTECTED]>:
> > Subject: [patch 02/45] IB/mthca: restore missing PCI registers after reset
> > --
> > mthca does not restore the following PCI-X/PCI Express
-stable review patch. If anyone has any objections, please let us know.
--
mthca does not restore the following PCI-X/PCI Express registers after reset:
PCI-X device: PCI-X command register
PCI-X bridge: upstream and downstream split transaction registers
PCI Express : PCI E
On Tue, Apr 04, 2006 at 12:07:23PM -0600, Jason Gunthorpe wrote:
> +#ifdef CONFIG_PCI_MSI
No #ifdef is needed really, right?
> +static void __devinit fixup_ht_msi(struct pci_dev* dev)
> +{
> + /* Some BIOS's do not enable the hypertransport MSI mapping capability
> +on the chipset. Th
On Tue, Apr 04, 2006 at 05:07:20PM -0700, David S. Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Tue, 4 Apr 2006 17:00:30 -0700
>
> > From: Michael Tsirkin <[EMAIL PROTECTED]>
> >
> > struct neigh_ops currently has a destructor field, but not a constructor
> > field.
> > The infiniband/ulp/ipo
On Mon, Apr 03, 2006 at 06:47:41PM +0300, Michael S. Tsirkin wrote:
> Hello, -stable team!
> The following patch is a backport from 2.6.17-rc1: is solves an oops/crash
> condition in ipoib that people are observing in 2.6.16/2.6.16.1.
>
> The patch exceeds the 100 line limit slightly, but only bec
On Thu, Mar 23, 2006 at 12:44:45AM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-03-22 at 21:49 -0800, Greg KH wrote:
> > Oh, and I like your new filesystem, but where do you propose that it be
> > mounted?
>
> I don't have any good candidates in mind. In our d
On Wed, Mar 22, 2006 at 04:05:01PM -0800, Bryan O'Sullivan wrote:
> +int ipath_driver_create_group(struct device_driver *drv)
> +{
> + int ret;
> +
> + if (!drv->kobj.dentry) {
> + ret = -ENODEV;
> + goto bail;
> + }
> +
> + ret = sysfs_create_group(&drv->kob
On Fri, Mar 10, 2006 at 05:43:50AM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 21:55 -0800, Roland Dreier wrote:
>
> > No, the only problems are with the way the various pieces of your
> > drivers refer to devices by index.
>
> OK. What's a safe way to iterate over the devices in the
On Fri, Mar 10, 2006 at 10:08:10AM -0500, Hal Rosenstock wrote:
> On Fri, 2006-03-10 at 09:59, Roland Dreier wrote:
> > Greg> The main issue is that if you create a sysfs file like this,
> > Greg> and then in 3 months realize that you need to change one of
> > Greg> those characters to
On Fri, Mar 10, 2006 at 11:25:52AM -0500, Dave Jones wrote:
> On Fri, Mar 10, 2006 at 07:55:21AM -0800, Bryan O'Sullivan wrote:
>
> > If Greg can get SUSE to turn on debugfs, that's great. I can ask Dave
> > Jones or Doug Ledford or some other Fedora/RedHat kernel person to do
> > likewise, bu
On Thu, Mar 09, 2006 at 08:58:13PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 17:00 -0800, Greg KH wrote:
>
> > They are in the latest -mm tree if you wish to use them. Unfortunatly
> > it might look like they will not work out, due to the per-cpu relay
> &g
On Thu, Mar 09, 2006 at 09:09:37PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 17:11 -0800, Greg KH wrote:
>
> > These two files sure do show a lot of different stuff, all in a
> > predefined structure for a single file. Please break them up into the
> &g
On Thu, Mar 09, 2006 at 08:41:36PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 17:04 -0800, Greg KH wrote:
>
> > > I don't expect this to be a practical problem. We're planning to add
> > > hotplug support to the driver once we have some cyc
On Thu, Mar 09, 2006 at 04:35:38PM -0800, Bryan O'Sullivan wrote:
> +static ssize_t show_node_info(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + static const size_t count = 10;
> + struct ipath_devdata *d
On Thu, Mar 09, 2006 at 04:48:45PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 16:45 -0800, Greg KH wrote:
>
> > > We don't support hotplugged devices at the moment.
> >
> > Why not? Your cards can't be placed in a machine that supports P
On Thu, Mar 09, 2006 at 03:59:37PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 15:46 -0800, Greg KH wrote:
> > On Thu, Mar 09, 2006 at 03:18:49PM -0800, Roland Dreier wrote:
> >
> > Thanks for CC:ing me, but where were the originals of these posted?
>
>
On Thu, Mar 09, 2006 at 04:46:29PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 16:35 -0800, Greg KH wrote:
>
> > Grumble? Oh come on, don't export binary structures through sysfs, it's
> > in the DOCUMENTATION THAT SYSFS IS FOR TEXT FILES ONLY
&
On Thu, Mar 09, 2006 at 03:52:47PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 15:26 -0800, Roland Dreier wrote:
>
> > Similarly what protects against another process opening the device
> > right after the ipath_sma_alive = 0 setting, but before you do all the
> > cleanup that's after t
On Thu, Mar 09, 2006 at 03:32:23PM -0800, Bryan O'Sullivan wrote:
> On Thu, 2006-03-09 at 15:18 -0800, Roland Dreier wrote:
> > > +static ssize_t show_atomic_stats(struct device_driver *dev, char *buf)
> > > +{
> > > +memcpy(buf, &ipath_stats, sizeof(ipath_stats));
> > > +
> > > +
On Thu, Mar 09, 2006 at 03:18:49PM -0800, Roland Dreier wrote:
Thanks for CC:ing me, but where were the originals of these posted?
> > +static ssize_t show_version(struct device_driver *dev, char *buf)
> > +{
> > + return scnprintf(buf, PAGE_SIZE, "%s", ipath_core_version);
> > +}
>
> Any r
On Sat, Feb 18, 2006 at 01:31:52PM -0800, Roland Dreier wrote:
> Greg> Sorry, I didn't mean to say "private", but rather,
> Greg> "seperate". Doing kernel development in a seperate
> Greg> development tree from the mainline kernel is very
> Greg> problematic, as has been documented
On Sat, Feb 18, 2006 at 10:52:58AM -0800, Roland Dreier wrote:
> Greg> Checking stuff into a private svn tree is vastly different
> Greg> from posting to lkml in public. In fact, it looks like the
> Greg> svn tree is so far ahead of the in-kernel stuff, that most
> Greg> people are
On Sat, Feb 18, 2006 at 08:32:28AM -0800, Roland Dreier wrote:
> Arjan> The bigger issue is: if people can't be bothered to do
> Arjan> those steps, why would they be bothered to do this for
> Arjan> maintenance and bugfixes etc etc? Basically it's now
> Arjan> already a de-facto u
On Fri, Feb 17, 2006 at 04:57:07PM -0800, Roland Dreier wrote:
> From: Roland Dreier <[EMAIL PROTECTED]>
>
> This is a very large file with way too much code for a .h file.
> The functions look too big to be inlined also. Is there any way
> for this code to move to a .c file?
Roland, your commen
On Fri, Feb 17, 2006 at 04:57:14PM -0800, Roland Dreier wrote:
> +int hipz_count_adapters(void)
> +{
> + int num = 0;
> + struct device_node *dn = NULL;
> +
> + EDEB_EN(7, "");
> +
> + while ((dn = of_find_node_by_name(dn, "lhca"))) {
> + num++;
> + }
The { } are no
On Fri, Jan 20, 2006 at 04:28:39PM -0800, Sean Hefty wrote:
> Greg KH wrote:
> >If you want, I can forward this on to Linus in my driver tree, or you
> >can send it yourselves.
>
> Thanks, Greg. Please go ahead and forward this patch.
Great, will do, thanks.
Care to give m
Here's a patch that will remove a few lines of code from the IB core,
and let it work properly with userspace programs that are only watching
the netlink socket for events, instead of mucking around in sysfs (like
the latest versions of udev do.)
I've only compile tested it as I have no IB hardwar
On Wed, Jan 18, 2006 at 09:53:08PM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-01-18 at 21:39 -0800, Greg KH wrote:
>
> > Ok, that's fair enough. But if you want to do something like ptys, then
> > why not just have your own filesystem for this driver?
>
>
On Wed, Jan 18, 2006 at 09:17:01PM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-01-18 at 17:17 -0800, David S. Miller wrote:
>
> > It's going to give you strict typing, and extensible attributes for
> > the configuration attributes you define. So if you determine later
> > "oh we need to add thi
On Wed, Jan 18, 2006 at 09:02:37PM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-01-18 at 18:57 -0800, Greg KH wrote:
>
> > Shouldn't you just open the proper chip device and port device itself?
> > That drops one ioctl.
>
> There isn't usually a "ri
On Wed, Jan 18, 2006 at 07:49:11PM -0800, Andrew Morton wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
> >
>
> Sorry for sticking my head in a beehive, but. Stand back and look at it:
>
> > Shouldn't you just open the proper chip device and port device itself?
On Wed, Jan 18, 2006 at 05:17:20PM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-01-18 at 16:53 -0800, Greg KH wrote:
>
> > Use the firmware subsystem for this. It uses sysfs so ioctl needed at
> > all.
>
> OK. Would I be correct in thinking that drivers/firmwa
On Wed, Jan 18, 2006 at 04:43:31PM -0800, Bryan O'Sullivan wrote:
> Opening the /dev/ipath special file assigns an appropriate free
> unit (chip) and port (context on a chip) to a user process.
Shouldn't you just open the proper chip device and port device itself?
That drops one io
On Wed, Jan 18, 2006 at 04:43:31PM -0800, Bryan O'Sullivan wrote:
> For EEPROM/flash management:
>
> READ_EEPROM reads the flash. WRITE_EEPROM writes it. I don't
> see a standard way of doing this in the kernel; many drivers
> provide their own private ioctls, some on ded
On Fri, Dec 30, 2005 at 05:40:50PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 16:10 -0800, Greg KH wrote:
>
> > But we (the kernel community), don't really accept that as a valid
> > reason to accept this kind of code, sorry.
>
> Fair enough. I
On Fri, Dec 30, 2005 at 03:47:07PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 00:39 -0800, Greg KH wrote:
>
> > > +void ipath_chip_done(void)
> > > +{
> > > +}
> > > +
> > > +void ipath_chip_cleanup(struct ipath_devdata *
On Fri, Dec 30, 2005 at 03:11:44PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 00:00 -0800, Greg KH wrote:
> > > - The driver still uses EXPORT_SYMBOL, for consistency with other
> > > code in drivers/infiniband
> >
> > Why would that mat
On Fri, Dec 30, 2005 at 03:17:55PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 00:12 -0800, Greg KH wrote:
> > And does your driver work with udev? I didn't see where you were
> > exporting the major:minor number of your devices to sysfs, but I might
> &
On Fri, Dec 30, 2005 at 03:10:09PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 00:25 -0800, Greg KH wrote:
> > > + unsigned long long Control;
> > > + unsigned long long PageAlign;
> > > + unsigned long long PortCnt;
> >
> > And what'
On Wed, Dec 28, 2005 at 04:31:27PM -0800, Bryan O'Sullivan wrote:
> Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
>
> diff -r ffbd416f30d4 -r ddd21709e12c
> drivers/infiniband/hw/ipath/ipath_driver.c
> --- /dev/null Thu Jan 1 00:00:00 1970 +
> +++ b/drivers/infiniband/hw/ipath/ipath_dr
On Wed, Dec 28, 2005 at 04:31:30PM -0800, Bryan O'Sullivan wrote:
> Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
>
> diff -r c37b118ef806 -r e8af3873b0d9
> drivers/infiniband/hw/ipath/ipath_driver.c
> --- a/drivers/infiniband/hw/ipath/ipath_driver.c Wed Dec 28 14:19:42
> 2005 -0800
>
On Wed, Dec 28, 2005 at 04:31:19PM -0800, Bryan O'Sullivan wrote:
>
> There are a few requested changes we have chosen to omit for now:
>
> - The driver still uses EXPORT_SYMBOL, for consistency with other
> code in drivers/infiniband
Why would that matter?
> - Someone asked for the ker
On Wed, Dec 28, 2005 at 04:31:31PM -0800, Bryan O'Sullivan wrote:
> Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
No description of what the patch does?
> +struct _infinipath_do_not_use_kernel_regs {
> + unsigned long long Revision;
u64?
> + unsigned long long Control;
> + uns
Please send these again to the stable@ address when they have been
accepted into upstream.
thanks,
greg k-h
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http:/
On Wed, Sep 28, 2005 at 06:44:55AM -0700, Roland Dreier wrote:
> Greg> I didn't think that git pulls were going to be allowed from
> Greg> subsystem maintainers after -rc1 came out. After that,
> Greg> patches by email were required to be sent, not git pulls.
> Greg> This does caus
On Tue, Sep 27, 2005 at 09:01:45PM -0700, Roland Dreier wrote:
> Linus, please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> for-linus
Hm, I complained about this last time, with no response...
I didn't think that git pulls were going to be allowed from s
On Fri, Aug 05, 2005 at 03:25:02PM -0700, yhlu wrote:
> In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
> mellanox Infiniband card. Some range above 4G. So the mmio below 4G
> is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
> used, the mmio will be 2G. For n
On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
>
> Hmm.. This looks half-way sane, but too ugly for words.
>
> I'd much rather see that when we detect a 64-bit resource, we always mark
> the next resource as being reserved some way, and then we just make
> pci_update_resource()
On Thu, Jul 28, 2005 at 12:57:51PM +0100, Ian Pratt wrote:
> > > Greg> Hm, you do realize that io_remap_pfn_range() is the same
> > > Greg> thing as remap_pfn_range() on i386, right?
> > >
> > > Greg> So, why would this patch change anything?
> > >
> > > It's not the same thing under
On Wed, Jul 27, 2005 at 09:20:08PM -0700, Roland Dreier wrote:
> Linus, please pull from
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
> for-linus
Not to be a pain, but didn't we say that we would only do email patches
after -rc1 comes out at the last kernel sum
On Thu, Jul 28, 2005 at 09:48:59AM +0300, Michael S. Tsirkin wrote:
> Quoting r. Greg KH <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
> >
> > On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote
On Wed, Jul 27, 2005 at 09:30:17PM -0700, Roland Dreier wrote:
> Greg> Hm, you do realize that io_remap_pfn_range() is the same
> Greg> thing as remap_pfn_range() on i386, right?
>
> Greg> So, why would this patch change anything?
>
> It's not the same thing under Xen. I think this p
On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote:
> Greg, Martin, does the following make sense?
> If it does, should other architectures be updated as well?
>
> ---
>
> Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range.
>
> Signed-off-by: Michael S. Tsirkin
gt;
> Here's a patch that applies on top of this patch set that fixes this:
>
>
> Greg KH pointed out that with the new class device code, we can just
> set class_dev.devt instead of having our own show_dev() function.
>
> Signed-off-by: Roland Dreier <[EMAIL PROTE
On Tue, Jun 28, 2005 at 11:13:22PM -0500, Troy Benjegerdes wrote:
> On Tue, Jun 28, 2005 at 05:27:09PM -0700, Greg KH wrote:
> > On Tue, Jun 28, 2005 at 04:03:43PM -0700, Roland Dreier wrote:
> > > +++ linux/drivers/infiniband/core/uverbs_main.c 2005-06-28
> > &g
On Tue, Jun 28, 2005 at 04:03:43PM -0700, Roland Dreier wrote:
> +++ linux/drivers/infiniband/core/uverbs_main.c 2005-06-28
> 15:20:04.363963991 -0700
> @@ -0,0 +1,708 @@
> +/*
> + * Copyright (c) 2005 Topspin Communications. All rights reserved.
> + * Copyright (c) 2005 Cisco Systems. All
On Sun, Apr 24, 2005 at 04:52:31PM -0500, Timur Tabi wrote:
> Greg KH wrote:
>
> >You don't "support" i386 or ia64 or x86-64 or ppc64 systems? What
> >hardware do you support?
>
> I've never seen or heard of any x86-32 or x86-64 system that support
On Sun, Apr 24, 2005 at 09:23:48AM -0500, Timur Tabi wrote:
> Andrew Morton wrote:
>
> >If your theory is correct then it should be able to demonstrate this
> >problem without any special hardware at all: pin some user memory, then
> >generate memory pressure then check the contents of those pinne
On Thu, Apr 21, 2005 at 03:07:42PM -0500, Timur Tabi wrote:
> >*You* need to come up with a solution that looks good to *the community*
> >if you want it merged.
>
> True, but I'm not going to waste my time adding this support if the
> consensus I get from the kernel developers that they don't
On Fri, Apr 01, 2005 at 02:06:50PM -0800, Roland Dreier wrote:
> Ugh, this patch is required to build support for the new Mellanox
> HCAs. Greg K-H applied it to his tree a while ago but it hasn't made
> it to Linus yet.
>
> Sorry,
> Roland
>
> Add PCI device IDs for new Mellanox MT25204 "Sina
On Sun, Mar 06, 2005 at 10:28:45PM +0200, Michael S. Tsirkin wrote:
> Greg, Martin,
>
> The AMD-8131 I/O APIC (device id 1022:7450/7451) does not support message
> signalled interrupts. Thus, if a device driver attempts to enable msi,
> it will suceed, but interrupts are not actually delivered to
On Tue, Mar 01, 2005 at 08:42:47AM -0800, Roland Dreier wrote:
> Hi Greg,
>
> It turns out that Mellanox decided to change the device ID at the last
> minute. So of course there will be parts with both IDs. Here's an
> updated patch that includes both IDs. Please use this instead.
Applied, tha
On Thu, Mar 03, 2005 at 05:02:36PM -0800, Roland Dreier wrote:
> Greg> Sure, I have no problem accepting that into the pci core.
>
> What would pci_irq_sync() do exactly?
Consolidate common code like this? :)
thanks,
greg k-h
___
openib-general m
On Thu, Mar 03, 2005 at 07:35:00PM -0500, Jeff Garzik wrote:
> Roland Dreier wrote:
> >@@ -783,6 +777,11 @@
> > cq->cqn & (dev->limits.num_cqs - 1));
> > spin_unlock_irq(&dev->cq_table.lock);
> >
> >+if (dev->mthca_flags & MTHCA_FLAG_MSI_X)
> >+ synchronize_irq(de
On Thu, Jan 20, 2005 at 09:35:59PM -0700, Ronald G. Minnich wrote:
> On Thu, 20 Jan 2005, Grant Grundler wrote:
> > I think you overlooked the fact that include/linux/rcupdate.h is
> > published under the GPL. Not "dual GPL/BSD". Someone can't take code
> > that uses linux's RCU and ship it under a
On Thu, Jan 20, 2005 at 10:02:24AM -0800, Sean Hefty wrote:
> Greg KH wrote:
>
> >Personally, I think it's a stupid thing to try to license this code in a
> >dual way, as any port someone is going to have to do to get this code to
> >work in another os will be almost
On Thu, Jan 20, 2005 at 06:02:36PM +0100, Adrian Bunk wrote:
> On Tue, Jan 18, 2005 at 11:06:19AM -0800, Roland Dreier wrote:
> > Michael> By the way, I was looking at using RCU to reduce locking,
> > Michael> also for thing like poll_cq. What do you say to that?
> >
> > Unless it's a dram
On Wed, Jan 12, 2005 at 05:01:43PM -0500, Dave Jones wrote:
> On Wed, Jan 12, 2005 at 01:41:08PM -0800, Greg KH wrote:
> > On Wed, Jan 12, 2005 at 04:09:45PM -0500, Dave Jones wrote:
> > > On Wed, Jan 12, 2005 at 12:50:51PM -0800, Roland Dreier wrote:
> > > > Hi
On Wed, Jan 12, 2005 at 04:09:45PM -0500, Dave Jones wrote:
> On Wed, Jan 12, 2005 at 12:50:51PM -0800, Roland Dreier wrote:
> > Hi Greg,
> >
> > Now that debugfs is merged into Linus's tree, I'm looking at using it
> > to replace the IPoIB debugging pseudo-filesystem (ipoib_debugfs). Is
> >
On Wed, Jan 12, 2005 at 12:50:51PM -0800, Roland Dreier wrote:
> Hi Greg,
>
> Now that debugfs is merged into Linus's tree, I'm looking at using it
> to replace the IPoIB debugging pseudo-filesystem (ipoib_debugfs).
Great!
> Is
> there any guidance on what the structure of debugfs should look li
On Tue, Nov 23, 2004 at 08:14:19AM -0800, Roland Dreier wrote:
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-bk/drivers/infiniband/core/cache.c 2004-11-23 08:10:16.816082837
> -0800
> @@ -0,0 +1,338 @@
> +/*
> + This software is available to you under a choice of one of two
> +
On Tue, Nov 23, 2004 at 07:06:07AM -0800, Roland Dreier wrote:
> Greg> Yes, it probably should be. Hm, no, we don't allow you to
> Greg> put class specific files if you use the class_simple API,
> Greg> sorry I misread your question. You can just handle the
> Greg> class yourself
On Mon, Nov 22, 2004 at 03:05:40PM -0800, Roland Dreier wrote:
> Greg> You are letting any user, with any privilege register or
> Greg> unregister an "agent"?
>
> They have to be able to open the device node. We could add a check
> that they have it open for writing but there's not really
On Mon, Nov 22, 2004 at 10:45:02PM -0800, Roland Dreier wrote:
> Greg> class_simple_device_add returns a pointer to a struct
> Greg> class_device * that you can then use to create a file in
> Greg> sysfs with. That should be what you're looking for.
>
> Shouldn't the ABI version be an
On Mon, Nov 22, 2004 at 10:51:10PM -0800, Johannes Erdfelt wrote:
>
> Is the eventual plan to move to dynamic majors for all devices?
No, some people will not allow that to happen, it would break too many
old programs and configurations.
It will probably be a config option if people wish to try
On Mon, Nov 22, 2004 at 10:47:29PM -0800, Roland Dreier wrote:
> Greg> Yeah, but a name in each file is much nicer.
>
> Very little of the kernel seems to follow this rule right now.
I agree, but it's good to add this for new files.
> Greg> One comment, the file drivers/infiniband/core/c
On Mon, Nov 22, 2004 at 03:30:47PM -0800, Johannes Erdfelt wrote:
> On Mon, Nov 22, 2004, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 22, 2004 at 02:58:45PM -0800, Roland Dreier wrote:
> > > Greg> Oh, have you asked for a real major number to be reserv
On Mon, Nov 22, 2004 at 03:34:23PM -0800, Roland Dreier wrote:
> Greg> No email address of who to bug with issues?
>
> There's a patch to MAINTAINERS...
Yeah, but a name in each file is much nicer.
> Greg> What is "RESERVED"? I must be missing a previous patch
> Greg> somewhere, I c
On Mon, Nov 22, 2004 at 06:08:21PM -0800, Roland Dreier wrote:
> Greg> This could be in a sysfs file, right?
>
> Ugh, how does one add an attribute (like the ABI version) to a
> class_simple? It shouldn't be per-device but I don't see anything
> like class_create_file() that could work for cl
On Mon, Nov 22, 2004 at 02:50:41PM -0800, Roland Dreier wrote:
> Greg> Who would be including these files, only drivers in
> Greg> drivers/infiniband? Or from files in other parts of the
> Greg> kernel?
>
> In the current patchset all the code is under drivers/infiniband.
Then it sho
On Mon, Nov 22, 2004 at 02:58:45PM -0800, Roland Dreier wrote:
> Greg> Why do you propose such a "deep" nesting of directories for
> Greg> umad devices? That's not the LANNANA way.
>
> No real reason, I'm open to better suggestions.
/dev/umad*
/dev/ib/umad*
> Greg> Oh, have you ask
On Mon, Nov 22, 2004 at 07:14:22AM -0800, Roland Dreier wrote:
> +/dev files
> +
> + To create the appropriate character device files automatically with
> + udev, a rule like
> +
> +KERNEL="umad*", NAME="infiniband/%s{ibdev}/ports/%s{port}/mad"
> +
> + can be used. This will create a device
On Mon, Nov 22, 2004 at 07:14:11AM -0800, Roland Dreier wrote:
> Add a driver that provides a character special device for each
> InfiniBand port. This device allows userspace to send and receive
> MADs via write() and read() (with some control operations implemented
> as ioctls).
Do you really n
On Mon, Nov 22, 2004 at 07:14:04AM -0800, Roland Dreier wrote:
>
> +#define ipoib_printk(level, priv, format, arg...)\
> + printk(level "%s: " format, ((struct ipoib_dev_priv *) priv)->dev->name
> , ## arg)
> +#define ipoib_warn(priv, format, arg...) \
> + ipoib_printk(KER
On Mon, Nov 22, 2004 at 07:13:24AM -0800, Roland Dreier wrote:
> organization of the code will be very much appreciated. For example,
> the current set of patches puts include files in driver/infiniband/include;
> would it be preferred to put include files in include/linux/infiniband/,
> directly
On Mon, Nov 22, 2004 at 07:13:48AM -0800, Roland Dreier wrote:
>
> Index: linux-bk/drivers/infiniband/core/Makefile
> ===
Please hack your submit script to not add these headers, when importing
to bk they end up showing up in the cha
On Fri, Oct 08, 2004 at 04:27:14PM -0700, Roland Dreier wrote:
> The increase in cost for the spec is rather unfortunate but I think
> it's orthogonal to any IP issues. Since the Linux kernel contains a
> lot of code written to specs available only under NDA (and even
> reverse-engineered code whe
On Fri, Oct 08, 2004 at 04:49:16PM -0600, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > [2] Sure, any person who has a copy of the kernel source tree could be a
> > target for any of a zillion other potential claims, nothing new there,
> >
Hi all,
Enough people have been asking me about this lately, that I thought I
would just bring it up publicly here.
It seems that the Infiniband group (IBTA) has changed their licensing
agrement of the basic Infiniband spec. See:
http://www.theinquirer.net/?article=18922
for more info ab
93 matches
Mail list logo
