dts: update to v4.12-rc7 ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

dts: update to v4.12-rc6 ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: dts: i.MX6: fix usdhc3 pinmuxing on tqma6x ...

The usdhc3 pin group wrongly referred the SD4 pads instead of the SD3 pads.
This leads to issues when muxing the SD4_CMD and SD4_CLK pads for uart3.

This regression was introduced by code refactoring in commit a5207a6 ("ARM:
dts: i.MX6: drop usage of pin group defines").

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: user close may happen in SYN-RECEIVED state ...

The reference says:

     5.2.3. SYN-RECEIVED
     ...
     Departures
       - A CLOSE request is made by the user.  Create a packet with
         FIN set.  Send it and go to the FIN-WAIT state.

Add this missing step.

Probably not a real usecase for barebox anyway as there is no user
triggered close.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: consolidate setting the next AN or SN flags ...

Setting the next AN or SN flag was being done in two different ways
throughout the code; e.g. here for AN:

    ratp_set_an(ratp_sn(hdr) + 1);
or:
    ratp_set_an(!ratp_sn(hdr));

We define a pair of new ratp_set_next_sn() and ratp_set_next_an()
macros that make it clear that the next value is desired, and also
hide the computation of the actual flag value within the macro, so the
previous example would now look like:

    ratp_set_next_an(ratp_sn(hdr));

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: don't ignore data that may arrive in behaviour H1 ...

If an input packet arrives H1 that has data in it, we need to:
  * track sn_received
  * if we have data pending, send it
  * if we don't have data pending, send a plain ACK

This process, as noted in RFC916, is the same as the I1 procedure, so
go and run it:

     Go to the ESTABLISHED state and execute procedure I1 to process
     any data which might be in this packet.

This fix allows the peer to queue data in the last packet doing the
connection establishment. It doesn't apply to the barebox<->bbremote
interaction because bbremote won't queue data until the connection is
completely established, but it allows third party ratp implementations
to do that.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: send initial data in behaviour B if any pending ...

And also, use ratp_send_ack() instead of manually constructing an ACK
if no data is pending to be sent.

The current barebox implementation doesn't allow any queueing of data
until the connection is established, so this is probably not a case
that would get run anyway.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: prefer using ratp_send_ack() in behaviour I1 ...

Instead of manually constructing an ACK, use the ratp_send_ack()
method, which already does that properly.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: consolidate ratp_sn_expected() and ratp_an_expected() ...

This is no code change in ratp_sn_expected(), it's just rewritten in
the same way as ratp_an_expected(), which follows the RFC916 approach.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: fix sending ACKs without data ...

All ACKs without data must be built in the same way from the input
message:
     <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>

The code was actually doing this instead:
     <SN=0><AN=SN><CTL=ACK>

This change fixes how the retransmissions are ACK-ed by the peer, and
would have affected the barebox<->bbremote interactions.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: remove FIXME comment: FIN always requires ACK ...

Section 3.4 in the RFC916 shows a packet flow for the connection close
where the initial packet sent by the endpoint starting the close has
just the FIN flag set, without an ACK:

          -->     <SN=0><AN=1><CTL=FIN>
                <SN=1><AN=1><CTL=FIN,ACK>  <--
          -->     <SN=1><AN=0><CTL=ACK>

This may lead to think that it is actually allowed to send the initial
packet with just FIN set, without ACK-ing any other packet from the
peer.

But, this is actually not possible, the packet MUST be ACK-ing a
previous packet from the peer, even if this is just a duplicated ACK,
because otherwise the packet with the FIN wouldn't get processed in
the H2 behavior (FIN processing) of the peer, as the F2 behavior (ACK
processing) would filter it out.

This is actually the same reasoning why data packets always have ACK
set, even if the same ACK has already been sent previously (e.g. with
a simple ACK packet without data); if they didn't have it, they would
be filtered out in the F2 behavior, never arriving the I1 behavior,
which is where the received data is processed.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: remove bogus data checks in behavior C2 ...

The SN validation was being completely ignored if the packet had no
data (e.g. for RST, FIN or SYN or plain ACKs). This condition is now
removed so that the SN check is done.

The second check removed was actually never being used, as it was
already being tested for not having data in the first one.

These two fixes are a cleanup to follow the protocol correctly.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: fix single byte sending flagged with SO ...

When a single data byte is sent, it is flagged as SO and the actual
data goes in the length byte within the header.

Worth noting that this issue wasn't found in any barebox<->bbremote
interaction because all data packets sent between them always have
more than one byte (due to the barebox command specific header).

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: fix data presence check ...

Looking at the "data length" and SO flag isn't enough to declare a
packet with or without data, because SYN flagged packets will also use
the "data length" field to define MDL.

So, improve the check to match against SYN|RST|FIN flagged packets,
which can never have data.

This commit fixed a segfault in barebox when an unexpected SYN packet
was sent in the middle of a connection; barebox thought the packet had
data because the "data length" in the SYN packet was different than 0.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: completely ignore RST flagged packets in behavior G ...

The reference says:

    This procedure represents the behavior of the CLOSED state of a
    connection. All incoming packets are discarded. If the packet
    had the RST flag set take no action. Otherwise it is necessary
    to build a RST packet.

So, skip building the RST packet if the incoming one had RST set.

This commit fixes an infinite loop of messages sent and received
between both ends during the connection close procedure, found when
testing barebox against a third party ratp implementation.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: add missing RST flag in behavior G ...

The reference says:

   If the ACK flag was set then send:
       <SN=received AN><CTL=RST>
   If the ACK flag was not set then send:
       <SN=0><AN=received SN+1 modulo 2><CTL=RST, ACK>
   (i.e. in both cases RST is needed)

The RST flag is set initially in the 'control' variable; so instead of
completely overwriting it, make sure the additional flags are OR-ed
to the current value.

This fix isn't related to any failed barebox<->bbremote interaction
(it really is a very rare corner case).

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: send missing RST in behavior C2 ...

The reference says:

    If SYN was set we assume that the other end crashed and has
    attempted to open a new connection.  We respond by sending a
    legal reset:
        <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>

Add this missing step.

This issue affects the barebox<->bbremote interaction if bbremote
crashes without closing the channel and restarts opening a complete
new connection.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: avoid unnecessary variable initializations ...

This is just a cleanup; the variables are completely initialized later
on so the initial values are totally discarded anyway.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: add missing transition to SYN-RECEIVED in behavior B ...

The reference says:

    If the SYN flag was set but the ACK was not set then the other
    end of the connection has executed an active open also.
    Acknowledge the SYN, choose your MDL, and send:
        <SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
    Go to the SYN-RECEIVED state without any further processing.

Add this missing step.

This fix isn't related to any barebox<->bbremote interaction issue,
because the case where both ends start an active connection doesn't
apply in this case.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

lib/fonts: add 6x8 font ...

This font is derived from linux lib/fonts/font_6x10.c.

Signed-off-by: Sven Schneider <s.schneider@arkona-technologies.de>
[rhi: fix indentation for block /* 36 0x28 '$' */]
Signed-off-by: Roland Hieber <r.hieber@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

state: backend: always pass backend type to Linux dtb ...

When the "backend-storage-type" property is unset in the barebox dtb
then barebox will use the default. Instead of leaving the property
unset in the Linux dtb, set it to the value we used as default. By
making the default explicit to Linux we force Linux to the same backend
type, even when the defaults may differ.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

i.MX: clk: Remove imx_clk_pllv3_locked() ...

Remove imx_clk_pllv3_locked() which was introduced for the sake of
Vybrid platform. The same effect (waiting on 'locked' bit) can be
achived with vanilla clk_pllv3_enable/disable, which make said
function unnecessary.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

i.MX: clk-pllv3: Do not touch PLL_BYPASS bit ...

Do not touch PLL_BYPASS bit as a part of clk_pll3_enable/disable
execution. For a number of platforms (e.g. Vybrid, i.MX6SL) PLL_BYPASS
is specified as a bit controlling a clock MUX represented by a
dedicated 'struct clk'. Altering that bit as a part of
clk_pll3_enable/disable is equivalent to calling clk_set_parent() and
it makes in the following code:

clk_enable(clk_disable(<some pll>))

change clock chain instead of being a no-op.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

clk-vf610: Mark all of CCSR muxes with CLK_OPS_PARENT_ENABLE ...

As per VYBRIDRM.pdf, p. 673:

"... When switching clock sources on GL MUX, both active and target
clock sources must be active..."

So mark all of the clock muxes controlled by CCM_CSSR with
CLK_OPS_PARENT_ENABLE to satisfy that requirement. Experiment shows
that failing to do so would result in failure (in some cases CPU
hang).

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Update zii_vf610_dev_defconfig ...

Update zii_vf610_dev_defconfig to add needed and remove unused
features.

Signed-off-by: Chris Healy <cphealy@gmail.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mtd: dataflash: Add flash_info for AT45DB641E ...

This is a backport of kernel commit
67e4145

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mtd: dataflash: Make use of "extened device information" ...

In anticipation of supporting chips that need it, extend the size of
struct flash_info's 'jedec_id' field to make room 2 byte of extended
device information as well as add code to fetch this data during
jedec_probe().

This is a backport of kernel commit
1da8869

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mtd: dataflash: Get rid of loop counter in jedec_probe() ...

"For" loop in jedec_probe can be simplified to not need counter
'i'. Convert the code and get rid of the variable.

This is a backport of kernel commit
a296a1b

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mtd: dataflash: Replace pr_debug, printk with dev_* functions ...

Lion's share of calls to pr_debug in this driver follow the pattern of
pr_debug("%s <message>", dev_name(<dev>), <arguments>), which should
be semantically identical to dev_dbg(<dev>, "<message>", <arguments>),
so replace such occurencies to simplify the code.

Convert the small minority of pr_debug that do not follow pattern from
above to use dev_dbg as well, for the sake of consistency.

Convert similar patter of printk(KERN_ERR, "%s: ...", dev_name(...),
...) to use dev_err instead.

No functional change intended.

This is a backport of kernel commit
02f6286

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mtd: dataflash: Improve coding style in jedec_probe() ...

Change the following:

   - Replace indentation between type and name of local variable from
     tabs to spaces

   - Replace magic number 0x1F with CFI_MFR_ATMEL macro

   - Replace variable 'tmp' with 'ret' and 'i' where appropriate

   - Reformat multi-line comments and add newlines where appropriate

No functional change intended.

This is a backport of kernel commit
41c9c66

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>