Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 0ae28a35 authored by David Woodhouse's avatar David Woodhouse
Browse files

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 

Conflicts:
	drivers/mtd/mtdcore.c

Pull in the bdi fixes and ARM platform changes that other outstanding
patches depend on.
parents 6f1f3d0a b57f95a3

Documentation/DocBook/libata.tmpl

+16 −33
Original line number Diff line number Diff line
@@ -107,10 +107,6 @@ void (*dev_config) (struct ata_port *, struct ata_device *); 
	issue of SET FEATURES - XFER MODE, and prior to operation.

	</para>

	<para>

	Called by ata_device_add() after ata_dev_identify() determines

	a device is present.

	</para>

	<para>

	This entry may be specified as NULL in ata_port_operations.

	</para>
@@ -154,8 +150,8 @@ unsigned int (*mode_filter) (struct ata_port *, struct ata_device *, unsigned in 


	<sect2><title>Taskfile read/write</title>

	<programlisting>

void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf);

void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);

void (*sff_tf_load) (struct ata_port *ap, struct ata_taskfile *tf);

void (*sff_tf_read) (struct ata_port *ap, struct ata_taskfile *tf);

	</programlisting>



	<para>
@@ -164,36 +160,35 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); 
	hardware registers / DMA buffers, to obtain the current set of

	taskfile register values.

	Most drivers for taskfile-based hardware (PIO or MMIO) use

	ata_tf_load() and ata_tf_read() for these hooks.

	ata_sff_tf_load() and ata_sff_tf_read() for these hooks.

	</para>



	</sect2>



	<sect2><title>PIO data read/write</title>

	<programlisting>

void (*data_xfer) (struct ata_device *, unsigned char *, unsigned int, int);

void (*sff_data_xfer) (struct ata_device *, unsigned char *, unsigned int, int);

	</programlisting>



	<para>

All bmdma-style drivers must implement this hook.  This is the low-level

operation that actually copies the data bytes during a PIO data

transfer.

Typically the driver

will choose one of ata_pio_data_xfer_noirq(), ata_pio_data_xfer(), or

ata_mmio_data_xfer().

Typically the driver will choose one of ata_sff_data_xfer_noirq(),

ata_sff_data_xfer(), or ata_sff_data_xfer32().

	</para>



	</sect2>



	<sect2><title>ATA command execute</title>

	<programlisting>

void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);

void (*sff_exec_command)(struct ata_port *ap, struct ata_taskfile *tf);

	</programlisting>



	<para>

	causes an ATA command, previously loaded with

	->tf_load(), to be initiated in hardware.

	Most drivers for taskfile-based hardware use ata_exec_command()

	Most drivers for taskfile-based hardware use ata_sff_exec_command()

	for this hook.

	</para>
@@ -218,8 +213,8 @@ command. 


	<sect2><title>Read specific ATA shadow registers</title>

	<programlisting>

u8   (*check_status)(struct ata_port *ap);

u8   (*check_altstatus)(struct ata_port *ap);

u8   (*sff_check_status)(struct ata_port *ap);

u8   (*sff_check_altstatus)(struct ata_port *ap);

	</programlisting>



	<para>
@@ -227,20 +222,14 @@ u8 (*check_altstatus)(struct ata_port *ap); 
	hardware.  On some hardware, reading the Status register has

	the side effect of clearing the interrupt condition.

	Most drivers for taskfile-based hardware use

	ata_check_status() for this hook.

	</para>

	<para>

	Note that because this is called from ata_device_add(), at

	least a dummy function that clears device interrupts must be

	provided for all drivers, even if the controller doesn't

	actually have a taskfile status register.

	ata_sff_check_status() for this hook.

	</para>



	</sect2>



	<sect2><title>Select ATA device on bus</title>

	<programlisting>

void (*dev_select)(struct ata_port *ap, unsigned int device);

void (*sff_dev_select)(struct ata_port *ap, unsigned int device);

	</programlisting>



	<para>
@@ -251,9 +240,7 @@ void (*dev_select)(struct ata_port *ap, unsigned int device); 
	</para>

	<para>

	Most drivers for taskfile-based hardware use

	ata_std_dev_select() for this hook.  Controllers which do not

	support second drives on a port (such as SATA contollers) will

	use ata_noop_dev_select().

	ata_sff_dev_select() for this hook.

	</para>



	</sect2>
