Searched hist:0 (Results 1 - 25 of 40686) sorted by path

1234567891011>>

/linux-master/Documentation/ABI/testing/
H A Dsysfs-block-dmdiff 0ce65797 Wed Feb 25 22:50:28 MST 2015 Mike Snitzer <snitzer@redhat.com> dm: impose configurable deadline for dm_request_fn's merge heuristic

Otherwise, for sequential workloads, the dm_request_fn can allow
excessive request merging at the expense of increased service time.

Add a per-device sysfs attribute to allow the user to control how long a
request, that is a reasonable merge candidate, can be queued on the
request queue. The resolution of this request dispatch deadline is in
microseconds (ranging from 1 to 100000 usecs), to set a 20us deadline:
echo 20 > /sys/block/dm-7/dm/rq_based_seq_io_merge_deadline

The dm_request_fn's merge heuristic and associated extra accounting is
disabled by default (rq_based_seq_io_merge_deadline is 0).

This sysfs attribute is not applicable to bio-based DM devices so it
will only ever report 0 for them.

By allowing a request to remain on the queue it will block others
requests on the queue. But introducing a short dequeue delay has proven
very effective at enabling certain sequential IO workloads on really
fast, yet IOPS constrained, devices to build up slightly larger IOs --
yielding 90+% throughput improvements. Having precise control over the
time taken to wait for larger requests to build affords control beyond
that of waiting for certain IO sizes to accumulate (which would require
a deadline anyway). This knob will only ever make sense with sequential
IO workloads and the particular value used is storage configuration
specific.

Given the expected niche use-case for when this knob is useful it has
been deemed acceptable to expose this relatively crude method for
crafting optimal IO on specific storage -- especially given the solution
is simple yet effective. In the context of DM multipath, it is
advisable to tune this sysfs attribute to a value that offers the best
performance for the common case (e.g. if 4 paths are expected active,
tune for that; if paths fail then performance may be slightly reduced).

Alternatives were explored to have request-based DM autotune this value
(e.g. if/when paths fail) but they were quickly deemed too fragile and
complex to warrant further design and development time. If this problem
proves more common as faster storage emerges we'll have to look at
elevating a generic solution into the block core.

Tested-by: Shiva Krishna Merla <shivakrishna.merla@netapp.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
diff 0ce65797 Wed Feb 25 22:50:28 MST 2015 Mike Snitzer <snitzer@redhat.com> dm: impose configurable deadline for dm_request_fn's merge heuristic

Otherwise, for sequential workloads, the dm_request_fn can allow
excessive request merging at the expense of increased service time.

Add a per-device sysfs attribute to allow the user to control how long a
request, that is a reasonable merge candidate, can be queued on the
request queue. The resolution of this request dispatch deadline is in
microseconds (ranging from 1 to 100000 usecs), to set a 20us deadline:
echo 20 > /sys/block/dm-7/dm/rq_based_seq_io_merge_deadline

The dm_request_fn's merge heuristic and associated extra accounting is
disabled by default (rq_based_seq_io_merge_deadline is 0).

This sysfs attribute is not applicable to bio-based DM devices so it
will only ever report 0 for them.

By allowing a request to remain on the queue it will block others
requests on the queue. But introducing a short dequeue delay has proven
very effective at enabling certain sequential IO workloads on really
fast, yet IOPS constrained, devices to build up slightly larger IOs --
yielding 90+% throughput improvements. Having precise control over the
time taken to wait for larger requests to build affords control beyond
that of waiting for certain IO sizes to accumulate (which would require
a deadline anyway). This knob will only ever make sense with sequential
IO workloads and the particular value used is storage configuration
specific.

Given the expected niche use-case for when this knob is useful it has
been deemed acceptable to expose this relatively crude method for
crafting optimal IO on specific storage -- especially given the solution
is simple yet effective. In the context of DM multipath, it is
advisable to tune this sysfs attribute to a value that offers the best
performance for the common case (e.g. if 4 paths are expected active,
tune for that; if paths fail then performance may be slightly reduced).

Alternatives were explored to have request-based DM autotune this value
(e.g. if/when paths fail) but they were quickly deemed too fragile and
complex to warrant further design and development time. If this problem
proves more common as faster storage emerges we'll have to look at
elevating a generic solution into the block core.

Tested-by: Shiva Krishna Merla <shivakrishna.merla@netapp.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
diff 0ce65797 Wed Feb 25 22:50:28 MST 2015 Mike Snitzer <snitzer@redhat.com> dm: impose configurable deadline for dm_request_fn's merge heuristic

Otherwise, for sequential workloads, the dm_request_fn can allow
excessive request merging at the expense of increased service time.

Add a per-device sysfs attribute to allow the user to control how long a
request, that is a reasonable merge candidate, can be queued on the
request queue. The resolution of this request dispatch deadline is in
microseconds (ranging from 1 to 100000 usecs), to set a 20us deadline:
echo 20 > /sys/block/dm-7/dm/rq_based_seq_io_merge_deadline

The dm_request_fn's merge heuristic and associated extra accounting is
disabled by default (rq_based_seq_io_merge_deadline is 0).

This sysfs attribute is not applicable to bio-based DM devices so it
will only ever report 0 for them.

