All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	i2c list <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Subject: Re: [PATCH] i2c: skip address detection if provided in board_info
Date: Wed, 13 Oct 2010 08:54:18 -0700	[thread overview]
Message-ID: <20101013085418.00003979@unknown> (raw)
In-Reply-To: <20101013092654.7e26fa00-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>

Hi Jean,

Jean Delvare Wed, 13 Oct 2010 09:26:54 +0200

>Devices don't have detect functions. Drivers do.
>
Yes, i understand. I was referring to i2c device driver vs adapter driver.
I will make it clearer next time.

>> Then all detect functions will be ignored
>> if i2c adpater class code is 0. The granularity of information provided by
>> our FW is per i2c device.
>> 
>> Seems we have three cases:
>> 1. adaptor class = 0, no detect
>> 2. adaptor class !=0, FW provide address via board info, no detect
>> 3. adaptor class !=0, no FW board info, do detect by default, but should
>> allow platform code override
>> 
>> I would think we need a global flag for case #3.
>
>You complain that the granularity of the current implementation is
>insufficient, but you propose to solve that problem using a _global_
>flag? This doesn't make sense, sorry.
>
to me, the global flag solves the problem where we want faster boottime
in all cases. so it is kinda of a different problem.

>There are actually two main cases, not three:
>
>1. Adapter class == 0, no detection, platform data provides all device
>   information.
>2. Adapter class != 0, detection of all devices, no platform data.
>
>Mixed cases aren't supported, because it is expected that all devices
>are declared as platform data, or none is. This seems to work OK so far
>for everybody. If it doesn't work for you, please explain why, in
>details.
>
it works for us in practice, at least for today. perhaps I am just playing
devil's advocate, but also for the completeness of the logic for future
use.

>Note though that there is some level of granularity because the adapter
>class is a bitfield. So it is possible to declare all I2C devices as
>platform data except the hardware monitoring devices, for example, and
>set adapter class = I2C_CLASS_HWMON.
>
>There aren't many bits really used, BTW, mostly I2C_CLASS_HWMON and
>I2C_CLASS_SPD, and the trend is to remove the unused class flags rather
>than to add new ones. However, if you need a new I2C_CLASS flag, this
>can certainly be done.
>

Can we make an explicit bit I2C_CLASS_NO_DETECT so that is is more
explicit? It also allows co-existance with other flags so that we can
handle mixed cases?

Thanks,
Jacob

  parent reply	other threads:[~2010-10-13 15:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-11 23:10 [PATCH] i2c: skip address detection if provided in board_info jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA
     [not found] ` <1286838635-16474-1-git-send-email-jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2010-10-12  7:28   ` Jean Delvare
     [not found]     ` <20101012092822.6f4e4aa5-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-10-12  8:21       ` Feng Tang
2010-10-12  8:47         ` Jean Delvare
     [not found]           ` <20101012104707.3318511d-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-10-12  9:30             ` Feng Tang
2010-10-12 11:34               ` Jean Delvare
     [not found]                 ` <20101012133425.490e3c4c-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-10-12 18:01                   ` Jacob Pan
2010-10-13  7:26                     ` Jean Delvare
     [not found]                       ` <20101013092654.7e26fa00-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-10-13 15:54                         ` Jacob Pan [this message]
2010-10-13 16:07                           ` Jean Delvare
     [not found]                             ` <20101013180751.2d37c513-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-10-13 17:01                               ` Jacob Pan
2010-10-13 17:04                   ` Feng Tang
2010-10-13  9:29                     ` Jean Delvare

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=20101013085418.00003979@unknown \
    --to=jacob.jun.pan-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.