Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.
> (also, did I send the v3 patch series threaded correctly?) Yes, that worked. Thanks! Things to improve there: I was both in To: and CC: field, so I got mails twice. Jean was missing completely. signature.asc Description: PGP signature
[PATCH v3 5/5] FireWire: add driver-api Introduction section
From: Takashi Sakamoto Replace the Introduction section's TBD with some useful overview text. Signed-off-by: Takashi Sakamoto Signed-off-by: Randy Dunlap Acked-by: Randy Dunlap Tested-by: Randy Dunlap To: linux1394-de...@lists.sourceforge.net Cc: Stefan Richter Cc: Takashi Sakamoto Cc: linux-doc@vger.kernel.org Cc: Randy Dunlap --- Documentation/driver-api/firewire.rst | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) --- linux-next-20180413.orig/Documentation/driver-api/firewire.rst +++ linux-next-20180413/Documentation/driver-api/firewire.rst @@ -5,17 +5,33 @@ Firewire (IEEE 1394) driver Interface Gu Introduction and Overview = -TBD +The Linux FireWire subsystem adds some interfaces into the Linux system +to use/maintain any resource on the IEEE 1394 bus. + +The main purpose of these interfaces is to access address space on each node +on the IEEE 1394 bus by ISO/IEC 13213 (IEEE 1212) procedure, and to control +isochronous resources on the bus by IEEE 1394 procedure. + +Two types of interfaces are added, according to consumers of the interface. A +set of userspace interfaces is available via `firewire character devices`. A set +of kernel interfaces is available via exported symbols in the `firewire-core` +module. Firewire char device data structures +.. include:: /ABI/stable/firewire-cdev +:literal: + .. kernel-doc:: include/uapi/linux/firewire-cdev.h :internal: Firewire device probing and sysfs interfaces +.. include:: /ABI/stable/sysfs-bus-firewire +:literal: + .. kernel-doc:: drivers/firewire/core-device.c :export: -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] FireWire: add a Documentation driver-api chapter
From: Randy Dunlap Add a basic Firewire/IEEE 1394 driver API chapter to the Linux kernel documentation. Signed-off-by: Randy Dunlap To: linux1394-de...@lists.sourceforge.net Cc: Stefan Richter Cc: Takashi Sakamoto Cc: linux-doc@vger.kernel.org Cc: Randy Dunlap --- v2: drop final blank line; in Cc:, change tab to space; Documentation/driver-api/firewire.rst | 32 Documentation/driver-api/index.rst|1 2 files changed, 33 insertions(+) --- /dev/null +++ linux-next-20180413/Documentation/driver-api/firewire.rst @@ -0,0 +1,32 @@ +=== +Firewire (IEEE 1394) driver Interface Guide +=== + +Introduction and Overview += + +TBD + +Firewire char device data structures + + +.. kernel-doc:: include/uapi/linux/firewire-cdev.h +:internal: + +Firewire device probing and sysfs interfaces + + +.. kernel-doc:: drivers/firewire/core-device.c +:export: + +Firewire core transaction interfaces + + +.. kernel-doc:: drivers/firewire/core-transaction.c +:export: + +Firewire Isochronous I/O interfaces +=== + +.. kernel-doc:: drivers/firewire/core-iso.c + :export: --- linux-next-20180413.orig/Documentation/driver-api/index.rst +++ linux-next-20180413/Documentation/driver-api/index.rst @@ -27,6 +27,7 @@ available subsections can be seen below. iio/index input usb/index + firewire pci spi i2c -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] FireWire: clean up firewire-cdev.h kernel-doc
From: Randy Dunlap
Clean up kernel-doc warnings in so that
it can be added to a Firewire/IEEE 1394 driver-api chapter
without adding lots of noisy warnings to the documentation build.
Signed-off-by: Randy Dunlap
Cc: Stefan Richter
Cc: linux1394-de...@lists.sourceforge.net
Cc: Takashi Sakamoto
Cc: linux-doc@vger.kernel.org
Cc: Randy Dunlap
---
@linux-doc: The patch that adds Documentation/driver-api/firewire.rst
causes a warning in this header file, but I don't see where it is
coming from (this header file patch does not touch that area of the
file):
../include/uapi/linux/firewire-cdev.h:312: WARNING: Inline literal start-string
without end-string.
include/uapi/linux/firewire-cdev.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
--- linux-next-20180413.orig/include/uapi/linux/firewire-cdev.h
+++ linux-next-20180413/include/uapi/linux/firewire-cdev.h
@@ -47,11 +47,11 @@
#define FW_CDEV_EVENT_ISO_INTERRUPT_MULTICHANNEL 0x09
/**
- * struct fw_cdev_event_common - Common part of all fw_cdev_event_ types
+ * struct fw_cdev_event_common - Common part of all fw_cdev_event_* types
* @closure: For arbitrary use by userspace
- * @type: Discriminates the fw_cdev_event_ types
+ * @type: Discriminates the fw_cdev_event_* types
*
- * This struct may be used to access generic members of all fw_cdev_event_
+ * This struct may be used to access generic members of all fw_cdev_event_*
* types regardless of the specific type.
*
* Data passed in the @closure field for a request will be returned in the
@@ -123,7 +123,13 @@ struct fw_cdev_event_response {
/**
* struct fw_cdev_event_request - Old version of &fw_cdev_event_request2
+ * @closure: See &fw_cdev_event_common; set by %FW_CDEV_IOC_ALLOCATE ioctl
* @type: See &fw_cdev_event_common; always %FW_CDEV_EVENT_REQUEST
+ * @tcode: Transaction code of the incoming request
+ * @offset:The offset into the 48-bit per-node address space
+ * @handle:Reference to the kernel-side pending request
+ * @length:Data length, i.e. the request's payload size in bytes
+ * @data: Incoming data, if any
*
* This event is sent instead of &fw_cdev_event_request2 if the kernel or
* the client implements ABI version <= 3. &fw_cdev_event_request lacks
@@ -353,7 +359,7 @@ struct fw_cdev_event_phy_packet {
};
/**
- * union fw_cdev_event - Convenience union of fw_cdev_event_ types
+ * union fw_cdev_event - Convenience union of fw_cdev_event_* types
* @common:Valid for all types
* @bus_reset: Valid if @common.type == %FW_CDEV_EVENT_BUS_RESET
* @response: Valid if @common.type == %FW_CDEV_EVENT_RESPONSE
@@ -735,7 +741,7 @@ struct fw_cdev_set_iso_channels {
* @header:Header and payload in case of a transmit context.
*
* &struct fw_cdev_iso_packet is used to describe isochronous packet queues.
- * Use the FW_CDEV_ISO_ macros to fill in @control.
+ * Use the FW_CDEV_ISO_* macros to fill in @control.
* The @header array is empty in case of receive contexts.
*
* Context type %FW_CDEV_ISO_CONTEXT_TRANSMIT:
@@ -842,7 +848,7 @@ struct fw_cdev_queue_iso {
* the %FW_CDEV_ISO_SYNC bit set
* @tags: Tag filter bit mask. Only valid for isochronous reception.
* Determines the tag values for which packets will be accepted.
- * Use FW_CDEV_ISO_CONTEXT_MATCH_ macros to set @tags.
+ * Use FW_CDEV_ISO_CONTEXT_MATCH_* macros to set @tags.
* @handle:Isochronous context handle within which to transmit or receive
*/
struct fw_cdev_start_iso {
@@ -1009,8 +1015,8 @@ struct fw_cdev_send_stream_packet {
* on the same card as this device. After transmission, an
* %FW_CDEV_EVENT_PHY_PACKET_SENT event is generated.
*
- * The payload @data[] shall be specified in host byte order. Usually,
- * @data[1] needs to be the bitwise inverse of @data[0]. VersaPHY packets
+ * The payload @data\[\] shall be specified in host byte order. Usually,
+ * @data\[1\] needs to be the bitwise inverse of @data\[0\]. VersaPHY packets
* are an exception to this rule.
*
* The ioctl is only permitted on device files which represent a local node.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] FireWire: clean up core-transaction.c kernel-doc
From: Randy Dunlap
Clean up kernel-doc warnings in
so that it can be added to a Firewire/IEEE 1394 driver-api chapter
without adding lots of noisy warnings to the documentation build.
Signed-off-by: Randy Dunlap
To: linux1394-de...@lists.sourceforge.net
Cc: Stefan Richter
Cc: Takashi Sakamoto
Cc: linux-doc@vger.kernel.org
Cc: Randy Dunlap
---
drivers/firewire/core-transaction.c | 10 ++
1 file changed, 10 insertions(+)
--- linux-next-20180413.orig/drivers/firewire/core-transaction.c
+++ linux-next-20180413/drivers/firewire/core-transaction.c
@@ -410,6 +410,14 @@ static void transaction_callback(struct
/**
* fw_run_transaction() - send request and sleep until transaction is completed
+ * @card: card interface for this request
+ * @tcode: transaction code
+ * @destination_id:destination node ID, consisting of bus_ID and phy_ID
+ * @generation:bus generation in which request and response
are valid
+ * @speed: transmission speed
+ * @offset:48bit wide offset into destination's address space
+ * @payload: data payload for the request subaction
+ * @length:length of the payload, in bytes
*
* Returns the RCODE. See fw_send_request() for parameter documentation.
* Unlike fw_send_request(), @data points to the payload of the request or/and
@@ -604,6 +612,7 @@ EXPORT_SYMBOL(fw_core_add_address_handle
/**
* fw_core_remove_address_handler() - unregister an address handler
+ * @handler: callback
*
* To be called in process context.
*
@@ -828,6 +837,7 @@ EXPORT_SYMBOL(fw_send_response);
/**
* fw_get_request_speed() - returns speed at which the @request was received
+ * @request: firewire request data
*/
int fw_get_request_speed(struct fw_request *request)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] FireWire: clean up kernel-doc, add Documentation chapter
This patch series cleans up kernel-doc warnings in several FireWire source files and then adds a Documentation driver-api chapter for FireWire. [PATCH v3 1/5] FireWire: clean up firewire-cdev.h kernel-doc [PATCH v3 2/5] FireWire: clean up core-iso.c kernel-doc [PATCH v3 3/5] FireWire: clean up core-transaction.c kernel-doc [PATCH v3 4/5] FireWire: add a Documentation driver-api chapter [PATCH v3 5/5] FireWire: add driver-api Introduction section Documentation/driver-api/firewire.rst | 50 +++- Documentation/driver-api/index.rst|1 drivers/firewire/core-iso.c |7 +++ drivers/firewire/core-transaction.c | 10 include/uapi/linux/firewire-cdev.h| 22 ++ 5 files changed, 81 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/5] FireWire: clean up core-iso.c kernel-doc
From: Randy Dunlap Clean up kernel-doc warnings in so that it can be added to a Firewire/IEEE 1394 driver-api chapter without adding lots of noisy warnings to the documentation build. Signed-off-by: Randy Dunlap To: linux1394-de...@lists.sourceforge.net Cc: Stefan Richter Cc: Takashi Sakamoto Cc: linux-doc@vger.kernel.org Cc: Randy Dunlap --- drivers/firewire/core-iso.c |7 +++ 1 file changed, 7 insertions(+) --- linux-next-20180413.orig/drivers/firewire/core-iso.c +++ linux-next-20180413/drivers/firewire/core-iso.c @@ -337,9 +337,16 @@ static void deallocate_channel(struct fw /** * fw_iso_resource_manage() - Allocate or deallocate a channel and/or bandwidth + * @card: card interface for this action + * @generation: bus generation + * @channels_mask: bitmask for channel allocation + * @channel: pointer for returning channel allocation result + * @bandwidth: pointer for returning bandwidth allocation result + * @allocate: whether to allocate (true) or deallocate (false) * * In parameters: card, generation, channels_mask, bandwidth, allocate * Out parameters: channel, bandwidth + * * This function blocks (sleeps) during communication with the IRM. * * Allocates or deallocates at most one channel out of channels_mask. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.
On Fri, Apr 13, 2018 at 11:49 AM, Jean Delvare wrote: > On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: >> On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: >> > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: >> >> > - Not meant to be called directly; instead, use the access functions >> >> > - below. >> >> > + If possible, use the provided i2c_smbus_* methods described below in >> >> > favor >> >> > + of issuing direct ioctls. >> >> >> >> Why this change? >> > >> > I'm also not sure if "in favor of" is right. "instead of" would sound >> > better to me, but I'm no native English speaker, I could be wrong. >> >> Sounds good, I'll adopt "instead of". Regarding Wolfram's earlier >> comment, as an engineer, requiring an out-of-tree library to build >> drivers felt a little off. I can revert this section if you want, >> just let me know. > > The i2c dev interface, and the overlaying library, are used by > user-space applications. This has nothing to do with "building > drivers", and makes your "out-of-tree" objection irrelevant. I doubt > libi2c is the only user-space library building on top of a kernel > interface. Ok, sounds good. I'll send a revised patch set reverting this block. (also, did I send the v3 patch series threaded correctly?) > > -- > Jean Delvare > SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/32] docs/vm: convert to ReST format
On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote: > > I believe that keeping the mm docs together will give better visibility of > > what (little) mm documentation we have and will make the updates easier. > > The documents that fit well into a certain topic could be linked there. For > > instance: > > ...but this sounds like just the opposite...? > > I've had this conversation with folks in a number of subsystems. > Everybody wants to keep their documentation together in one place - it's > easier for the developers after all. But for the readers I think it's > objectively worse. It perpetuates the mess that Documentation/ is, and > forces readers to go digging through all kinds of inappropriate material > in the hope of finding something that tells them what they need to know. > > So I would *really* like to split the documentation by audience, as has > been done for a number of other kernel subsystems (and eventually all, I > hope). > > I can go ahead and apply the RST conversion, that seems like a step in > the right direction regardless. But I sure hope we don't really have to > keep it as an unorganized jumble of stuff... I've started on Documentation/core-api/memory.rst which covers just memory allocation. So far it has the Overview and GFP flags sections written and an outline for 'The slab allocator', 'The page allocator', 'The vmalloc allocator' and 'The page_frag allocator'. And typing this up, I realise we need a 'The percpu allocator'. I'm thinking that this is *not* the right document for the DMA memory allocators (although it should link to that documentation). I suspect the existing Documentation/vm/ should probably stay as an unorganised jumble of stuff. Developers mostly talking to other MM developers. Stuff that people outside the MM fraternity should know about needs to be centrally documented. By all means convert it to ReST ... I don't much care, and it may make it easier to steal bits or link to it from the organised documentation. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/32] docs/vm: convert to ReST format
Sorry for the silence, I'm pedaling as fast as I can, honest... On Sun, 1 Apr 2018 09:38:58 +0300 Mike Rapoport wrote: > My thinking was to start with mechanical RST conversion and then to start > working on the contents and ordering of the documentation. Some of the > existing files, e.g. ksm.txt, can be moved as is into the appropriate > places, others, like transhuge.txt should be at least split into admin/user > and developer guides. > > Another problem with many of the existing mm docs is that they are rather > developer notes and it wouldn't be really straight forward to assign them > to a particular topic. All this sounds good. > I believe that keeping the mm docs together will give better visibility of > what (little) mm documentation we have and will make the updates easier. > The documents that fit well into a certain topic could be linked there. For > instance: ...but this sounds like just the opposite...? I've had this conversation with folks in a number of subsystems. Everybody wants to keep their documentation together in one place - it's easier for the developers after all. But for the readers I think it's objectively worse. It perpetuates the mess that Documentation/ is, and forces readers to go digging through all kinds of inappropriate material in the hope of finding something that tells them what they need to know. So I would *really* like to split the documentation by audience, as has been done for a number of other kernel subsystems (and eventually all, I hope). I can go ahead and apply the RST conversion, that seems like a step in the right direction regardless. But I sure hope we don't really have to keep it as an unorganized jumble of stuff... Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: ftrace: clarify filters with dynamic ftrace and graph
On Fri, 13 Apr 2018 11:54:03 -0400 Steven Rostedt wrote: > Jon, you want to take it in your tree? Sure, I'll grab it. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.
On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: > On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: > >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: > >> > - Not meant to be called directly; instead, use the access functions > >> > - below. > >> > + If possible, use the provided i2c_smbus_* methods described below in > >> > favor > >> > + of issuing direct ioctls. > >> > >> Why this change? > > > > I'm also not sure if "in favor of" is right. "instead of" would sound > > better to me, but I'm no native English speaker, I could be wrong. > > Sounds good, I'll adopt "instead of". Regarding Wolfram's earlier > comment, as an engineer, requiring an out-of-tree library to build > drivers felt a little off. I can revert this section if you want, > just let me know. The i2c dev interface, and the overlaying library, are used by user-space applications. This has nothing to do with "building drivers", and makes your "out-of-tree" objection irrelevant. I doubt libi2c is the only user-space library building on top of a kernel interface. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC bpf-next v2 4/8] bpf: add documentation for eBPF helpers (23-32)
2018-04-12 17:28 UTC-0700 ~ Alexei Starovoitov
> On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
>> Add documentation for eBPF helper functions to bpf.h user header file.
>> This documentation can be parsed with the Python script provided in
>> another commit of the patch series, in order to provide a RST document
>> that can later be converted into a man page.
>>
>> The objective is to make the documentation easily understandable and
>> accessible to all eBPF developers, including beginners.
>>
>> This patch contains descriptions for the following helper functions, all
>> written by Daniel:
>>
>> - bpf_get_prandom_u32()
>> - bpf_get_smp_processor_id()
>> - bpf_get_cgroup_classid()
>> - bpf_get_route_realm()
>> - bpf_skb_load_bytes()
>> - bpf_csum_diff()
>> - bpf_skb_get_tunnel_opt()
>> - bpf_skb_set_tunnel_opt()
>> - bpf_skb_change_proto()
>> - bpf_skb_change_type()
>>
>> Cc: Daniel Borkmann
>> Signed-off-by: Quentin Monnet
>> ---
>> include/uapi/linux/bpf.h | 125
>> +++
>> 1 file changed, 125 insertions(+)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index f3ea8824efbc..d147d9dd6a83 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
[...]
>> @@ -604,6 +612,13 @@ union bpf_attr {
>> * Return
>> * 0 on success, or a negative error in case of failure.
>> *
>> + * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
>> + * Description
>> + * Retrieve the classid for the current task, i.e. for the
>> + * net_cls (network classifier) cgroup to which *skb* belongs.
>
> please add that kernel should be configured with CONFIG_NET_CLS_CGROUP=y|m
> and mention Documentation/cgroup-v1/net_cls.txt
Ok.
> Otherwise 'network classifier' is way too generic.
I am not so familiar with cgroups. What would you suggest instead?
> I'd also mention that placing a task into net_cls controller
> disables all of cgroup-bpf.
Could you please explain a bit more? Placing a task into the controller
is using:
echo > /sys/fs/cgroup//tasks
correct? Then if I do this, it disables all of cgroup-bpf. Does this
mean that I loose the possibility to use or add BPF programs to all
cgroup-related attach points for this cgroup? I think I missed something
here.
>> + * Return
>> + * The classid, or 0 for the default unconfigured classid.
>> + *
>> * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16
>> vlan_tci)
>> * Description
>> * Push a *vlan_tci* (VLAN tag control information) of protocol
I have no particular comments on the other items you reported on this
patch, I will fix them. Thanks!
Quentin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] Documentation/i2c: sync docs with current state of i2c-tools
Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* helper routines as static inlined functions provided by linux/i2c-dev.h. Work has been done to refactor the linux/i2c-dev.h file in the i2c-tools project out into its own library. As a result, these docs have become stale. This patch corrects the discrepancy and directs the reader to the i2c-tools project for more information. Signed-off-by: Sam Hansen --- No changes from v2. Documentation/i2c/dev-interface | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface index c8737d502791..f92ee1f59914 100644 --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -23,11 +23,6 @@ First, you need to include these two headers: #include #include -(Please note that there are two files named "i2c-dev.h" out there. One is -distributed with the Linux kernel and the other one is included in the -source tree of i2c-tools. They used to be different in content but since 2012 -they're identical. You should use "linux/i2c-dev.h"). - Now, you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this. Adapter numbers are assigned somewhat dynamically, so you can not @@ -140,8 +135,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset) set in each message, overriding the values set with the above ioctl's. ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args) - Not meant to be called directly; instead, use the access functions - below. + If possible, use the provided i2c_smbus_* methods described below instead + of issuing direct ioctls. You can do plain i2c transactions by using read(2) and write(2) calls. You do not need to pass the address byte; instead, set it through @@ -166,10 +161,9 @@ what happened. The 'write' transactions return 0 on success; the returns the number of values read. The block buffers need not be longer than 32 bytes. -The above functions are all inline functions, that resolve to calls to -the i2c_smbus_access function, that on its turn calls a specific ioctl -with the data in a specific format. Read the source code if you -want to know what happens behind the screens. +The above functions are made available by linking against the libi2c library, +which is provided by the i2c-tools project. See: +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/. Implementation details -- 2.17.0.484.g0c8726318c-goog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] Documentation/i2c: adopt kernel commenting style in examples
The example I2C code is rewritten to adopt the preferred kernel block commenting style. Signed-off-by: Sam Hansen --- Changes from v2: 1. only the block comment is updated. 2. one-line comments are reverted to prior form. Documentation/i2c/dev-interface | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface index f92ee1f59914..fbed645ccd75 100644 --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -67,8 +67,10 @@ the device supports them. Both are illustrated below. /* res contains the read word */ } - /* Using I2C Write, equivalent of - i2c_smbus_write_word_data(file, reg, 0x6543) */ + /* + * Using I2C Write, equivalent of + * i2c_smbus_write_word_data(file, reg, 0x6543) + */ buf[0] = reg; buf[1] = 0x43; buf[2] = 0x65; -- 2.17.0.484.g0c8726318c-goog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] Documentation/i2c: whitespace cleanup
This strips trailing whitespace in Documentation/i2c/dev-interface.
Signed-off-by: Sam Hansen
---
No changes from v2.
Documentation/i2c/dev-interface | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index d04e6e4964ee..c8737d502791 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,8 +9,8 @@ i2c adapters present on your system at a given time. i2cdetect
is part of
the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
@@ -38,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -72,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -147,7 +147,7 @@ You can do plain i2c transactions by using read(2) and
write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file smbus-protocol
+You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -158,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.17.0.484.g0c8726318c-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples
On Fri, Apr 13, 2018 at 9:50 AM, Wolfram Sang wrote: > >> - int adapter_nr = 2; /* probably dynamically determined */ > > Such comments are actually OK. Ah, gotcha. Thanks for the correction. Standby for revised patch set. > >> -/* ERROR HANDLING; you can check errno to see what went wrong */ > > Such as well. > >> - /* Using I2C Write, equivalent of >> - i2c_smbus_write_word_data(file, reg, 0x6543) */ >> + /* >> + * Using I2C Write, equivalent of >> + * i2c_smbus_write_word_data(file, reg, 0x6543). >> + */ > > This is the only broken one AFAICT. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples
> - int adapter_nr = 2; /* probably dynamically determined */ Such comments are actually OK. > -/* ERROR HANDLING; you can check errno to see what went wrong */ Such as well. > - /* Using I2C Write, equivalent of > - i2c_smbus_write_word_data(file, reg, 0x6543) */ > + /* > + * Using I2C Write, equivalent of > + * i2c_smbus_write_word_data(file, reg, 0x6543). > + */ This is the only broken one AFAICT. signature.asc Description: PGP signature
Re: [PATCH v2 2/3] Documentation/i2c: sync docs with current state of i2c-tools
On Fri, Apr 13, 2018 at 09:44:04AM -0700, Sam Hansen wrote: > Currently, Documentation/i2c/dev-interface describes the use of > i2c_smbus_* helper routines as static inlined functions provided by > linux/i2c-dev.h. Work has been done to refactor the linux/i2c-dev.h file > in the i2c-tools project out into its own library. As a result, these > docs have become stale. > > This patch corrects the discrepancy and directs the reader to the > i2c-tools project for more information. > > Signed-off-by: Sam Hansen Looks good to me as well. signature.asc Description: PGP signature
Re: [PATCH v2 1/3] Documentation/i2c: whitespace cleanup
On Fri, Apr 13, 2018 at 09:44:03AM -0700, Sam Hansen wrote: > This strips trailing whitespace in Documentation/i2c/dev-interface. > > Signed-off-by: Sam Hansen Looks good to me. But please send new series as seperate threads. signature.asc Description: PGP signature
[PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples
The example I2C code is rewritten to adopt the preferred kernel block
commenting style.
Signed-off-by: Sam Hansen
---
Documentation/i2c/dev-interface | 57 +
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index f92ee1f59914..e17f5814c199 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -30,24 +30,34 @@ assume much about them. They can even change from one boot
to the next.
Next thing, open the device file, as follows:
+ /*
+ * The adapter is probably dynamically determined.
+ */
int file;
- int adapter_nr = 2; /* probably dynamically determined */
+ int adapter_nr = 2;
char filename[20];
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
-/* ERROR HANDLING; you can check errno to see what went wrong */
+/*
+ * ERROR HANDLING; you can check errno to see what went wrong.
+ */
exit(1);
}
When you have opened the device, you must specify with what device
address you want to communicate:
- int addr = 0x40; /* The I2C address */
+ /*
+ * The I2C address.
+ */
+ int addr = 0x40;
if (ioctl(file, I2C_SLAVE, addr) < 0) {
-/* ERROR HANDLING; you can check errno to see what went wrong */
+/*
+ * ERROR HANDLING; you can check errno to see what went wrong.
+ */
exit(1);
}
@@ -55,32 +65,51 @@ Well, you are all set up now. You can now use SMBus
commands or plain
I2C to communicate with your device. SMBus commands are preferred if
the device supports them. Both are illustrated below.
- __u8 reg = 0x10; /* Device register to access */
+ /*
+ * The device register to access.
+ */
+ __u8 reg = 0x10;
__s32 res;
char buf[10];
- /* Using SMBus commands */
+ /*
+ * Using SMBus commands.
+ */
res = i2c_smbus_read_word_data(file, reg);
if (res < 0) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
} else {
-/* res contains the read word */
+/*
+ * res contains the read word.
+ */
}
- /* Using I2C Write, equivalent of
- i2c_smbus_write_word_data(file, reg, 0x6543) */
+ /*
+ * Using I2C Write, equivalent of
+ * i2c_smbus_write_word_data(file, reg, 0x6543).
+ */
buf[0] = reg;
buf[1] = 0x43;
buf[2] = 0x65;
if (write(file, buf, 3) != 3) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
}
- /* Using I2C Read, equivalent of i2c_smbus_read_byte(file) */
+ /*
+ * Using I2C Read, equivalent of i2c_smbus_read_byte(file).
+ */
if (read(file, buf, 1) != 1) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
} else {
-/* buf[0] contains the read byte */
+/*
+ * buf[0] contains the read byte.
+ */
}
Note that only a subset of the I2C and SMBus protocols can be achieved by
--
2.17.0.484.g0c8726318c-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] Documentation/i2c: sync docs with current state of i2c-tools
Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* helper routines as static inlined functions provided by linux/i2c-dev.h. Work has been done to refactor the linux/i2c-dev.h file in the i2c-tools project out into its own library. As a result, these docs have become stale. This patch corrects the discrepancy and directs the reader to the i2c-tools project for more information. Signed-off-by: Sam Hansen --- Documentation/i2c/dev-interface | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface index c8737d502791..f92ee1f59914 100644 --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -23,11 +23,6 @@ First, you need to include these two headers: #include #include -(Please note that there are two files named "i2c-dev.h" out there. One is -distributed with the Linux kernel and the other one is included in the -source tree of i2c-tools. They used to be different in content but since 2012 -they're identical. You should use "linux/i2c-dev.h"). - Now, you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this. Adapter numbers are assigned somewhat dynamically, so you can not @@ -140,8 +135,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset) set in each message, overriding the values set with the above ioctl's. ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args) - Not meant to be called directly; instead, use the access functions - below. + If possible, use the provided i2c_smbus_* methods described below instead + of issuing direct ioctls. You can do plain i2c transactions by using read(2) and write(2) calls. You do not need to pass the address byte; instead, set it through @@ -166,10 +161,9 @@ what happened. The 'write' transactions return 0 on success; the returns the number of values read. The block buffers need not be longer than 32 bytes. -The above functions are all inline functions, that resolve to calls to -the i2c_smbus_access function, that on its turn calls a specific ioctl -with the data in a specific format. Read the source code if you -want to know what happens behind the screens. +The above functions are made available by linking against the libi2c library, +which is provided by the i2c-tools project. See: +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/. Implementation details -- 2.17.0.484.g0c8726318c-goog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] Documentation/i2c: whitespace cleanup
This strips trailing whitespace in Documentation/i2c/dev-interface.
Signed-off-by: Sam Hansen
---
Documentation/i2c/dev-interface | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index d04e6e4964ee..c8737d502791 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,8 +9,8 @@ i2c adapters present on your system at a given time. i2cdetect
is part of
the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
@@ -38,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -72,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -147,7 +147,7 @@ You can do plain i2c transactions by using read(2) and
write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file smbus-protocol
+You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -158,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.17.0.484.g0c8726318c-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 02/10] PCI: cadence: Update cdns_pcie_ep_raise_irq function signature
On Tue, Apr 10 at 18.15, Gustavo Pimentel wrote:
> From: Gustavo Pimentel [mailto:gustavo.pimen...@synopsys.com]
> Changes the cdns_pcie_ep_raise_irq function signature, namely the
> interrupt_num variable type from u8 to u16 to accommodate the MSI-X
> maximum interrupts of 2048.
>
> Signed-off-by: Gustavo Pimentel
> ---
> drivers/pci/cadence/pcie-cadence-ep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c
> b/drivers/pci/cadence/pcie-cadence-ep.c
> index 3d8283e..6d6322c 100644
> --- a/drivers/pci/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -363,7 +363,7 @@ static int cdns_pcie_ep_send_msi_irq(struct
> cdns_pcie_ep *ep, u8 fn, }
>
> static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
> - enum pci_epc_irq_type type, u8
> interrupt_num)
> + enum pci_epc_irq_type type, u16
> interrupt_num)
> {
> struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>
> --
> 2.7.4
>
Acked-by: Alan Douglas
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.
On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: > Hi Wolfram, Sam, > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: >> > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* >> > helper routines as static inlined functions provided by linux/i2c-dev.h. >> > Work >> > has been done to refactor the linux/i2c-dev.h file in the i2c-tools project >> > out into its own library. As a result, these docs have become stale. >> >> Thanks for fixing this! >> >> > This patch corrects the discrepancy and directs the reader to the i2c-tools >> > project for more information. Additionally, some trailing-whitespace >> > cleanups >> > were made. >> >> Minor nit: Having the whitespace changes in a seperate patch is a tad >> easier to review. >> >> > - /* Using I2C Write, equivalent of >> > + /* Using I2C Write, equivalent of >> > i2c_smbus_write_word_data(file, reg, 0x6543) */ >> >> Maybe change to Kernel coding style comments while here? >> >> > - Not meant to be called directly; instead, use the access functions >> > - below. >> > + If possible, use the provided i2c_smbus_* methods described below in >> > favor >> > + of issuing direct ioctls. >> >> Why this change? > > I'm also not sure if "in favor of" is right. "instead of" would sound > better to me, but I'm no native English speaker, I could be wrong. Sounds good, I'll adopt "instead of". Regarding Wolfram's earlier comment, as an engineer, requiring an out-of-tree library to build drivers felt a little off. I can revert this section if you want, just let me know. > >> > -The above functions are all inline functions, that resolve to calls to >> > -the i2c_smbus_access function, that on its turn calls a specific ioctl >> > -with the data in a specific format. Read the source code if you >> > -want to know what happens behind the screens. >> > +The above functions are made available by linking against the libi2c >> > library, >> > +which is provided by the i2c-tools project. See: >> > +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/. >> >> This is fine with me. Maybe Jean has a comment on this? > > Fixing the documentation is always welcome, thanks Sam for stepping in. > However we really want separate patches for whitespace fixes and actual > contents change, as Wolfram already mentioned above. Will do! I'll send a v2 patch set, thanks. > > -- > Jean Delvare > SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: ftrace: clarify filters with dynamic ftrace and graph
On Fri, 13 Apr 2018 17:39:15 +0200 Steffen Maier wrote: > I fell into the trap of having set up function tracer with a very > limited filter and then switched over to function_graph and was > erroneously wondering why the latter did not trace what I expected, > which was the full unabridged graph recursion. > > Signed-off-by: Steffen Maier > Cc: Steven Rostedt Looks good. Reviewed-by: Steven Rostedt (VMware) > Cc: Ingo Molnar > Cc: Jonathan Corbet Jon, you want to take it in your tree? -- Steve > Cc: linux-doc@vger.kernel.org > --- > > Changes since v1: > Integrated review comments by Steven Rostedt > * less emotional phrasing > * also mention function profiling with set_ftrace_filter > (hopefully I got that right as I don't have experience with it) > > Documentation/trace/ftrace.rst | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst > index e45f0786f3f9..9bbd3aefadb2 100644 > --- a/Documentation/trace/ftrace.rst > +++ b/Documentation/trace/ftrace.rst > @@ -224,6 +224,8 @@ of ftrace. Here is a list of some of the key files: > has a side effect of enabling or disabling specific functions > to be traced. Echoing names of functions into this file > will limit the trace to only those functions. > + This influences the tracers "function" and "function_graph" > + and thus also function profiling (see "function_profile_enabled"). > > The functions listed in "available_filter_functions" are what > can be written into this file. > @@ -265,6 +267,8 @@ of ftrace. Here is a list of some of the key files: > Functions listed in this file will cause the function graph > tracer to only trace these functions and the functions that > they call. (See the section "dynamic ftrace" for more details). > + Note, set_ftrace_filter and set_ftrace_notrace still affects > + what functions are being traced. > >set_graph_notrace: > > @@ -277,7 +281,8 @@ of ftrace. Here is a list of some of the key files: > > This lists the functions that ftrace has processed and can trace. > These are the function names that you can pass to > - "set_ftrace_filter" or "set_ftrace_notrace". > + "set_ftrace_filter", "set_ftrace_notrace", > + "set_graph_function", or "set_graph_notrace". > (See the section "dynamic ftrace" below for more details.) > >dyn_ftrace_total_info: -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation: ftrace: clarify filters with dynamic ftrace and graph
I fell into the trap of having set up function tracer with a very limited filter and then switched over to function_graph and was erroneously wondering why the latter did not trace what I expected, which was the full unabridged graph recursion. Signed-off-by: Steffen Maier Cc: Steven Rostedt Cc: Ingo Molnar Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Changes since v1: Integrated review comments by Steven Rostedt * less emotional phrasing * also mention function profiling with set_ftrace_filter (hopefully I got that right as I don't have experience with it) Documentation/trace/ftrace.rst | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index e45f0786f3f9..9bbd3aefadb2 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -224,6 +224,8 @@ of ftrace. Here is a list of some of the key files: has a side effect of enabling or disabling specific functions to be traced. Echoing names of functions into this file will limit the trace to only those functions. + This influences the tracers "function" and "function_graph" + and thus also function profiling (see "function_profile_enabled"). The functions listed in "available_filter_functions" are what can be written into this file. @@ -265,6 +267,8 @@ of ftrace. Here is a list of some of the key files: Functions listed in this file will cause the function graph tracer to only trace these functions and the functions that they call. (See the section "dynamic ftrace" for more details). + Note, set_ftrace_filter and set_ftrace_notrace still affects + what functions are being traced. set_graph_notrace: @@ -277,7 +281,8 @@ of ftrace. Here is a list of some of the key files: This lists the functions that ftrace has processed and can trace. These are the function names that you can pass to - "set_ftrace_filter" or "set_ftrace_notrace". + "set_ftrace_filter", "set_ftrace_notrace", + "set_graph_function", or "set_graph_notrace". (See the section "dynamic ftrace" below for more details.) dyn_ftrace_total_info: -- 2.13.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: ftrace: clarify filters with dynamic ftrace and graph
On Fri, 13 Apr 2018 11:26:16 +0200 Steffen Maier wrote: > I fell into the trap of having set up function tracer with a very > limited filter and then switched over to function_graph and was > erroneously wondering why the latter did not trace what I expected, > which was the full unabridged graph recursion. I didn't realize that the documentation doesn't state this. I mention it in all my talks that talk about function and function_graph tracer and set_ftrace_filter. > > Signed-off-by: Steffen Maier > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: Jonathan Corbet > Cc: linux-doc@vger.kernel.org > --- > Documentation/trace/ftrace.rst | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst > index e45f0786f3f9..68835d062344 100644 > --- a/Documentation/trace/ftrace.rst > +++ b/Documentation/trace/ftrace.rst > @@ -224,6 +224,7 @@ of ftrace. Here is a list of some of the key files: > has a side effect of enabling or disabling specific functions > to be traced. Echoing names of functions into this file > will limit the trace to only those functions. > + This influences both the tracers "function" and "function_graph"! I know you probably were a bit upset about the documentation not emphasizing that this affects function_graph, but there's no reason to have an exclamation point at the end of that statement. It states that it affects what functions are traced without mentioning tracers. The assumption was that any "function type" tracing will be affected by it. Which is no longer true, because stack tracer has its own filter files. We should also mention that function profiling is affected by that too. > > The functions listed in "available_filter_functions" are what > can be written into this file. > @@ -265,6 +266,9 @@ of ftrace. Here is a list of some of the key files: > Functions listed in this file will cause the function graph > tracer to only trace these functions and the functions that > they call. (See the section "dynamic ftrace" for more details). > + With dynamic ftrace, the graph tracer can only trace functions that > + set_ftrace_filter minus set_ftrace_notrace armed; this also influences > + the ability to chase function call chains. Again, the above seems a bit emotional ;-) Just something like this: Note, set_ftrace_filter and set_ftrace_notrace still affects what functions are being traced. > >set_graph_notrace: > > @@ -277,7 +281,8 @@ of ftrace. Here is a list of some of the key files: > > This lists the functions that ftrace has processed and can trace. > These are the function names that you can pass to > - "set_ftrace_filter" or "set_ftrace_notrace". > + "set_ftrace_filter", "set_ftrace_notrace", > + "set_graph_function", or "set_graph_notrace". > (See the section "dynamic ftrace" below for more details.) This part is fine. -- Steve -- Steve > >dyn_ftrace_total_info: -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8
James,
Thanks for this mail.
On 2018/4/13 0:14, James Morse wrote:
> Hi gengdongjiu,
>
> On 12/04/18 06:00, gengdongjiu wrote:
>> 2018-02-16 1:55 GMT+08:00 James Morse :
>>> On 05/02/18 11:24, gengdongjiu wrote:
> Is the emulated SError routed following the routing rules for
> HCR_EL2.{AMO,
> TGE}?
Yes, it is.
>>>
>>> ... and yet ...
>>>
>>>
> What does your firmware do when it wants to emulate SError but its masked?
> (e.g.1: The physical-SError interrupted EL2 and the SPSR shows EL2 had
> PSTATE.A set.
> e.g.2: The physical-SError interrupted EL2 but HCR_EL2 indicates the
> emulated SError should go to EL1. This effectively masks SError.)
Currently we does not consider much about the mask status(SPSR).
>>>
>>> .. this is a problem.
>>>
>>> If you ignore SPSR_EL3 you may deliver an SError to EL1 when the exception
>>> interrupted EL2. Even if you setup the EL1 register correctly, EL1 can't
>>> eret to
>>> EL2. This should never happen, SError is effectively masked if you are
>>> running
>>> at an EL higher than the one its routed to.
>>>
>>> More obviously: if the exception came from the EL that SError should be
>>> routed
>>> to, but PSTATE.A was set, you can't deliver SError. Masking SError is the
>>> only
>
>> James, I summarized the masking and routing rules for SError to
>> confirm with you for the firmware first solution,
>
> You also said "Currently we does not consider much about the mask
> status(SPSR)."
Yes, we currently do not consider much it. After clarification with you, we
want to modify the EL3 firmware to follow this rule.
>
>
>> 1. If the HCR_EL2.{AMO,TGE} is set,
>
> If one or the other of these bits is set: (AMO==1 || TGE==1)
>
>> which means the SError should route to EL2,
>> When system happens SError and trap to EL3, If EL3 find
>> HCR_EL2.{AMO,TGE} and SPSR_EL3.A are both set,
>> and find this SError come from EL2, it will not deliver an SError:
>> store the RAS error in the BERT and 'reboot'; but if
>> it find that this SError come from EL1 or EL0, it also need to deliver
>> an SError, right?
>
> Yes.
>
>
>> 2. If the HCR_EL2.{AMO,TGE} is not set,
>
> If neither of these bits is set: (AMO==0 && TGE == 0)
>
>> which means the SError should route to EL1,
>> When system happens SError and trap to EL3, If EL3 find
>> HCR_EL2.{AMO,TGE} and SPSR_EL3.A are both not set,
>
> (I'm reading this as all three of these bits are clear)
sorry, it is a typo issue.
it should be HCR_EL2.AMO and HCR_EL2.TGE are both clear, but SPSR_EL3.A is set.
>
>> and find this SError come from EL1, it will not deliver an SError:
>> store the RAS error in the BERT and 'reboot';
>
> No, (AMO==0 && TGE == 0) means SError is routed to EL1, this exception
> interrupted EL1 and the A bit was clear, so EL1 can take an SError.
Agree.
>
> The two cases here are:
> AMO==0,TGE==0 means SError should be routed to EL1. If SPSR_EL3 says the
> exception interrupted EL1 and the A bit was set, you need to do the BERT
> trick.
>
> If SPSR_EL3 says the exception interrupted EL2, you need to do the BERT trick
"BERT trick" is storing the RAS error in the BERT and 'reboot, right?
> regardless of the A bit, as SError is implicitly masked by running at a higher
> exception level than it was routed to.
>
>
>>From your v11 reply:
>> 2. The exception came from the EL that SError should not be routed
>> to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3
>> firmware still deliver SError
>
> (this is re-iterating the two-cases above:)
> 'not be routed to' is one of two things: Route-to-EL2+interruted-EL1, or
> Route-to-EL1+interrupted-EL2.
>
> Route-to-EL2+interrupted-EL1 is fine, regardless of SPSR_EL3.A the emulated
> SError can be delivered to EL2, as EL2 can't mask SError when executing at a
> lower EL.
Agree.
>
> Route-to-EL1+interrupted-EL2 is the problem. SError is implicitly masked by
> running at a higher EL. Regardless of SPSR_EL3.A, the emulated SError can not
> be
> delivered.
"can not be delivered" means storing the RAS error in the BERT and 'reboot,
right?
In the Table D1-15 in "D1.14.2 Asynchronous exception masking", for the case,
it is "C"
"C"means SError is not taken regardless of the value of the Process state
interrupt mask.
for this case, whether it will be unsafe if BIOS directly reboot?
> KVM does this on the way out of a guest, if an SError occurs during this time
> the CPU will wait until execution returns to EL1 before delivering the SError.
> Your firmware has to do the same.
>
> Table D1-15 in "D1.14.2 Asynchronous exception masking" has a table with all
> the
> combinations. The ARM-ARM is what we need to match with this behaviour.
>
>
>> but if it find that this SError come from EL0, it also need to deliver an
>> SError, right?
>
> I thought interrupted-EL0 could always be delivered: but re-reading the
> ARM-ARM's "D1.14.2 Asynchronous exception masking", if asynchronous excepti
Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.
Hi Wolfram, Sam, On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: > On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: > > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* > > helper routines as static inlined functions provided by linux/i2c-dev.h. > > Work > > has been done to refactor the linux/i2c-dev.h file in the i2c-tools project > > out into its own library. As a result, these docs have become stale. > > Thanks for fixing this! > > > This patch corrects the discrepancy and directs the reader to the i2c-tools > > project for more information. Additionally, some trailing-whitespace > > cleanups > > were made. > > Minor nit: Having the whitespace changes in a seperate patch is a tad > easier to review. > > > - /* Using I2C Write, equivalent of > > + /* Using I2C Write, equivalent of > > i2c_smbus_write_word_data(file, reg, 0x6543) */ > > Maybe change to Kernel coding style comments while here? > > > - Not meant to be called directly; instead, use the access functions > > - below. > > + If possible, use the provided i2c_smbus_* methods described below in > > favor > > + of issuing direct ioctls. > > Why this change? I'm also not sure if "in favor of" is right. "instead of" would sound better to me, but I'm no native English speaker, I could be wrong. > > -The above functions are all inline functions, that resolve to calls to > > -the i2c_smbus_access function, that on its turn calls a specific ioctl > > -with the data in a specific format. Read the source code if you > > -want to know what happens behind the screens. > > +The above functions are made available by linking against the libi2c > > library, > > +which is provided by the i2c-tools project. See: > > +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/. > > This is fine with me. Maybe Jean has a comment on this? Fixing the documentation is always welcome, thanks Sam for stepping in. However we really want separate patches for whitespace fixes and actual contents change, as Wolfram already mentioned above. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: ftrace: clarify filters with dynamic ftrace and graph
I fell into the trap of having set up function tracer with a very limited filter and then switched over to function_graph and was erroneously wondering why the latter did not trace what I expected, which was the full unabridged graph recursion. Signed-off-by: Steffen Maier Cc: Steven Rostedt Cc: Ingo Molnar Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/trace/ftrace.rst | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index e45f0786f3f9..68835d062344 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -224,6 +224,7 @@ of ftrace. Here is a list of some of the key files: has a side effect of enabling or disabling specific functions to be traced. Echoing names of functions into this file will limit the trace to only those functions. + This influences both the tracers "function" and "function_graph"! The functions listed in "available_filter_functions" are what can be written into this file. @@ -265,6 +266,9 @@ of ftrace. Here is a list of some of the key files: Functions listed in this file will cause the function graph tracer to only trace these functions and the functions that they call. (See the section "dynamic ftrace" for more details). + With dynamic ftrace, the graph tracer can only trace functions that + set_ftrace_filter minus set_ftrace_notrace armed; this also influences + the ability to chase function call chains. set_graph_notrace: @@ -277,7 +281,8 @@ of ftrace. Here is a list of some of the key files: This lists the functions that ftrace has processed and can trace. These are the function names that you can pass to - "set_ftrace_filter" or "set_ftrace_notrace". + "set_ftrace_filter", "set_ftrace_notrace", + "set_graph_function", or "set_graph_notrace". (See the section "dynamic ftrace" below for more details.) dyn_ftrace_total_info: -- 2.13.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