By allowing a request to remain on the queue it will block others
requests on the queue. But introducing a short dequeue delay has proven
very effective at enabling certain sequential IO workloads on really
fast, yet IOPS constrained, devices to build up slightly larger IOs --
yielding 90+% throughput improvements. Having precise control over the
time taken to wait for larger requests to build affords control beyond
that of waiting for certain IO sizes to accumulate (which would require
a deadline anyway). This knob will only ever make sense with sequential
IO workloads and the particular value used is storage configuration
specific.

Given the expected niche use-case for when this knob is useful it has
been deemed acceptable to expose this relatively crude method for
crafting optimal IO on specific storage -- especially given the solution
is simple yet effective. In the context of DM multipath, it is
advisable to tune this sysfs attribute to a value that offers the best
performance for the common case (e.g. if 4 paths are expected active,
tune for that; if paths fail then performance may be slightly reduced).

Alternatives were explored to have request-based DM autotune this value
(e.g. if/when paths fail) but they were quickly deemed too fragile and
complex to warrant further design and development time. If this problem
proves more common as faster storage emerges we'll have to look at
elevating a generic solution into the block core.

Tested-by: Shiva Krishna Merla <shivakrishna.merla@netapp.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
H A Dsysfs-bus-iio-potentiometer-mcp45312704e300 Mon Nov 07 16:58:53 MST 2016 Peter Rosin <peda@axentia.se> iio: mcp4531: provide range of available raw values

Example:

$ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available'
[0 1 256]

Meaning: min 0, step 1 and max 256.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2704e300 Mon Nov 07 16:58:53 MST 2016 Peter Rosin <peda@axentia.se> iio: mcp4531: provide range of available raw values

Example:

$ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available'
[0 1 256]

Meaning: min 0, step 1 and max 256.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
H A Dsysfs-bus-pci-drivers-janz-cmodio0d1802ef Tue May 05 12:08:34 MDT 2015 Andreas Gröger <andreas24groeger@gmail.com> can: janz-ican3: add documentation for existing sysfs entries

This patch adds documentation for the existing sysfs entries for the janz PCI
module.

Signed-off-by: Andreas Gröger <andreas24groeger@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
H A Dsysfs-bus-usb-lvstestdiff f624ec70 Wed Aug 23 01:35:30 MDT 2017 Jack Pham <jackp@codeaurora.org> usb: misc: lvstest: add entry to place port in compliance mode

Add support for the SuperSpeed Link Layer test case TD.7.34
which requires the operator to place the port into compliance
mode, and to subsequently bring it out via reset. Historically
according to the (now deprecated) USB 3.0 specification a
SuperSpeed host downstream port would automatically transition
to Compliance mode from the Polling state if LFPS polling times
out. However the language in USB 3.1 as well as xHCI 1.1 states
it may be required to explicitly enable this transition. For
such hosts this is done by sending a SET_FEATURE(PORT_LINK_STATE)
with the state set to Compliance to the root hub port.

Similar to the other supported commands, to do this via sysfs:

echo > /sys/bus/usb/devices/2-0\:1.0/enable_compliance

According to xHCI 1.1 section 4.19.1.2.4.1, this enables the
transition to compliance mode upon LFPS timeout. Note that this
can only be issued when the port is in disconnected state. And
in order to disable this behavior on subsequent transitions, a
warm reset should be issued. So add another entry to do that:

echo > /sys/bus/usb/devices/2-0\:1.0/warm_reset

In general these attributes can also be useful for other USB
SuperSpeed compliance tests such as electrical and eye diagram
testing which require CPn patterns to be transmitted.

Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff f624ec70 Wed Aug 23 01:35:30 MDT 2017 Jack Pham <jackp@codeaurora.org> usb: misc: lvstest: add entry to place port in compliance mode

Add support for the SuperSpeed Link Layer test case TD.7.34
which requires the operator to place the port into compliance
mode, and to subsequently bring it out via reset. Historically
according to the (now deprecated) USB 3.0 specification a
SuperSpeed host downstream port would automatically transition
to Compliance mode from the Polling state if LFPS polling times
out. However the language in USB 3.1 as well as xHCI 1.1 states
it may be required to explicitly enable this transition. For
such hosts this is done by sending a SET_FEATURE(PORT_LINK_STATE)
with the state set to Compliance to the root hub port.

Similar to the other supported commands, to do this via sysfs:

echo > /sys/bus/usb/devices/2-0\:1.0/enable_compliance

According to xHCI 1.1 section 4.19.1.2.4.1, this enables the
transition to compliance mode upon LFPS timeout. Note that this
can only be issued when the port is in disconnected state. And
in order to disable this behavior on subsequent transitions, a
warm reset should be issued. So add another entry to do that:

echo > /sys/bus/usb/devices/2-0\:1.0/warm_reset

In general these attributes can also be useful for other USB
SuperSpeed compliance tests such as electrical and eye diagram
testing which require CPn patterns to be transmitted.

Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce21bfe6 Mon Jul 14 07:57:49 MDT 2014 Pratyush Anand <pratyush.anand@gmail.com> USB: Add LVS Test device driver

OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests. Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then write Linux Foundation's vendor ID which is used by root hubs and
SS root hub's device ID into new_id file. Writing IDs into new_id file
will also bind the lvs driver with any available SS root hub interfaces.

echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.

Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H A Dsysfs-bus-vmbusd765edbb Fri Aug 10 17:06:08 MDT 2018 Stephen Hemminger <stephen@networkplumber.org> vmbus: add driver_override support

Add support for overriding the default driver for a VMBus device
in the same way that it can be done for PCI devices. This patch
adds the /sys/bus/vmbus/devices/.../driver_override file
and the logic for matching.

This is used by driverctl tool to do driver override.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fdriverctl%2Fdriverctl&amp;data=02%7C01%7Ckys%40microsoft.com%7C42e803feb2c544ef6ea908d5fd538878%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636693457619960040&amp;sdata=kEyYHRIjNZCk%2B37moCSqbrZL426YccNQrsWpENcrZdw%3D&amp;reserved=0

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H A Dsysfs-class-iommu-intel-iommua5459cfe Thu Jun 12 16:12:31 MDT 2014 Alex Williamson <alex.williamson@redhat.com> iommu/vt-d: Make use of IOMMU sysfs support

Register our DRHD IOMMUs, cross link devices, and provide a base set
of attributes for the IOMMU. Note that IRQ remapping support parses
the DMAR table very early in boot, well before the iommu_class can
reasonably be setup, so our registration is split between
intel_iommu_init(), which occurs later, and alloc_iommu(), which
typically occurs much earlier, but may happen at any time later
with IOMMU hot-add support.

On a typical desktop system, this provides the following (pruned):

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
/sys/devices/virtual/iommu/dmar0/devices
/sys/devices/virtual/iommu/dmar0/devices/0000:00:02.0
/sys/devices/virtual/iommu/dmar0/intel-iommu
/sys/devices/virtual/iommu/dmar0/intel-iommu/cap
/sys/devices/virtual/iommu/dmar0/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar0/intel-iommu/address
/sys/devices/virtual/iommu/dmar0/intel-iommu/version
/sys/devices/virtual/iommu/dmar1
/sys/devices/virtual/iommu/dmar1/devices
/sys/devices/virtual/iommu/dmar1/devices/0000:00:00.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:01.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:16.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1a.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1b.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1c.0
...
/sys/devices/virtual/iommu/dmar1/intel-iommu
/sys/devices/virtual/iommu/dmar1/intel-iommu/cap
/sys/devices/virtual/iommu/dmar1/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar1/intel-iommu/address
/sys/devices/virtual/iommu/dmar1/intel-iommu/version
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1

(devices also link back to the dmar units)

This makes address, version, capabilities, and extended capabilities
available, just like printed on boot. I've tried not to duplicate
data that can be found in the DMAR table, with the exception of the
address, which provides an easy way to associate the sysfs device with
a DRHD entry in the DMAR. It's tempting to add scopes and RMRR data
here, but the full DMAR table is already exposed under /sys/firmware/
and therefore already provides a way for userspace to learn such
details.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
a5459cfe Thu Jun 12 16:12:31 MDT 2014 Alex Williamson <alex.williamson@redhat.com> iommu/vt-d: Make use of IOMMU sysfs support

Register our DRHD IOMMUs, cross link devices, and provide a base set
of attributes for the IOMMU. Note that IRQ remapping support parses
the DMAR table very early in boot, well before the iommu_class can
reasonably be setup, so our registration is split between
intel_iommu_init(), which occurs later, and alloc_iommu(), which
typically occurs much earlier, but may happen at any time later
with IOMMU hot-add support.

On a typical desktop system, this provides the following (pruned):

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
/sys/devices/virtual/iommu/dmar0/devices
/sys/devices/virtual/iommu/dmar0/devices/0000:00:02.0
/sys/devices/virtual/iommu/dmar0/intel-iommu
/sys/devices/virtual/iommu/dmar0/intel-iommu/cap
/sys/devices/virtual/iommu/dmar0/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar0/intel-iommu/address
/sys/devices/virtual/iommu/dmar0/intel-iommu/version
/sys/devices/virtual/iommu/dmar1
/sys/devices/virtual/iommu/dmar1/devices
/sys/devices/virtual/iommu/dmar1/devices/0000:00:00.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:01.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:16.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1a.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1b.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1c.0
...
/sys/devices/virtual/iommu/dmar1/intel-iommu
/sys/devices/virtual/iommu/dmar1/intel-iommu/cap
/sys/devices/virtual/iommu/dmar1/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar1/intel-iommu/address
/sys/devices/virtual/iommu/dmar1/intel-iommu/version
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1

(devices also link back to the dmar units)

This makes address, version, capabilities, and extended capabilities
available, just like printed on boot. I've tried not to duplicate
data that can be found in the DMAR table, with the exception of the
address, which provides an easy way to associate the sysfs device with
a DRHD entry in the DMAR. It's tempting to add scopes and RMRR data
here, but the full DMAR table is already exposed under /sys/firmware/
and therefore already provides a way for userspace to learn such
details.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
a5459cfe Thu Jun 12 16:12:31 MDT 2014 Alex Williamson <alex.williamson@redhat.com> iommu/vt-d: Make use of IOMMU sysfs support

