What is holding the SS pin high in SPI master mode on AVRs?

Question

A typical AVR datasheet contains the following example of an SPI Master mode configuration (here from page 164 of the ATmega128/L datasheet):

void SPI_MasterInit(void)
{
    /* Set MOSI and SCK output, all others input */
    DDR_SPI = (1<<DD_MOSI)|(1<<DD_SCK);

    /* Enable SPI, Master, set clock rate fck/16 */
    SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0);
}

void SPI_MasterTransmit(char cData)
{
    /* Start transmission */
    SPDR = cData;

    /* Wait for transmission complete */
    while (!(SPSR & (1<<SPIF)))
        ;
}

Note that the initialization of the data direction register, here given as DDR_SPI, sets the SS pin to input (implied by "all others to input").

However, the section on the SS pin functionality (which follows the code, on page 166) states for Master mode:

If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI slave.

If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following actions:

1. The MSTR bit in SPCR is cleared and the SPI system becomes a slave. As a result of the SPI becoming a slave, the MOSI and SCK pins become inputs.
2. The SPIF flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt routine will be executed.

Thus, when interrupt-driven SPI transmission is used in master mode, and there exists a possibility that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI master mode.

(Emphasis mine).

Now, the code works fine for me, but I don't understand why. The Master's SS pin direction is set to input, but what is holding it high? The code doesn't activate the pull-up. It seems to me that a floating pin could possibly trigger the consequences 1. and 2., resulting in the master becoming a slave. But it seems hard to believe to me that the code examples would employ such an unpredictable scenario.

Answer 1

The SS line ( of this devices or others ) is completely ignored in the example since it is supposed to controlled by the software ( you have to do it ) as it states that in page 163 of that datasheet:

When configured as a Master, the SPI interface has no automatic control of the SS line. This must be handled by user software before communication can start. W hen this is do ne, writing a byte to the SPI Data Register starts the SPI clock generator, and the hardware shifts the 8 bits into the Slave.

I now this is about the other device SS but it implies that you should take care of this line on both sides ,So even in the sending part it is supposed to drive the SS of the slave low but it is not included

    void SPI_MasterTransmit(char cData)
{
    /* Start transmission */
    // set slave SS line to low is missing here
    SPDR = cData;

    /* Wait for transmission complete */
    while (!(SPSR & (1<<SPIF)));
}