@@ -441,13 +428,13 @@ void (*irq_clear) (struct ata_port *); 
	to struct ata_host_set.

	</para>

	<para>

	Most legacy IDE drivers use ata_interrupt() for the

	Most legacy IDE drivers use ata_sff_interrupt() for the

	irq_handler hook, which scans all ports in the host_set,

	determines which queued command was active (if any), and calls

	ata_host_intr(ap,qc).

	ata_sff_host_intr(ap,qc).

	</para>

	<para>

	Most legacy IDE drivers use ata_bmdma_irq_clear() for the

	Most legacy IDE drivers use ata_sff_irq_clear() for the

	irq_clear() hook, which simply clears the interrupt and error

	flags in the DMA status register.

	</para>
@@ -496,10 +483,6 @@ void (*host_stop) (struct ata_host_set *host_set); 
	data from port at this time.

	</para>

	<para>

	Many drivers use ata_port_stop() as this hook, which frees the

	PRD table.

	</para>

	<para>

	->host_stop() is called after all ->port_stop() calls

have completed.  The hook must finalize hardware shutdown, release DMA

and other resources, etc.

Documentation/DocBook/tracepoint.tmpl

+13 −0
Original line number Diff line number Diff line
@@ -16,6 +16,15 @@ 
     </address>

    </affiliation>

   </author>

   <author>

    <firstname>William</firstname>

    <surname>Cohen</surname>

    <affiliation>

     <address>

      <email>wcohen@redhat.com</email>

     </address>

    </affiliation>

   </author>

  </authorgroup>



  <legalnotice>
@@ -91,4 +100,8 @@ 
!Iinclude/trace/events/signal.h

  </chapter>



  <chapter id="block">

   <title>Block IO</title>

!Iinclude/trace/events/block.h

  </chapter>

</book>

Documentation/HOWTO

+1 −1
Original line number Diff line number Diff line
@@ -234,7 +234,7 @@ process is as follows: 
    Linus, usually the patches that have already been included in the

    -next kernel for a few weeks.  The preferred way to submit big changes

    is using git (the kernel's source management tool, more information

    can be found at http://git.or.cz/) but plain patches are also just

    can be found at http://git-scm.com/) but plain patches are also just

    fine.

  - After two weeks a -rc1 kernel is released it is now possible to push

    only patches that do not include new features that could affect the

Documentation/RCU/NMI-RCU.txt

+22 −17
Original line number Diff line number Diff line
@@ -34,7 +34,7 @@ NMI handler. 
		cpu = smp_processor_id();

		++nmi_count(cpu);



		if (!rcu_dereference(nmi_callback)(regs, cpu))

		if (!rcu_dereference_sched(nmi_callback)(regs, cpu))

			default_do_nmi(regs);



		nmi_exit();
@@ -47,12 +47,13 @@ function pointer. If this handler returns zero, do_nmi() invokes the 
default_do_nmi() function to handle a machine-specific NMI.  Finally,

preemption is restored.



Strictly speaking, rcu_dereference() is not needed, since this code runs

only on i386, which does not need rcu_dereference() anyway.  However,

it is a good documentation aid, particularly for anyone attempting to

do something similar on Alpha.

In theory, rcu_dereference_sched() is not needed, since this code runs

only on i386, which in theory does not need rcu_dereference_sched()

anyway.  However, in practice it is a good documentation aid, particularly

for anyone attempting to do something similar on Alpha or on systems

with aggressive optimizing compilers.



Quick Quiz:  Why might the rcu_dereference() be necessary on Alpha,

Quick Quiz:  Why might the rcu_dereference_sched() be necessary on Alpha,

	     given that the code referenced by the pointer is read-only?
@@ -99,17 +100,21 @@ invoke irq_enter() and irq_exit() on NMI entry and exit, respectively. 


Answer to Quick Quiz



	Why might the rcu_dereference() be necessary on Alpha, given

	Why might the rcu_dereference_sched() be necessary on Alpha, given

	that the code referenced by the pointer is read-only?



	Answer: The caller to set_nmi_callback() might well have

		initialized some data that is to be used by the

		new NMI handler.  In this case, the rcu_dereference()

		would be needed, because otherwise a CPU that received

		an NMI just after the new handler was set might see

		the pointer to the new NMI handler, but the old

		pre-initialized version of the handler's data.



		More important, the rcu_dereference() makes it clear

		to someone reading the code that the pointer is being

		protected by RCU.
 
		initialized some data that is to be used by the new NMI

		handler.  In this case, the rcu_dereference_sched() would

		be needed, because otherwise a CPU that received an NMI

		just after the new handler was set might see the pointer

		to the new NMI handler, but the old pre-initialized

		version of the handler's data.



		This same sad story can happen on other CPUs when using

		a compiler with aggressive pointer-value speculation

		optimizations.



		More important, the rcu_dereference_sched() makes it

		clear to someone reading the code that the pointer is

		being protected by RCU-sched.