public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Greg KH" <greg@kroah.com>
To: "Bryan O'Sullivan" <bos@pathscale.com>
Cc: <linux-kernel@vger.kernel.org>, <openib-general@openib.org>
Subject: Re: [PATCH 12 of 20] ipath - misc driver support code
Date: Fri, 30 Dec 2005 00:25:05 -0800	[thread overview]
Message-ID: <20051230082505.GC7438@kroah.com> (raw)
In-Reply-To: <5e9b0b7876e2d570f25e.1135816291@eng-12.pathscale.com>

On Wed, Dec 28, 2005 at 04:31:31PM -0800, Bryan O'Sullivan wrote:
> Signed-off-by: Bryan O'Sullivan <bos@pathscale.com>

No description of what the patch does?

> +struct _infinipath_do_not_use_kernel_regs {
> +	unsigned long long Revision;

u64?

> +	unsigned long long Control;
> +	unsigned long long PageAlign;
> +	unsigned long long PortCnt;

And what's with the InterCapsNamingScheme of these variables?

> +/*
> + * would prefer to not inline this, to avoid code bloat, and simplify debugging
> + * But when compiling against 2.6.10 kernel tree, it gets an error, so
> + * not for now.
> + */
> +static void ipath_i2c_delay(ipath_type, int);

You aren't compiling this for a 2.6.10 kernel anymore :)

> +/*
> + * we use this instead of udelay directly, so we can make sure
> + * that previous register writes have been flushed all the way
> + * to the chip.  Since we are delaying anyway, the cost doesn't
> + * hurt, and makes the bit twiddling more regular
> + * If delay is negative, we'll do the chip read, to be sure write made it
> + * to our chip, but won't do udelay()
> + */
> +static void ipath_i2c_delay(ipath_type dev, int dtime)
> +{
> +	/*
> +	 * This needs to be volatile, so that the compiler doesn't
> +	 * optimize away the read to the device's mapped memory.
> +	 */
> +	volatile uint32_t read_val;
> +	if (!dtime)
> +		return;
> +	read_val = ipath_kget_kreg32(dev, kr_scratch);
> +	if (--dtime > 0)	/* register read takes about .5 usec, itself */
> +		udelay(dtime);
> +}

Huh?  After reading your comment, I still don't understand why you can't
just use udelay().  Or are you counting on calling this function with
only "1" being set for dtime?

Ah, in looking at your code, that is exactly what is happening.  That's
a mess, just delay and everything will work properly on the next rev of
the hardware where the time to read that register will have dropped to
1/8 the time it does today...

> +/*
> + * write a byte, one bit at a time.  Returns 0 if we got the following
> + * ack, otherwise 1
> + */
> +static int ipath_wr_byte(ipath_type dev, uint8_t data)
> +{
> +	int bit_cntr;
> +	uint8_t bit;
> +
> +	for (bit_cntr = 7; bit_cntr >= 0; bit_cntr--) {
> +		bit = (data >> bit_cntr) & 1;
> +		ipath_sda_out(dev, bit, 1);
> +		ipath_scl_out(dev, i2c_line_high, 1);
> +		ipath_scl_out(dev, i2c_line_low, 1);
> +	}
> +	if (!ipath_i2c_ackrcv(dev))
> +		return 1;
> +	return 0;
> +}

Ah, isn't it fun to write bit-banging functions...  And the in-kernel
i2c code is messier than doing this by hand?

> +/*
> + *      ipath_eeprom_read - Receives x # byte from the eeprom via I2C.
> + *
> + *  eeprom: Atmel AT24C01
> + *
> + */
> +
> +int ipath_eeprom_read(ipath_type dev, uint8_t eeprom_offset, void *buffer,
> +		      int len)

Odd function comment style.  Please fix this to be in kerneldoc format.

> diff -r e8af3873b0d9 -r 5e9b0b7876e2 drivers/infiniband/hw/ipath/ipath_lib.c
> --- /dev/null	Thu Jan  1 00:00:00 1970 +0000
> +++ b/drivers/infiniband/hw/ipath/ipath_lib.c	Wed Dec 28 14:19:43 2005 -0800
> @@ -0,0 +1,90 @@
> +/*
> + * Copyright (c) 2003, 2004, 2005, 2006 PathScale, Inc. All rights reserved.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + *     Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *      - Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *
> + *      - Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + *
> + * Patent licenses, if any, provided herein do not apply to
> + * combinations of this program with other software, or any other
> + * product whatsoever.
> + */
> +
> +/*
> + * This is library code for the driver, similar to what's in libinfinipath for
> + * usermode code.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/version.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/types.h>
> +#include <linux/string.h>
> +#include <linux/delay.h>
> +#include <linux/timer.h>
> +#include <linux/fs.h>
> +#include <linux/poll.h>
> +#include <asm/io.h>
> +#include <asm/byteorder.h>
> +#include <asm/uaccess.h>

Are you _sure_ you need all of these for the one function in this file?

> +
> +#include "ipath_kernel.h"
> +
> +unsigned infinipath_debug = __IPATH_INFO;
> +
> +uint32_t _ipath_pico_per_cycle;	/* always present, for now */
> +
> +/*
> + * This isn't perfect, but it's close enough for timing work. We want this
> + * to work on systems where the cycle counter isn't the same as the clock
> + * frequency.  The one msec spin is OK, since we execute this only once
> + * when first loaded.  We don't use CURRENT_TIME because on some systems
> + * it only has jiffy resolution; we just assume udelay is well calibrated
> + * and that we aren't likely to be rescheduled.  Do it multiple times,
> + * with a yield in between, to try to make sure we get the "true minimum"
> + * value.
> + * _ipath_pico_per_cycle isn't going to lead to completely accurate
> + * conversions from timestamps to nanoseconds, but it's close enough
> + * for our purposes, which is mainly to allow people to show events with
> + * nsecs or usecs if desired, rather than cycles.
> + */
> +void ipath_init_picotime(void)
> +{
> +	int i;
> +	u_int64_t ts, te, delta = -1ULL;
> +
> +	for (i = 0; i < 5; i++) {
> +		ts = get_cycles();
> +		udelay(250);
> +		te = get_cycles();
> +		if ((te - ts) < delta)
> +			delta = te - ts;
> +		yield();
> +	}
> +	_ipath_pico_per_cycle = 250000000 / delta;
> +}

Ick.  A whole file for one function and 2 public variables?  And a
horrible timing function too?  Please just use the core kernel timing
functions, which will work all the time on all arches...


> diff -r e8af3873b0d9 -r 5e9b0b7876e2 drivers/infiniband/hw/ipath/ipath_upages.c
> --- /dev/null	Thu Jan  1 00:00:00 1970 +0000
> +++ b/drivers/infiniband/hw/ipath/ipath_upages.c	Wed Dec 28 14:19:43 2005 -0800
> @@ -0,0 +1,144 @@
> +/*
> + * Copyright (c) 2003, 2004, 2005, 2006 PathScale, Inc. All rights reserved.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + *     Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *      - Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *
> + *      - Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + *
> + * Patent licenses, if any, provided herein do not apply to
> + * combinations of this program with other software, or any other
> + * product whatsoever.
> + */
> +
> +#include <stddef.h>

Where is this file being pulled in from?

> +
> +#include <linux/config.h>
> +#include <linux/version.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/string.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/mm.h>
> +#include <linux/spinlock.h>
> +
> +#include <asm/page.h>
> +#include <asm/io.h>
> +
> +#include "ipath_kernel.h"
> +
> +/*
> + * Our version of the kernel mlock function.  This function is no longer
> + * exposed, so we need to do it ourselves.

Woah, um, don't you think that you should either export the main mlock
function itself, or fix your code to not need it?  Rolling it yourself
isn't a good idea...

thanks,

greg k-h

  reply	other threads:[~2005-12-30 17:55 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-29  0:31 [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 1 of 20] Introduce __memcpy_toio32 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 2 of 20] memcpy32 for x86_64 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 3 of 20] Add memcpy_toio32 to each arch Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 4 of 20] Define BITS_PER_BYTE Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 5 of 20] ipath - driver core header files Bryan O'Sullivan
2005-12-29  8:18   ` Pekka Enberg
2005-12-29 14:15     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 6 of 20] ipath - driver debugging headers Bryan O'Sullivan
2005-12-29  8:22   ` Pekka Enberg
2005-12-29  0:31 ` [PATCH 7 of 20] ipath - MMIO copy routines Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 8 of 20] ipath - core driver, part 1 of 4 Bryan O'Sullivan
2005-12-30  8:39   ` Greg KH
2005-12-30 23:47     ` Bryan O'Sullivan
2005-12-31  0:12       ` Greg KH
2005-12-29  0:31 ` [PATCH 9 of 20] ipath - core driver, part 2 " Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 10 of 20] ipath - core driver, part 3 " Bryan O'Sullivan
2005-12-30 18:46   ` Linus Torvalds
2005-12-30 23:50     ` Bryan O'Sullivan
2005-12-31  8:36       ` Arjan van de Ven
2005-12-29  0:31 ` [PATCH 11 of 20] ipath - core driver, part 4 " Bryan O'Sullivan
2005-12-29  2:19   ` [openib-general] " Roland Dreier
2005-12-29 14:21     ` Bryan O'Sullivan
2005-12-30  8:12   ` Greg KH
2005-12-30 23:17     ` Bryan O'Sullivan
2005-12-31  0:08       ` Greg KH
2005-12-29  0:31 ` [PATCH 12 of 20] ipath - misc driver support code Bryan O'Sullivan
2005-12-30  8:25   ` Greg KH [this message]
2005-12-30 23:10     ` Bryan O'Sullivan
2005-12-31  0:13       ` Greg KH
2005-12-30 18:15   ` Arjan van de Ven
2005-12-29  0:31 ` [PATCH 13 of 20] ipath - routines used by upper layer driver code Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 14 of 20] ipath - infiniband verbs header Bryan O'Sullivan
2005-12-29  8:21   ` Pekka Enberg
2005-12-29 14:22     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 15 of 20] ipath - infiniband verbs support, part 1 of 3 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 16 of 20] path - infiniband verbs support, part 2 " Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 17 of 20] ipath - infiniband verbs support, part 3 " Bryan O'Sullivan
2005-12-29 19:24   ` Pekka Enberg
2005-12-30  3:19     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 18 of 20] ipath - infiniband management datagram support Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 19 of 20] ipath - kbuild infrastructure Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 20 of 20] ipath - integrate driver into infiniband " Bryan O'Sullivan
2005-12-29 19:01 ` [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Horst von Brand
2005-12-29 19:26   ` Lee Revell
2005-12-31  5:36     ` Jan Engelhardt
2006-01-02 16:05     ` Horst von Brand
2006-01-02 16:22       ` Christoph Hellwig
2005-12-30  3:17   ` Bryan O'Sullivan
2005-12-30  8:00 ` Greg KH
2005-12-30 23:11   ` Bryan O'Sullivan
2005-12-31  0:10     ` Greg KH
2005-12-31  1:40       ` Bryan O'Sullivan
2006-01-02 20:35         ` Eric W. Biederman
2006-01-02 22:22           ` Bryan O'Sullivan
2006-01-04 21:26           ` Roland Dreier
2006-01-05 15:28             ` Bryan O'Sullivan
2006-01-03 17:27         ` Greg KH
2006-01-03 20:54           ` Bryan O'Sullivan
2006-01-03 20:57             ` Arjan van de Ven
2006-01-03 21:24               ` Bryan O'Sullivan
2006-01-03 21:26                 ` Arjan van de Ven
2006-01-04  3:33                   ` Bryan O'Sullivan
2006-01-04 21:28             ` [openib-general] " Roland Dreier
2006-01-05 15:31               ` Bryan O'Sullivan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051230082505.GC7438@kroah.com \
    --to=greg@kroah.com \
    --cc=bos@pathscale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openib-general@openib.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox