All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Bordug <vbordug@ru.mvista.com>
To: Andy Fleming <afleming@freescale.com>
Cc: Phillips Kim-R1AAHA <Kim.Phillips@freescale.com>,
	Yin Olivia-r63875 <Hong-Hua.Yin@freescale.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	linuxppc-dev@ozlabs.org, 'Paul Mackerras' <paulus@samba.org>,
	Chu hanjin-r52514 <Hanjin.Chu@freescale.com>
Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
Date: Thu, 29 Jun 2006 22:51:31 +0400	[thread overview]
Message-ID: <20060629225131.43b9ed59@localhost.localdomain> (raw)
In-Reply-To: <8A7E4B7C-8744-47FF-90FA-9B68C5187CEE@freescale.com>

On Thu, 29 Jun 2006 13:03:23 -0500
Andy Fleming wrote:

[snip]
> >>> +	iounmap(bcsr_regs);
> >>> +
> >> And if we have a design, which do not contain real ethernet UCC  
> >> usage? Or UCC
> >> geth is disabled somehow explicitly? Stuff like that normally
> >> goes to the
> >> callback that is going to be triggered upon Etherbet init.
> > I will move it.
> 
> 
> Wait...no.  I don't understand Vitaly's objection.  If someone  
> creates a board with an 8360 that doesn't use the UCC ethernet, they  
> can create a separate board file.  This is the board-specific code,  
> and it is perfectly acceptable for it to reset the PHY like this.   
> What ethernet callback could be used?
> 

I am sort of against the unconditional trigger of the ethernet-specific stuff,
dependless if UCC eth is really wanted in specific configuration.

For stuff like that I'd make a function (to setup low-level stuff), and pass it 
via platform_info to the eth driver, so that really driver-specific things happen in driver context only.

Yes this is board specific file, and virtually everything needed for the board can take place here. 
But usually BCSR acts as a toggle for a several things, and IOW, I see it more correct to trigger those stuff from the respective drivers (using a callback passed through platform_info)

-Vitaly

WARNING: multiple messages have this Message-ID (diff)
From: Vitaly Bordug <vbordug@ru.mvista.com>
To: Andy Fleming <afleming@freescale.com>
Cc: Li Yang-r58472 <LeoLi@freescale.com>,
	Phillips Kim-R1AAHA <Kim.Phillips@freescale.com>,
	Yin Olivia-r63875 <Hong-Hua.Yin@freescale.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	linuxppc-dev@ozlabs.org, "'Paul Mackerras'" <paulus@samba.org>,
	Chu hanjin-r52514 <Hanjin.Chu@freescale.com>
Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
Date: Thu, 29 Jun 2006 22:51:31 +0400	[thread overview]
Message-ID: <20060629225131.43b9ed59@localhost.localdomain> (raw)
In-Reply-To: <8A7E4B7C-8744-47FF-90FA-9B68C5187CEE@freescale.com>

On Thu, 29 Jun 2006 13:03:23 -0500
Andy Fleming wrote:

[snip]
> >>> +	iounmap(bcsr_regs);
> >>> +
> >> And if we have a design, which do not contain real ethernet UCC  
> >> usage? Or UCC
> >> geth is disabled somehow explicitly? Stuff like that normally
> >> goes to the
> >> callback that is going to be triggered upon Etherbet init.
> > I will move it.
> 
> 
> Wait...no.  I don't understand Vitaly's objection.  If someone  
> creates a board with an 8360 that doesn't use the UCC ethernet, they  
> can create a separate board file.  This is the board-specific code,  
> and it is perfectly acceptable for it to reset the PHY like this.   
> What ethernet callback could be used?
> 

I am sort of against the unconditional trigger of the ethernet-specific stuff,
dependless if UCC eth is really wanted in specific configuration.

For stuff like that I'd make a function (to setup low-level stuff), and pass it 
via platform_info to the eth driver, so that really driver-specific things happen in driver context only.

Yes this is board specific file, and virtually everything needed for the board can take place here. 
But usually BCSR acts as a toggle for a several things, and IOW, I see it more correct to trigger those stuff from the respective drivers (using a callback passed through platform_info)

-Vitaly

  reply	other threads:[~2006-06-29 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-29  9:28 [PATCH 1/7] powerpc: Add mpc8360epb platform support Li Yang-r58472
2006-06-29  9:28 ` Li Yang-r58472
2006-06-29 18:03 ` Andy Fleming
2006-06-29 18:03   ` Andy Fleming
2006-06-29 18:51   ` Vitaly Bordug [this message]
2006-06-29 18:51     ` Vitaly Bordug
2006-06-29 19:18     ` Andy Fleming
2006-06-29 19:18       ` Andy Fleming
2006-06-29 19:56       ` Vitaly Bordug
2006-06-29 19:56         ` Vitaly Bordug
2006-06-29 21:04         ` Andy Fleming
2006-06-29 21:04           ` Andy Fleming
2006-06-29 22:10           ` Vitaly Bordug
2006-06-29 22:10             ` Vitaly Bordug
  -- strict thread matches above, loose matches on Subject: below --
2006-07-04  7:00 Li Yang-r58472
2006-07-04  7:00 ` Li Yang-r58472
2006-07-04 22:39 ` Benjamin Herrenschmidt
2006-07-04 22:39   ` Benjamin Herrenschmidt
2006-06-30 10:27 Li Yang-r58472
2006-06-30 10:27 ` Li Yang-r58472
2006-07-01  9:00 ` Benjamin Herrenschmidt
2006-07-01  9:00   ` Benjamin Herrenschmidt
2006-06-30  7:58 Li Yang-r58472
2006-06-30  7:58 ` Li Yang-r58472
2006-06-28 14:23 Li Yang-r58472
2006-06-28 14:23 ` Li Yang-r58472
2006-06-28 16:58 ` Vitaly Bordug
2006-06-28 16:58   ` Vitaly Bordug

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=20060629225131.43b9ed59@localhost.localdomain \
    --to=vbordug@ru.mvista.com \
    --cc=Hanjin.Chu@freescale.com \
    --cc=Hong-Hua.Yin@freescale.com \
    --cc=Kim.Phillips@freescale.com \
    --cc=afleming@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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.