All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean MacLennan <smaclennan-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
	i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
Subject: Re: [PATCH 2/2] i2c-ibm_iic driver
Date: Tue, 19 Feb 2008 18:18:06 -0500	[thread overview]
Message-ID: <47BB63AE.2090903@pikatech.com> (raw)
In-Reply-To: <200802192355.17707.arnd-r2nGTMty4D4@public.gmane.org>

Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
>   
>> On Tuesday 19 February 2008, Jean Delvare wrote:
>>     
>>> With this Kconfig change, "make menuconfig" lets me select the
>>> i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
>>> that you want to restrict the build to PPC machines somehow, or at
>>> least make sure that either IBM_OCP or OF support is present.
>>>       
>> How about this:
>>
>> -       depends on IBM_OCP
>> +       depends on 4xx
>>     
>
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
>
> -       depends on IBM_OCP
> +       depends on IBM_OCP || PPC_MERGE
>
>   
I have no problem with this change. If everybody agrees, I can respin 
the patch.

Cheers,
   Sean

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

WARNING: multiple messages have this Message-ID (diff)
From: Sean MacLennan <smaclennan@pikatech.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jean Delvare <khali@linux-fr.org>,
	linuxppc-dev@ozlabs.org, Stefan Roese <sr@denx.de>,
	i2c@lm-sensors.org
Subject: Re: [PATCH 2/2] i2c-ibm_iic driver
Date: Tue, 19 Feb 2008 18:18:06 -0500	[thread overview]
Message-ID: <47BB63AE.2090903@pikatech.com> (raw)
In-Reply-To: <200802192355.17707.arnd@arndb.de>

Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
>   
>> On Tuesday 19 February 2008, Jean Delvare wrote:
>>     
>>> With this Kconfig change, "make menuconfig" lets me select the
>>> i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
>>> that you want to restrict the build to PPC machines somehow, or at
>>> least make sure that either IBM_OCP or OF support is present.
>>>       
>> How about this:
>>
>> -       depends on IBM_OCP
>> +       depends on 4xx
>>     
>
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
>
> -       depends on IBM_OCP
> +       depends on IBM_OCP || PPC_MERGE
>
>   
I have no problem with this change. If everybody agrees, I can respin 
the patch.

Cheers,
   Sean

  parent reply	other threads:[~2008-02-19 23:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09 17:05 [PATCH] i2c-ibm_iic driver Sean MacLennan
2008-01-09 17:05 ` Sean MacLennan
     [not found] ` <4784FED1.2040206-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
2008-01-31  4:27   ` Sean MacLennan
     [not found]     ` <47A14E23.50807-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
2008-02-14  8:45       ` Jean Delvare
2008-02-16  4:07         ` [PATCH 1/2] " Sean MacLennan
2008-02-16  8:20           ` Jean Delvare
2008-02-16  4:11         ` [PATCH 2/2] " Sean MacLennan
2008-02-16  9:31           ` Jean Delvare
2008-02-16 20:54             ` Sean MacLennan
2008-02-17 10:52               ` Jean Delvare
2008-02-19  1:42             ` Sean MacLennan
2008-02-19  8:23               ` Jean Delvare
     [not found]                 ` <20080219092321.1fed233d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-02-19  8:59                   ` Stefan Roese
2008-02-19  8:59                     ` Stefan Roese
2008-02-19 22:23                     ` Sean MacLennan
     [not found]                     ` <200802190959.41253.sr-ynQEQJNshbs@public.gmane.org>
2008-02-19 22:55                       ` Arnd Bergmann
2008-02-19 22:55                         ` Arnd Bergmann
     [not found]                         ` <200802192355.17707.arnd-r2nGTMty4D4@public.gmane.org>
2008-02-19 23:18                           ` Sean MacLennan [this message]
2008-02-19 23:18                             ` Sean MacLennan
2008-02-19 23:41                             ` Stephen Rothwell
2008-02-19 23:41                               ` Stephen Rothwell
     [not found]                               ` <20080220104133.e9722e62.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2008-02-19 23:54                                 ` Arnd Bergmann
2008-02-19 23:54                                   ` Arnd Bergmann
2008-02-20  6:57                           ` Jean Delvare
2008-02-20  6:57                             ` Jean Delvare
2008-02-19 21:58                 ` Sean MacLennan
2008-02-20  7:20                   ` 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=47BB63AE.2090903@pikatech.com \
    --to=smaclennan-qtffpm9i2avwk0htik3j/w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
    --cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@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.