Register our DRHD IOMMUs, cross link devices, and provide a base set
of attributes for the IOMMU. Note that IRQ remapping support parses
the DMAR table very early in boot, well before the iommu_class can
reasonably be setup, so our registration is split between
intel_iommu_init(), which occurs later, and alloc_iommu(), which
typically occurs much earlier, but may happen at any time later
with IOMMU hot-add support.

On a typical desktop system, this provides the following (pruned):

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
/sys/devices/virtual/iommu/dmar0/devices
/sys/devices/virtual/iommu/dmar0/devices/0000:00:02.0
/sys/devices/virtual/iommu/dmar0/intel-iommu
/sys/devices/virtual/iommu/dmar0/intel-iommu/cap
/sys/devices/virtual/iommu/dmar0/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar0/intel-iommu/address
/sys/devices/virtual/iommu/dmar0/intel-iommu/version
/sys/devices/virtual/iommu/dmar1
/sys/devices/virtual/iommu/dmar1/devices
/sys/devices/virtual/iommu/dmar1/devices/0000:00:00.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:01.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:16.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1a.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1b.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1c.0
...
/sys/devices/virtual/iommu/dmar1/intel-iommu
/sys/devices/virtual/iommu/dmar1/intel-iommu/cap
/sys/devices/virtual/iommu/dmar1/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar1/intel-iommu/address
/sys/devices/virtual/iommu/dmar1/intel-iommu/version
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1

(devices also link back to the dmar units)

This makes address, version, capabilities, and extended capabilities
available, just like printed on boot. I've tried not to duplicate
data that can be found in the DMAR table, with the exception of the
address, which provides an easy way to associate the sysfs device with
a DRHD entry in the DMAR. It's tempting to add scopes and RMRR data
here, but the full DMAR table is already exposed under /sys/firmware/
and therefore already provides a way for userspace to learn such
details.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
H A Dsysfs-class-net-janz-ican30d1802ef Tue May 05 12:08:34 MDT 2015 Andreas Gröger <andreas24groeger@gmail.com> can: janz-ican3: add documentation for existing sysfs entries

This patch adds documentation for the existing sysfs entries for the janz PCI
module.

Signed-off-by: Andreas Gröger <andreas24groeger@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
H A Dsysfs-class-powercap
H A Dsysfs-devices-firmware_noded1efe3c3 Tue Oct 02 00:43:23 MDT 2012 Lance Ortiz <lance.ortiz@hp.com> ACPI: Add new sysfs interface to export device description

Add support to export the device description obtained from the ACPI _STR
method, if one exists for a device, to user-space via a sysfs interface.
This new interface provides a standard and platform neutral way for users
to obtain the description text stored in the ACPI _STR method. If no
_STR method exists for the device, no sysfs 'description' file will be
created. The 'description' file will be located in the /sys/devices/
directory using the device's path.

/sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description

Example:

/sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description

It can also be located using the ACPI device path, for example:

/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description

Execute the 'cat' command on the 'description' file to obtain the
description string for that device.

This patch also includes documentation describing how the new sysfs
interface works

Changes from v1-v2 based on comments by Len Brown and Fengguang Wu
* Removed output "No Description" and leaving a NULL attribute if the
_STR method failed to evaluate.

* In acpi_device_remove_files() removed the redundent check of
dev->pnp.str_obj before calling free. This check triggered a message
from smatch.

Signed-off-by: Lance Ortiz <lance.ortiz@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
d1efe3c3 Tue Oct 02 00:43:23 MDT 2012 Lance Ortiz <lance.ortiz@hp.com> ACPI: Add new sysfs interface to export device description

Add support to export the device description obtained from the ACPI _STR
method, if one exists for a device, to user-space via a sysfs interface.
This new interface provides a standard and platform neutral way for users
to obtain the description text stored in the ACPI _STR method. If no
_STR method exists for the device, no sysfs 'description' file will be
created. The 'description' file will be located in the /sys/devices/
directory using the device's path.

/sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description

Example:

/sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description

It can also be located using the ACPI device path, for example:

/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description

Execute the 'cat' command on the 'description' file to obtain the
description string for that device.

This patch also includes documentation describing how the new sysfs
interface works

Changes from v1-v2 based on comments by Len Brown and Fengguang Wu
* Removed output "No Description" and leaving a NULL attribute if the
_STR method failed to evaluate.

* In acpi_device_remove_files() removed the redundent check of
dev->pnp.str_obj before calling free. This check triggered a message
from smatch.

Signed-off-by: Lance Ortiz <lance.ortiz@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
H A Dsysfs-driver-hid-picolcddiff 0b5adf92 Sun Apr 25 13:29:16 MDT 2010 Bruno Prémont <bonbons@linux-vserver.org> HID: split picolcd's operation_mode sysfs attribute

Original operation_mode sysfs attribute accepts the operation mode
as main value with an option delay as second value to change
the start-up delay on mode change.

