All of lore.kernel.org
 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 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.