public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/3] sf: Shrink spi_slave {}
Date: Sat, 18 Jan 2014 18:03:25 +0100	[thread overview]
Message-ID: <201401181803.25740.marex@denx.de> (raw)
In-Reply-To: <20140117182954.GE20094@book.gsilab.sittig.org>

On Friday, January 17, 2014 at 07:29:54 PM, Gerhard Sittig wrote:
> On Fri, Jan 17, 2014 at 22:42 +0530, Jagan Teki wrote:
> > On Fri, Jan 17, 2014 at 10:01 PM, Marek Vasut <marex@denx.de> wrote:
> > > Anyway, I feel we're sinking deeper and deeper into this
> > > sh*t, we should instead take a step back and re-think the
> > > whole approach until we break it even more.
> > 
> > Yes - will shrink once we plan for new approach.  But I'm
> > unclear with new SPI-NOR.
> 
> Regarding this specific patch:  I assume what Marek suggested was
> to restrict the "SPI slave" information to what's specific to an
> SPI slave.  It's just not true that every SPI slave is a flash
> chip (an assumption which QSPI developers appear to fall for
> rather easily).

Heh, really ? :) Otherwise I agree with you.

btw. I honestly don't quite understand this inclination to building separate SPI 
NOR controller instead of building full-fat SPI bus controller :(

> I was about to make a similar comment, that trimming the
> identifiers so rigorously leads to code that only "initiated"
> people can read.

OK, I have to admit I am rather blunt and my rambling may sound nasty. Please 
don't take it personally ;-)

> Even those who want to learn have no chance,
> there would not be a legend of any kind (except for the commit
> message, which soon is buried and not obvious to look up).  And
> even with the legend, it's tedious to train the casual
> co-developer to those specific abbreviations, which may not even
> be in wide spread use outside of the U-Boot code base.
> 
> So I agree with Marek that we should take a deep breath, and be
> aware of the consequences before taking a specific direction (and
> having a clear direction would also be beneficial).
> 
> A more involved answer I will send to the quad SPI thread.

Thanks for expainding so and please keep me in the loop on the qspi :)

Best regards,
Marek Vasut

  reply	other threads:[~2014-01-18 17:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1389969707-3781-1-git-send-email-jaganna@xilinx.com>
2014-01-17 14:41 ` [U-Boot] [PATCH 2/3] sf: Shrink spi_slave {} Jagannadha Sutradharudu Teki
2014-01-17 16:31   ` Marek Vasut
2014-01-17 17:12     ` Jagan Teki
2014-01-17 18:29       ` Gerhard Sittig
2014-01-18 17:03         ` Marek Vasut [this message]
2014-01-18 16:59       ` Marek Vasut
2014-01-17 14:41 ` [U-Boot] [PATCH 3/3] sf: Use shortcut names Jagannadha Sutradharudu Teki
2014-01-17 16:31   ` Marek Vasut
2014-01-20 11:05     ` Detlev Zundel
2014-01-20 11:41       ` Jagan Teki

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=201401181803.25740.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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