As it is preferred to have exactly one value per sysfs attribute,
extract this delay into a separate sysfs attribute called
operation_mode_delay.

Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
H A Dsysfs-ibft138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
138fe4e0 Wed Apr 09 20:50:41 MDT 2008 Konrad Rzeszutek <ketuzsezr@darnok.org> Firmware: add iSCSI iBFT Support

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target. Currently the iSCSI
information is hard-coded in the initrd. The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H A Dsysfs-kernel-fscaps088ab0b4 Mon Feb 28 07:57:17 MST 2011 Ludwig Nussel <ludwig.nussel@suse.de> kernel/ksysfs.c: expose file_caps_enabled in sysfs

A kernel booted with no_file_caps allows to install fscaps on a binary
but doesn't actually honor the fscaps when running the binary. Userspace
currently has no sane way to determine whether installing fscaps
actually has any effect. Since parsing /proc/cmdline is fragile this
patch exposes the current setting (1 or 0) via /sys/kernel/fscaps

Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H A Dsysfs-kernel-irqecb3f394 Mon Sep 12 22:14:51 MDT 2016 Craig Gallek <kraig@google.com> genirq: Expose interrupt information through sysfs

Information about interrupts is exposed via /proc/interrupts, but the
format of that file has changed over kernel versions and differs across
architectures. It also has varying column numbers depending on hardware.

That all makes it hard for tools to parse.

To solve this, expose the information through sysfs so each irq attribute
is in a separate file in a consistent, machine parsable way.

This feature is only available when both CONFIG_SPARSE_IRQ and
CONFIG_SYSFS are enabled.

Examples:
/sys/kernel/irq/18/actions: i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7
/sys/kernel/irq/18/chip_name: IR-IO-APIC
/sys/kernel/irq/18/hwirq: 18
/sys/kernel/irq/18/name: fasteoi
/sys/kernel/irq/18/per_cpu_count: 0,0
/sys/kernel/irq/18/type: level

/sys/kernel/irq/25/actions: ahci0
/sys/kernel/irq/25/chip_name: IR-PCI-MSI
/sys/kernel/irq/25/hwirq: 512000
/sys/kernel/irq/25/name: edge
/sys/kernel/irq/25/per_cpu_count: 29036,0
/sys/kernel/irq/25/type: edge

[ tglx: Moved kobject_del() under sparse_irq_lock, massaged code comments
and changelog ]

Signed-off-by: Craig Gallek <kraig@google.com>
Cc: David Decotigny <decot@google.com>
Link: http://lkml.kernel.org/r/1473783291-122873-1-git-send-email-kraigatgoog@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
ecb3f394 Mon Sep 12 22:14:51 MDT 2016 Craig Gallek <kraig@google.com> genirq: Expose interrupt information through sysfs

Information about interrupts is exposed via /proc/interrupts, but the
format of that file has changed over kernel versions and differs across
architectures. It also has varying column numbers depending on hardware.

That all makes it hard for tools to parse.

To solve this, expose the information through sysfs so each irq attribute
is in a separate file in a consistent, machine parsable way.

This feature is only available when both CONFIG_SPARSE_IRQ and
CONFIG_SYSFS are enabled.

Examples:
/sys/kernel/irq/18/actions: i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7
/sys/kernel/irq/18/chip_name: IR-IO-APIC
/sys/kernel/irq/18/hwirq: 18
/sys/kernel/irq/18/name: fasteoi
/sys/kernel/irq/18/per_cpu_count: 0,0
/sys/kernel/irq/18/type: level

/sys/kernel/irq/25/actions: ahci0
/sys/kernel/irq/25/chip_name: IR-PCI-MSI
/sys/kernel/irq/25/hwirq: 512000
/sys/kernel/irq/25/name: edge
/sys/kernel/irq/25/per_cpu_count: 29036,0
/sys/kernel/irq/25/type: edge

[ tglx: Moved kobject_del() under sparse_irq_lock, massaged code comments
and changelog ]

Signed-off-by: Craig Gallek <kraig@google.com>
Cc: David Decotigny <decot@google.com>
Link: http://lkml.kernel.org/r/1473783291-122873-1-git-send-email-kraigatgoog@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
ecb3f394 Mon Sep 12 22:14:51 MDT 2016 Craig Gallek <kraig@google.com> genirq: Expose interrupt information through sysfs

Information about interrupts is exposed via /proc/interrupts, but the
format of that file has changed over kernel versions and differs across
architectures. It also has varying column numbers depending on hardware.

That all makes it hard for tools to parse.

To solve this, expose the information through sysfs so each irq attribute
is in a separate file in a consistent, machine parsable way.

This feature is only available when both CONFIG_SPARSE_IRQ and
CONFIG_SYSFS are enabled.

Examples:
/sys/kernel/irq/18/actions: i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7
/sys/kernel/irq/18/chip_name: IR-IO-APIC
/sys/kernel/irq/18/hwirq: 18
/sys/kernel/irq/18/name: fasteoi
/sys/kernel/irq/18/per_cpu_count: 0,0
/sys/kernel/irq/18/type: level

/sys/kernel/irq/25/actions: ahci0
/sys/kernel/irq/25/chip_name: IR-PCI-MSI
/sys/kernel/irq/25/hwirq: 512000
/sys/kernel/irq/25/name: edge
/sys/kernel/irq/25/per_cpu_count: 29036,0
/sys/kernel/irq/25/type: edge

