Shankari02 <shankari.ak0208@xxxxxxxxx> writes: > This patch improves few sentences by correcting their grammatical formation. Some code functions have been highlighted for better readability. Please wrap your text to less than 80 columns Some maintainers react strongly to the "this patch" phrasing; better to use the imperative tense as described in Documentation/process/submitting-patches.rst. > Signed-off-by: Shankari <shankari.ak0208@xxxxxxxxx> Please include your full name in the signoff > --- > Documentation/driver-api/fpga/fpga-mgr.rst | 26 +++++++++++----------- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst > index 8d2b79f696c1..a53775399bbd 100644 > --- a/Documentation/driver-api/fpga/fpga-mgr.rst > +++ b/Documentation/driver-api/fpga/fpga-mgr.rst > @@ -76,7 +76,7 @@ parameter syntax is the same, but the call to ``fpga_mgr_unregister()`` should b > removed. In the above example, the ``socfpga_fpga_remove()`` function would not be > required. > > -The ops will implement whatever device specific register writes are needed to > +The ops will implement whatever device-specific register writes are needed to > do the programming sequence for this particular FPGA. These ops return 0 for > success or negative error codes otherwise. > > @@ -86,34 +86,34 @@ The programming sequence is:: > 3. .write or .write_sg (may be called once or multiple times) > 4. .write_complete > > -The .parse_header function will set header_size and data_size to > +The **.parse_header** function will set header_size and data_size to All of this extra markup does not help, I would not do that. Functions are generally marked using the function() convention instead. > struct fpga_image_info. Before parse_header call, header_size is initialized > with initial_header_size. If flag skip_header of fpga_manager_ops is true, > .write function will get image buffer starting at header_size offset from the > beginning. If data_size is set, .write function will get data_size bytes of > -the image buffer, otherwise .write will get data up to the end of image buffer. > -This will not affect .write_sg, .write_sg will still get whole image in > -sg_table form. If FPGA image is already mapped as a single contiguous buffer, > +the image buffer; otherwise .write will get data up to the end of image buffer. > +This will not affect .write_sg, .write_sg will still get the whole image in > +sg_table form. If FPGA image is already mapped as a single contiguous buffer, the > whole buffer will be passed into .parse_header. If image is in scatter-gather > form, core code will buffer up at least .initial_header_size before the first > -call of .parse_header, if it is not enough, .parse_header should set desired > -size into info->header_size and return -EAGAIN, then it will be called again > +call of .parse_header, if it is not enough, .parse_header should set the desired > +size into info->header_size and return ``-EAGAIN``, then it will be called again > with greater part of image buffer on the input. > > -The .write_init function will prepare the FPGA to receive the image data. The > +The **.write_init** function will prepare the FPGA to receive the image data. The > buffer passed into .write_init will be at least info->header_size bytes long; > if the whole bitstream is not immediately available then the core code will > buffer up at least this much before starting. > > -The .write function writes a buffer to the FPGA. The buffer may be contain the > +The **.write** function writes a buffer to the FPGA. The buffer may contain the > whole FPGA image or may be a smaller chunk of an FPGA image. In the latter > case, this function is called multiple times for successive chunks. This interface > is suitable for drivers which use PIO. > > -The .write_sg version behaves the same as .write except the input is a sg_table > -scatter list. This interface is suitable for drivers which use DMA. > +The **.write_sg** version behaves the same as .write except the input is a sg_table > +scatter list. This interface is suitable for drivers that use DMA. > > -The .write_complete function is called after all the image has been written > +The **.write_complete** function is called after all the image has been written > to put the FPGA into operating mode. > > The ops include a .state function which will determine the state the FPGA is in > @@ -126,7 +126,7 @@ API for implementing a new FPGA Manager driver > * ``fpga_mgr_states`` - Values for :c:expr:`fpga_manager->state`. > * struct fpga_manager - the FPGA manager struct > * struct fpga_manager_ops - Low level FPGA manager driver ops > -* struct fpga_manager_info - Parameter structure for fpga_mgr_register_full() > +* struct fpga_manager_info - Parameter structure for ``fpga_mgr_register_full()`` This extra markup will actively defeat the automatic markup we already have. > * __fpga_mgr_register_full() - Create and register an FPGA manager using the > fpga_mgr_info structure to provide the full flexibility of options > * __fpga_mgr_register() - Create and register an FPGA manager using standard > -- > 2.34.1 Thanks, jon
