This is the code from SPI.cpp:
void SPIClass::begin() {
// Set direction register for SCK and MOSI pin.
// MISO pin automatically overrides to INPUT.
// When the SS pin is set as OUTPUT, it can be used as
// a general purpose output port (it doesn't influence
// SPI operations).
pinMode(SCK, OUTPUT);
pinMode(MOSI, OUTPUT);
pinMode(SS, OUTPUT);
digitalWrite(SCK, LOW);
digitalWrite(MOSI, LOW);
digitalWrite(SS, HIGH);
// Warning: if the SS pin ever becomes a LOW INPUT then SPI
// automatically switches to Slave, so the data direction of
// the SS pin MUST be kept as OUTPUT.
SPCR |= _BV(MSTR);
SPCR |= _BV(SPE);
}
Note that it doesn't directly set MISO to an input, but the documentation for the Atmega says "When the SPI is enabled, the data direction of the MOSI, MISO, SCK, and SS pins is overridden according to Table 18-1 on page 168.". And that table says the MISO is set as an input. So the enabling of SPI does indeed set MISO as an input. The other ones are done in SPI.begin because the chip itself doesn't want to set things to an output in case you didn't really want to do that.
What if you have a chip that needs SS low to select the chip?
Well that is the normal case, and you can see that it sets SS as an output, and initially high. So you set it low when you want to write to it, and then high again (as in my example).
Does "pulling SCK low" mean it pulls SCK low no matter what the SPI data mode is set to?
Well the code certainly does, however my tests reveal that if you do this:
SPI.begin ();
SPI.setDataMode (SPI_MODE2); // clock is high to low
Then the SPI hardware switches the clock to normally high, so you don't have to worry about that.