[ tglx: Moved kobject_del() under sparse_irq_lock, massaged code comments
and changelog ]

Signed-off-by: Craig Gallek <kraig@google.com>
Cc: David Decotigny <decot@google.com>
Link: http://lkml.kernel.org/r/1473783291-122873-1-git-send-email-kraigatgoog@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
/linux-master/Documentation/
H A DCodingStylediff 0acbc6c6 Thu Jan 29 17:28:16 MST 2009 Teemu Likonen <tlikonen@iki.fi> Documentation: update CodingStyle tips for Emacs users

With the previous Emacs tips example the kernel style was made available
for files in the kernel-tree only. This patch updates the tip to add a
separate cc-mode indent style ("linux-tabs-only"). This makes it easy to
switch between different indent styles and also makes the kernel style
easily available for any filetype mode (c++, awk, ...) that is managed
by the Emacs cc-mode.

Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff c16a02d6 Fri Sep 29 03:01:21 MDT 2006 Alan Stern <stern@rowland.harvard.edu> [PATCH] Add section on function return values to CodingStyle

This patch (as776) adds a new chapter to Documentation/CodingStyle,
explaining the circumstances under which a function should return 0 for
failure and non-zero for success as opposed to a negative error code for
failure and 0 for success.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff c16a02d6 Fri Sep 29 03:01:21 MDT 2006 Alan Stern <stern@rowland.harvard.edu> [PATCH] Add section on function return values to CodingStyle

This patch (as776) adds a new chapter to Documentation/CodingStyle,
explaining the circumstances under which a function should return 0 for
failure and non-zero for success as opposed to a negative error code for
failure and 0 for success.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
H A DSubmittingPatchesdiff 0e4f07a6 Tue Oct 18 05:05:32 MDT 2016 Mauro Carvalho Chehab <mchehab@kernel.org> docs: rename development-process/ to process/

As we'll type this a lot, after adding CodingStyle & friends,
let's rename the directory name to a shorter one.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff 6ade9772 Sat Jul 18 06:31:40 MDT 2015 Benjamin Herr <ben@0x539.de> Doc: fix trivial typo in SubmittingPatches

This patch changes the tense of a verb in SubmittingPatches to ensure
grammatical validity of the containing sentence.

Signed-off-by: Benjamin Herr <ben@0x539.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
diff 6ade9772 Sat Jul 18 06:31:40 MDT 2015 Benjamin Herr <ben@0x539.de> Doc: fix trivial typo in SubmittingPatches

This patch changes the tense of a verb in SubmittingPatches to ensure
grammatical validity of the containing sentence.

Signed-off-by: Benjamin Herr <ben@0x539.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
diff 013542ca Sat Jul 18 06:31:40 MDT 2015 Benjamin Herr <ben@0x539.de> Doc: fix trivial typo in SubmittingPatches

This patch changes the tense of a verb in SubmittingPatches to ensure
grammatical validity of the containing sentence.

Signed-off-by: Benjamin Herr <ben@0x539.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
diff 013542ca Sat Jul 18 06:31:40 MDT 2015 Benjamin Herr <ben@0x539.de> Doc: fix trivial typo in SubmittingPatches

This patch changes the tense of a verb in SubmittingPatches to ensure
grammatical validity of the containing sentence.

Signed-off-by: Benjamin Herr <ben@0x539.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
diff 0eea2314 Tue Dec 23 08:52:01 MST 2014 Jonathan Corbet <corbet@lwn.net> Docs: SubmittingPatches: update follow-through instructions

SubmittingPatches was written in the "keep sending to Linus until something
shows up in a release" era. Given that we don't do things that way anymore
and the system is far less lossy, update this information and add some
hints on responding to reviewer comments.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
diff 0af52703 Wed Jul 31 15:59:38 MDT 2013 Geert Uytterhoeven <geert@linux-m68k.org> Documentation/SubmittingPatches: Request summaries for commit references

Request inclusion of oneline summaries when referring to other commits

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff 0f44cd23 Fri Jun 08 14:46:45 MDT 2007 Andrew Morton <akpm@linux-foundation.org> document Acked-by:

Explain what we use Acked-by: for, and how it differs from Signed-off-by:

Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff 0a920b5b Fri Jun 01 01:46:48 MDT 2007 Andy Whitcroft <apw@shadowen.org> add a trivial patch style checker

We are seeing increasing levels of minor patch style violations in submissions
to the mailing lists as well as making it into the tree. These detract from
the quality of the submission and cause unnessary work for reviewers.

As a first step package up the current state of the patch style checker and
include it in the kernel tree. Add instructions suggesting running it on
submissions. This adds version v0.01 of the checkpatch.pl script.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/linux-master/Documentation/admin-guide/laptops/
H A Dindex.rstdiff 7e042736 Fri Jun 28 04:13:34 MDT 2019 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> docs: add SPDX tags to new index files

All those new files I added are under GPL v2.0 license.

Add the corresponding SPDX headers to them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
/linux-master/Documentation/admin-guide/namespaces/
H A Dindex.rstdiff 7e042736 Fri Jun 28 04:13:34 MDT 2019 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> docs: add SPDX tags to new index files

