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

Commit 3cef5c5b authored by David S. Miller's avatar David S. Miller
Browse files


Conflicts:
	drivers/net/ethernet/cadence/macb.c

Overlapping changes in macb driver, mostly fixes and cleanups
in 'net' overlapping with the integration of at91_ether into
macb in 'net-next'.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 8ac467e8 affb8172
Loading
Loading
Loading
Loading
+27 −0
Original line number Diff line number Diff line
Code of Conflict
----------------

The Linux kernel development effort is a very personal process compared
to "traditional" ways of developing software.  Your code and ideas
behind it will be carefully reviewed, often resulting in critique and
criticism.  The review will almost always require improvements to the
code before it can be included in the kernel.  Know that this happens
because everyone involved wants to see the best possible solution for
the overall success of Linux.  This development process has been proven
to create the most robust operating system kernel ever, and we do not
want to do anything to cause the quality of submission and eventual
result to ever decrease.

If however, anyone feels personally abused, threatened, or otherwise
uncomfortable due to this process, that is not acceptable.  If so,
please contact the Linux Foundation's Technical Advisory Board at
<tab@lists.linux-foundation.org>, or the individual members, and they
will work to resolve the issue to the best of their ability.  For more
information on who is on the Technical Advisory Board and what their
role is, please see:
	http://www.linuxfoundation.org/programs/advisory-councils/tab

As a reviewer of code, please strive to keep things civil and focused on
the technical issues involved.  We are all humans, and frustrations can
be high on both sides of the process.  Try to keep in mind the immortal
words of Bill and Ted, "Be excellent to each other."
+1 −0
Original line number Diff line number Diff line
@@ -7,6 +7,7 @@ Required properties:
  - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC
- reg : Should contain I2C/HS-I2C registers location and length
- interrupts : Should contain I2C/HS-I2C interrupt
- clocks : Should contain the I2C/HS-I2C clock specifier

Optional properties:
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
+4 −1
Original line number Diff line number Diff line
@@ -4,7 +4,10 @@ Ethernet nodes are defined to describe on-chip ethernet interfaces in
APM X-Gene SoC.

Required properties for all the ethernet interfaces:
- compatible: Should be "apm,xgene-enet"
- compatible: Should state binding information from the following list,
  - "apm,xgene-enet":    RGMII based 1G interface
  - "apm,xgene1-sgenet": SGMII based 1G interface
  - "apm,xgene1-xgenet": XFI based 10G interface
- reg: Address and length of the register set for the device. It contains the
  information of registers in the same order as described by reg-names
- reg-names: Should contain the register set names
+16 −0
Original line number Diff line number Diff line
@@ -21,6 +21,18 @@ Optional properties:
- reg-io-width : the size (in bytes) of the IO accesses that should be
  performed on the device.  If this property is not present then single byte
  accesses are used.
- dcd-override : Override the DCD modem status signal. This signal will always
  be reported as active instead of being obtained from the modem status
  register. Define this if your serial port does not use this pin.
- dsr-override : Override the DTS modem status signal. This signal will always
  be reported as active instead of being obtained from the modem status
  register. Define this if your serial port does not use this pin.
- cts-override : Override the CTS modem status signal. This signal will always
  be reported as active instead of being obtained from the modem status
  register. Define this if your serial port does not use this pin.
- ri-override : Override the RI modem status signal. This signal will always be
  reported as inactive instead of being obtained from the modem status register.
  Define this if your serial port does not use this pin.

Example:

@@ -31,6 +43,10 @@ Example:
		interrupts = <10>;
		reg-shift = <2>;
		reg-io-width = <4>;
		dcd-override;
		dsr-override;
		cts-override;
		ri-override;
	};

Example with one clock:
+17 −5
Original line number Diff line number Diff line
@@ -40,8 +40,10 @@ but also to IPIs and to some other special-purpose interrupts.

The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
requesting a special-purpose interrupt.  It causes suspend_device_irqs() to
leave the corresponding IRQ enabled so as to allow the interrupt to work all
the time as expected.
leave the corresponding IRQ enabled so as to allow the interrupt to work as
expected during the suspend-resume cycle, but does not guarantee that the
interrupt will wake the system from a suspended state -- for such cases it is
necessary to use enable_irq_wake().

Note that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one
user of it.  Thus, if the IRQ is shared, all of the interrupt handlers installed
@@ -110,8 +112,9 @@ any special interrupt handling logic for it to work.
IRQF_NO_SUSPEND and enable_irq_wake()
-------------------------------------

There are no valid reasons to use both enable_irq_wake() and the IRQF_NO_SUSPEND
flag on the same IRQ.
There are very few valid reasons to use both enable_irq_wake() and the
IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the
same device.

First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND
interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
@@ -120,4 +123,13 @@ handlers are not invoked after suspend_device_irqs()).

Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
to individual interrupt handlers, so sharing an IRQ between a system wakeup
interrupt source and an IRQF_NO_SUSPEND interrupt source does not make sense.
interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally
make sense.

In rare cases an IRQ can be shared between a wakeup device driver and an
IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver
must be able to discern spurious IRQs from genuine wakeup events (signalling
the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to
ensure that the IRQ will function as a wakeup source, and must request the IRQ
with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If
these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.
Loading