public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Marcin Obara <marcin_obara@users.sourceforge.net>,
	linux-kernel@vger.kernel.org, pavel@suse.cz
Subject: Re: [PATCH] Intel Management Engine Interface
Date: Tue, 12 Aug 2008 18:15:24 +0200	[thread overview]
Message-ID: <48A1B71C.6080201@gmail.com> (raw)
In-Reply-To: <20080811215340.2c0635dd.akpm@linux-foundation.org>

On 08/12/2008 06:53 AM, Andrew Morton wrote:
> On Mon, 11 Aug 2008 21:23:01 +0200 (CEST)
> Marcin Obara <marcin_obara@users.sourceforge.net> wrote:
>> +/*
>> + * error code definition
>> + */
>> +#define     ESLOTS_OVERFLOW              1
>> +#define     ECORRUPTED_MESSAGE_HEADER    1000
>> +#define     ECOMPLETE_MESSAGE            1001
> 
> What's this?  The driver defines its onw errno numbers?
> 
> Are these ever returned to userspace?
> 
> This is risky/confusing/misleading, isn't it?

Yes and already pointed out. This leaks to userspace and it's wrong. Please go 
and read my comments to version #1 once again and if you don't understand 
anything, please drop a message, but do not silently ignore others' comments.

E.g. unlocked_ioctl switch hasn't been done plus other things mentioned below 
too (not all of them)