All those new files I added are under GPL v2.0 license.

Add the corresponding SPDX headers to them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
/linux-master/Documentation/admin-guide/pm/
H A Dindex.rstdiff 0c0b6b7b Mon Aug 21 07:14:56 MDT 2017 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM: docs: Describe high-level PM strategies and sleep states

Reorganize the power management part of admin-guide by adding a
description of major power management strategies supported by the
kernel (system-wide and working-state power management) to it and
dividing the rest of the material into the system-wide PM and
working-state PM chapters.

On top of that, add a description of system sleep states to the
system-wide PM chapter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
H A Dintel_epb.rst5861381d Thu Mar 21 16:18:01 MDT 2019 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling

The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.

The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation). However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.

The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition. Again, that behavior may at least be confusing
from the user space perspective.

In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.

However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.

While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.

Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
5861381d Thu Mar 21 16:18:01 MDT 2019 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling

The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.

The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation). However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.

The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition. Again, that behavior may at least be confusing
from the user space perspective.

In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.

However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.

While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.

Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
5861381d Thu Mar 21 16:18:01 MDT 2019 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling

The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.

The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation). However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.

The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition. Again, that behavior may at least be confusing
from the user space perspective.

In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.

However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.

While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.

Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
H A Dstrategies.rst0c0b6b7b Mon Aug 21 07:14:56 MDT 2017 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM: docs: Describe high-level PM strategies and sleep states

Reorganize the power management part of admin-guide by adding a
description of major power management strategies supported by the
kernel (system-wide and working-state power management) to it and
dividing the rest of the material into the system-wide PM and
working-state PM chapters.

On top of that, add a description of system sleep states to the
system-wide PM chapter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
/linux-master/Documentation/devicetree/bindings/arc/
H A Dhsdk.txta518d637 Tue Aug 15 12:13:55 MDT 2017 Alexey Brodkin <abrodkin@synopsys.com> ARC: [plat-hsdk] initial port for HSDK board

This initial port adds support of ARC HS Development Kit board with some
basic features such serial port, USB, SD/MMC and Ethernet.

Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
heavily use IO Coherency for speeding-up DMA-aware peripherals.

Note as opposed to other ARC boards we link Linux kernel to
0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
situated at our more usual link base 0x8000_0000. We still can use
memory region starting at 0x8000_0000 as we reallocate DCCM in our
platform code.

Note that PAE remapping for DMA clients does not work due to an RTL bug,
so CREG_PAE register must be programmed to all zeroes, otherwise it will
cause problems with DMA to/from peripherals even if PAE40 is not used.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
a518d637 Tue Aug 15 12:13:55 MDT 2017 Alexey Brodkin <abrodkin@synopsys.com> ARC: [plat-hsdk] initial port for HSDK board

This initial port adds support of ARC HS Development Kit board with some
basic features such serial port, USB, SD/MMC and Ethernet.

Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
heavily use IO Coherency for speeding-up DMA-aware peripherals.

Note as opposed to other ARC boards we link Linux kernel to
0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
situated at our more usual link base 0x8000_0000. We still can use
memory region starting at 0x8000_0000 as we reallocate DCCM in our
platform code.

Note that PAE remapping for DMA clients does not work due to an RTL bug,
so CREG_PAE register must be programmed to all zeroes, otherwise it will
cause problems with DMA to/from peripherals even if PAE40 is not used.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
a518d637 Tue Aug 15 12:13:55 MDT 2017 Alexey Brodkin <abrodkin@synopsys.com> ARC: [plat-hsdk] initial port for HSDK board

This initial port adds support of ARC HS Development Kit board with some
basic features such serial port, USB, SD/MMC and Ethernet.

Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
heavily use IO Coherency for speeding-up DMA-aware peripherals.

Note as opposed to other ARC boards we link Linux kernel to
0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
situated at our more usual link base 0x8000_0000. We still can use
memory region starting at 0x8000_0000 as we reallocate DCCM in our
platform code.

Note that PAE remapping for DMA clients does not work due to an RTL bug,
so CREG_PAE register must be programmed to all zeroes, otherwise it will
cause problems with DMA to/from peripherals even if PAE40 is not used.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
/linux-master/Documentation/devicetree/bindings/arm/marvell/
H A Darmada-39x.txtdiff 35664512 Wed Aug 03 16:14:20 MDT 2016 Grzegorz Jaszczyk <jaz@semihalf.com> ARM: dts: mvebu: armada-395-gp: add support for the Armada 395 GP Board

This commit adds description for the following features for this board:

- Serial port
- PCIe interfaces
- USB2.0
- USB3.0
- SDIO
- 1024 MiB NAND-FLASH
- SATA
- I2C buses

Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
diff 35664512 Wed Aug 03 16:14:20 MDT 2016 Grzegorz Jaszczyk <jaz@semihalf.com> ARM: dts: mvebu: armada-395-gp: add support for the Armada 395 GP Board

This commit adds description for the following features for this board:

- Serial port
- PCIe interfaces
- USB2.0
- USB3.0
- SDIO
- 1024 MiB NAND-FLASH
- SATA
- I2C buses

Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
diff eebead78 Wed Aug 03 16:14:16 MDT 2016 Grzegorz Jaszczyk <jaz@semihalf.com> ARM: dts: mvebu: armada-395: add support for the Armada 395 SoC family

Beside interfaces described in the armada-39x.dtsi, the Armada 395 SoC
family supports: 2 x SATA3 (2 ports in one unit) and the USB3.0

Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
/linux-master/Documentation/devicetree/bindings/arm/omap/
H A Dcrossbar.txtdiff 4c9847b7 Wed Nov 29 13:55:15 MST 2017 Mathieu Malaterre <malat@debian.org> dt-bindings: Remove leading 0x from bindings notation

Improve the binding example by removing all the leading 0x to fix the
following dtc warnings:

Warning (unit_address_format): Node /XXX unit name should not have leading "0x"

Converted using the following command:

find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +

This is a follow up to commit 48c926cd3414

Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff 4c9847b7 Wed Nov 29 13:55:15 MST 2017 Mathieu Malaterre <malat@debian.org> dt-bindings: Remove leading 0x from bindings notation

Improve the binding example by removing all the leading 0x to fix the
following dtc warnings:

Warning (unit_address_format): Node /XXX unit name should not have leading "0x"

Converted using the following command:

find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +

This is a follow up to commit 48c926cd3414

Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff 4c9847b7 Wed Nov 29 13:55:15 MST 2017 Mathieu Malaterre <malat@debian.org> dt-bindings: Remove leading 0x from bindings notation

Improve the binding example by removing all the leading 0x to fix the
following dtc warnings:

Warning (unit_address_format): Node /XXX unit name should not have leading "0x"

Converted using the following command:

find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +

This is a follow up to commit 48c926cd3414

Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff 4c9847b7 Wed Nov 29 13:55:15 MST 2017 Mathieu Malaterre <malat@debian.org> dt-bindings: Remove leading 0x from bindings notation

Improve the binding example by removing all the leading 0x to fix the
following dtc warnings:

Warning (unit_address_format): Node /XXX unit name should not have leading "0x"

Converted using the following command:

find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +

This is a follow up to commit 48c926cd3414

Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff 4c9847b7 Wed Nov 29 13:55:15 MST 2017 Mathieu Malaterre <malat@debian.org> dt-bindings: Remove leading 0x from bindings notation

Improve the binding example by removing all the leading 0x to fix the
following dtc warnings:

Warning (unit_address_format): Node /XXX unit name should not have leading "0x"

Converted using the following command:

find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +

This is a follow up to commit 48c926cd3414

Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Rob Herring <robh@kernel.org>
diff d360892d Wed Jun 25 13:10:34 MDT 2014 Nishanth Menon <nm@ti.com> irqchip: crossbar: Allow for quirky hardware with direct hardwiring of GIC

On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in our
description of the hardware with SKIP and RESERVED where appropriate.

Unfortunately, we need to be able to refer to these hardwired IRQs.
So, to request these, crossbar driver can use the existing information
from it's table that these SKIP/RESERVED maps are direct wired sources
and generic allocation/programming of crossbar should be avoided.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-17-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
diff a35057d1 Wed Jun 25 13:10:22 MDT 2014 Nishanth Menon <nm@ti.com> irqchip: crossbar: Initialise the crossbar with a safe value

Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value must be written to
ensure that the crossbar mapping matches with interrupt controller
usage.

So provide a safe value in the dt data to map if
'0' is not safe for the platform and use it during init and unmap

While at this, fix the below checkpatch warning.
Fixes checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#37: FILE: drivers/irqchip/irq-crossbar.c:37:
+ void (*write) (int, int);

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Link: https://lkml.kernel.org/r/1403766634-18543-5-git-send-email-r.sricharan@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
H A Dl3-noc.txtdiff 53a848be Thu Apr 10 10:33:13 MDT 2014 Rajendra Nayak <rnayak@ti.com> bus: omap_l3_noc: Add DRA7 interconnect error data

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
<0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
<0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
diff 53a848be Thu Apr 10 10:33:13 MDT 2014 Rajendra Nayak <rnayak@ti.com> bus: omap_l3_noc: Add DRA7 interconnect error data

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
<0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
<0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
diff 53a848be Thu Apr 10 10:33:13 MDT 2014 Rajendra Nayak <rnayak@ti.com> bus: omap_l3_noc: Add DRA7 interconnect error data

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
<0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
<0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
diff 53a848be Thu Apr 10 10:33:13 MDT 2014 Rajendra Nayak <rnayak@ti.com> bus: omap_l3_noc: Add DRA7 interconnect error data

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
<0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
<0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
/linux-master/Documentation/devicetree/bindings/bus/
H A Dbrcm,bus-axi.txt23a71fd6 Fri Mar 20 19:06:22 MDT 2015 Scott Branden <sbranden@broadcom.com> dt-bindings: brcm: rationalize Broadcom documentation naming

This patchset attempts to standardize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.

Although there are no guidelines currently present for how to name
the dt-bindings document the "vendor,binding.txt" style is in use by
some of the other vendors.

Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Rob Herring <robh@kernel.org>

Completed in 447 milliseconds

1234567891011>>