>> +static void host_init_wd(struct iamt_heci_device *dev)
>> +{
>> +	spin_lock_bh(&dev->device_lock);
>> +
>> +	heci_init_file_private(&dev->wd_file_ext, NULL);
>> +
>> +	/* look for WD client and connect to it */
>> +	dev->wd_file_ext.state = HECI_FILE_DISCONNECTED;
>> +	dev->wd_timeout = 0;
>> +
>> +	if (dev->asf_mode) {
>> +		memcpy(dev->wd_data, heci_stop_wd_params, HECI_WD_PARAMS_SIZE);
>> +	} else {
>> +		/* AMT mode */
>> +		dev->wd_timeout = AMT_WD_VALUE;
>> +		DBG("dev->wd_timeout=%d.\n", dev->wd_timeout);
>> +		memcpy(dev->wd_data, heci_start_wd_params, HECI_WD_PARAMS_SIZE);
>> +		memcpy(dev->wd_data + HECI_WD_PARAMS_SIZE,
>> +		       &dev->wd_timeout, sizeof(__u16));
>> +	}
>> +
>> +	/* find ME WD client */
>> +	heci_find_me_client(dev, &dev->wd_file_ext,
>> +			    &heci_wd_guid, HECI_WD_HOST_CLIENT_ID);
>> +	spin_unlock_bh(&dev->device_lock);
>> +
>> +	DBG("check wd_file_ext\n");
>> +	if (HECI_FILE_CONNECTING == dev->wd_file_ext.state) {
>> +		if (heci_connect_me_client(dev, &dev->wd_file_ext, 15) == 1) {
>> +			DBG("dev->wd_timeout=%d.\n", dev->wd_timeout);
>> +			if (dev->wd_timeout != 0)
>> +				dev->wd_due_counter = 1;
>> +			else
>> +				dev->wd_due_counter = 0;
>> +			DBG("successfully connected to WD client.\n");
>> +		}
>> +	} else
>> +		DBG("failed to find WD client.\n");
>> +
>> +
>> +	spin_lock_bh(&dev->device_lock);
>> +	dev->wd_timer.function = &heci_wd_timer;
>> +	dev->wd_timer.data = (unsigned long) dev;
>> +	spin_unlock_bh(&dev->device_lock);
> 
> Use setup_timer().
> 
> Note that setup_timer() does init_timer(), but we already have an
> init_timer(dev->wd_timer) elsewhere.  Please sort that out.

Already commented, left unchanged and without an explanation.

>> +/* IOCTL commands */
>> +#define IOCTL_HECI_GET_VERSION \
>> +    _IOWR('H' , 0x0, struct heci_message_data)
>> +#define IOCTL_HECI_CONNECT_CLIENT \
>> +    _IOWR('H' , 0x01, struct heci_message_data)
>> +#define IOCTL_HECI_WD \
>> +    _IOWR('H' , 0x02, struct heci_message_data)
>> +#define IOCTL_HECI_BYPASS_WD \
>> +    _IOWR('H' , 0x10, struct heci_message_data)
> 
> So this driver implements ioctls!
> 
> That is a core, top-level, userspace-visible design decision!  It
> should have been given prominent billing in the changelog description.
> 
> 
> These four values are supposed to be exported to userspace headers,
> yes?  But they're buried in a kernel-internal header and don't have the
> appropriate __KERNEL__ wrappers.

... and conflicts with hid as I commented before. Also ioctl-number.txt update 
should be done.

>> +	if (!dev->mem_addr) {
>> +		printk(KERN_ERR "heci: Remap IO device memory failure.\n");
>> +		err = -ENOMEM;
>> +		goto free_device;
>> +	}
>> +	/* request and enable interrupt   */
>> +	err = request_irq(pdev->irq, heci_isr_interrupt, IRQF_SHARED,
>> +			heci_driver_name, dev);
> 
> Doing request_irq() after pci_enable_device() is dengerous.  If the
> device happened to be requesting an interrupt when we did
> pci_enable_device(), things will generally go pear-shaped.

Hm, no, pci_enable_device sets up irq (i.e. even pdev->irq), this is correct 
sequence. Actually one should not touch pdev before enabling the device it's 
describing in most cases.

  reply	other threads:[~2008-08-12 16:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17 18:27 [PATCH] Intel Management Engine Interface Marcin Obara
2008-07-18  0:00 ` Randy Dunlap
2008-07-18  5:44 ` Marcin Obara
2008-07-18 17:39   ` Marcin Obara
2008-07-18 19:23     ` Marcin Obara
2008-07-18 20:30       ` Marcin Obara
2008-07-23 18:00         ` Marcin Obara
2008-08-11 19:23           ` Marcin Obara
2008-08-12  4:53             ` Andrew Morton
2008-08-12 16:15               ` Jiri Slaby [this message]
2008-08-12 19:24                 ` Marcin Obara
2008-08-12 19:24                   ` Alan Cox
2008-08-12 21:03                   ` Arjan van de Ven
2008-08-13  0:58             ` Greg KH
2008-08-13  7:16               ` Marcin Obara
2008-08-13 18:18                 ` Greg KH
2008-08-13 19:48                   ` Marcin Obara
2008-08-14  0:23                     ` Greg KH
2008-07-18  9:27 ` Andi Kleen
2008-07-18 10:51   ` Marcin Obara
2008-07-18 11:02     ` Andi Kleen
2008-07-18 11:33       ` Marcin Obara
2008-08-06 16:56 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2008-05-20  0:11 Anas Nashif
2008-05-20  0:28 ` Andrew Morton
2008-05-20 19:02   ` Gabriel C
2008-05-22 16:51   ` Pavel Machek
2008-05-20 15:42 ` Maxim Levitsky
2008-05-20 20:35 ` Carlos R. Mafra
2008-05-20 22:27 ` Jiri Slaby
2008-05-23  7:04 ` Pavel Machek
2007-12-11 17:32 Anas Nashif
2007-12-11 18:14 ` Andi Kleen
2007-12-11 18:38   ` Anas Nashif
2007-12-11 18:53     ` Andi Kleen
2007-12-11 19:02       ` David Miller
2007-12-11 19:47         ` Andi Kleen
2007-12-11 19:06       ` Anas Nashif
2007-12-11 19:48         ` Andi Kleen
2007-12-12 15:00         ` Mark Lord
2007-12-12 16:17           ` Andi Kleen
2007-12-12  8:48 ` Alexander E. Patrakov

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=48A1B71C.6080201@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin_obara@users.sourceforge.net \
    --cc=pavel@suse.cz \
    /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