From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80014182 for ; Fri, 16 May 2025 00:13:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747354417; cv=none; b=ZFc2qhL6gs2T/whLhWEHMaQQmFiuS5ltlaOaqH4A3+umWseYYb6VgB7sosGjG2KkvRta7aF+pbLf/mGSilKREUDVsVQCPNwFr0k1rJVoqxtt7eKZ7QdLlKuZUPa4Is9/ZwP4R2FDg8goaua7pPRQY0jyTkNnCPMCDnxSvHBoqdg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747354417; c=relaxed/simple; bh=CGG6jGXMIinSQ0YSIHvn85mnGlEINaaQlo/+CW6AhP8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z85JVTMBQCWSK+wT07cb4orW4WaFJH2Pq79EFSqt/XVPPVHjgniAxZh1lE3AvA2Hg5XaO+hrINdQpInEfzAQT+g+lWR+W584F+kTslE5XAef7yjB6ATRcv8nMYm868DLCkp6DYjc6AZfxtO7oqGG5LplUbE6DSAnwyffz8Pfwx0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=minyard.net; spf=none smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard-net.20230601.gappssmtp.com header.i=@minyard-net.20230601.gappssmtp.com header.b=zr+Kv/G6; arc=none smtp.client-ip=209.85.167.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard-net.20230601.gappssmtp.com header.i=@minyard-net.20230601.gappssmtp.com header.b="zr+Kv/G6" Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3f9a7cbc8f1so913682b6e.0 for ; Thu, 15 May 2025 17:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard-net.20230601.gappssmtp.com; s=20230601; t=1747354414; x=1747959214; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fIQzh+d2Cl2iQMRyzQRgpL9ZV/FSzUS9sLNvNDM8pQA=; b=zr+Kv/G66bomUjVB9BMYRkl+zLOivQXGGeXIqYvmNdCBEo9hKWw/noDqufHtofvwOA jgcA2ZX0jzCOF3HLcAwd9gR5fPA00TMjVWaqkecJcBT7WQsx/e+FDJUECJTlEDs47aF4 vFrOIIFsWvI+kkQi9wARHILMPt5OrYgSLTmRpWJHhL5iNm1j1rdFpANLo7S1FyP4gze7 9Q6k4mTLfLB1/9LhyTnckvHX2fRqPvnY7cJEWZ4enkzdtYyMLh/ufk7b8uNGGHvd7SwF TjrsqRZezNIs+gJI2YqqN5oWdMrPMKEGEWTT5Ap6/b9ZIKafmTppEQ9W9pe3dyqUqCj0 4DDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747354414; x=1747959214; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fIQzh+d2Cl2iQMRyzQRgpL9ZV/FSzUS9sLNvNDM8pQA=; b=WaTQDIGFa9e5Q57t86CKtisNxh/CiftNXx6CpogEItKg5cm5p2L47esujOE2FnoMC/ EAjlFFACpxip+MM7qcYMRvuRoGP1CcgUgX0ccnmj64ZRngsJLs5ItAVnvaZVn383Wn4z hn9OyYwpYo/XV+evxjtItXu0FVW47Lgu3K5FYC+Y1pdPNaRJCcOZq9+5JAuRxgLZgEF5 lyOFM4k+1YoTjo8/ZzSRgsPfU2Rb3CIsEyBagoCrPOdDxGigWV424LbGBNM4Ej5ASecE d7N7QOaxuCmzEgWmFgIN/3A6KaC8+Lh0njFph+XxDLppfLVNOEzNzcDOp94egq4H3NUM 9RoQ== X-Forwarded-Encrypted: i=1; AJvYcCWTB5YwBUYcTU8a2uXrDBlCdwSk9OX8zs8QElZ4HOXVC5Ov2Y0KRC4TMzi2jIWAMy+ejlyaOi3gw8+WE0HVGGio6ekp2g==@lists.linux.dev X-Gm-Message-State: AOJu0YyLrvQ73C4Coc3WhPZe3OjRXa4VZ0xwqFbDWD1ht5TEMMTUcrQb +KsQktrY02vaT+EBVkkuTCaZj+N2jYoRJbeOL67As0RwM1YS5ijC5U5f09jIGBa09DY= X-Gm-Gg: ASbGncvhgWFI2Ch1jApxZ7GPjx4lToqRDrZz5Bv1maMa7O0k6cGxMhv7ksgoEQkSnRC b2TQ/K5l+FcWGCSJlWrcb78xtUD8WLIClzvmIdtSBdzYtEfPTtR1/ZanUS1OM+9/WMfIbHRcICo iKCu8kBd9qj+iPQWgJ3ptn83Jcc/4Il14h5UPdwCt+bVIDQNZvtNLOYvmYz6VibsdLPqS+uzT+5 KAl+WLGfRLrNHREOsFOxRTzUGyAto4yq9464GqRWtoxBKBBTLxiEurohTyNomsAPJRfviqQ3hXT uzg4lMHR6DHF4vEhGIZk8m+B2llv3Bp3bv2Te48N38DQhkqCJhRCl9M= X-Google-Smtp-Source: AGHT+IHw+xOETWTyOT89ZTuJ4/7y2Jcun/+WyMsgKHv9WFHVKeTtE/CECud8o+oMJFlD/SDqIiuTug== X-Received: by 2002:a05:6808:338c:b0:3f9:2fdc:ee93 with SMTP id 5614622812f47-404d87b897dmr1274677b6e.30.1747354414372; Thu, 15 May 2025 17:13:34 -0700 (PDT) Received: from mail.minyard.net ([2001:470:b8f6:1b:d0c5:1ce0:9035:258c]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-609f2f43884sm188602eaf.15.2025.05.15.17.13.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 May 2025 17:13:32 -0700 (PDT) Date: Thu, 15 May 2025 19:13:27 -0500 From: Corey Minyard To: Praveen Balakrishnan Cc: corbet@lwn.net, openipmi-developer@lists.sourceforge.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, linux-kernel-mentees@lists.linux.dev Subject: Re: [PATCH] docs: ipmi: fix spelling and grammar mistakes Message-ID: Reply-To: corey@minyard.net References: <20250515234757.19710-1-praveen.balakrishnan@magd.ox.ac.uk> Precedence: bulk X-Mailing-List: linux-kernel-mentees@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250515234757.19710-1-praveen.balakrishnan@magd.ox.ac.uk> On Fri, May 16, 2025 at 12:47:57AM +0100, Praveen Balakrishnan wrote: > Corrected various spelling and grammatical mistakes in > Documentation/driver-api/ipmi.rst to improve readability. > > No changes to the technical content has been made. Thank you, I have added this to my tree. -corey > > Signed-off-by: Praveen Balakrishnan > --- > Documentation/driver-api/ipmi.rst | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst > index dfa021eacd63..d9fb2376e8da 100644 > --- a/Documentation/driver-api/ipmi.rst > +++ b/Documentation/driver-api/ipmi.rst > @@ -45,7 +45,7 @@ manual), choose the 'IPMI SI handler' option. A driver also exists > for direct I2C access to the IPMI management controller. Some boards > support this, but it is unknown if it will work on every board. For > this, choose 'IPMI SMBus handler', but be ready to try to do some > -figuring to see if it will work on your system if the SMBIOS/APCI > +figuring to see if it will work on your system if the SMBIOS/ACPI > information is wrong or not present. It is fairly safe to have both > these enabled and let the drivers auto-detect what is present. > > @@ -63,7 +63,7 @@ situation, you need to read the section below named 'The SI Driver' or > IPMI defines a standard watchdog timer. You can enable this with the > 'IPMI Watchdog Timer' config option. If you compile the driver into > the kernel, then via a kernel command-line option you can have the > -watchdog timer start as soon as it initializes. It also have a lot > +watchdog timer start as soon as it initializes. It also has a lot > of other options, see the 'Watchdog' section below for more details. > Note that you can also have the watchdog continue to run if it is > closed (by default it is disabled on close). Go into the 'Watchdog > @@ -317,13 +317,13 @@ This gives the receiver a place to actually put the message. > > If the message cannot fit into the data you provide, you will get an > EMSGSIZE error and the driver will leave the data in the receive > -queue. If you want to get it and have it truncate the message, us > +queue. If you want to get it and have it truncate the message, use > the IPMICTL_RECEIVE_MSG_TRUNC ioctl. > > When you send a command (which is defined by the lowest-order bit of > the netfn per the IPMI spec) on the IPMB bus, the driver will > automatically assign the sequence number to the command and save the > -command. If the response is not receive in the IPMI-specified 5 > +command. If the response is not received in the IPMI-specified 5 > seconds, it will generate a response automatically saying the command > timed out. If an unsolicited response comes in (if it was after 5 > seconds, for instance), that response will be ignored. > @@ -367,7 +367,7 @@ channel bitmasks do not overlap. > > To respond to a received command, set the response bit in the returned > netfn, use the address from the received message, and use the same > -msgid that you got in the receive message. > +msgid that you got in the received message. > > From userland, equivalent IOCTLs are provided to do these functions. > > @@ -440,7 +440,7 @@ register would be 0xca6. This defaults to 1. > > The regsizes parameter gives the size of a register, in bytes. The > data used by IPMI is 8-bits wide, but it may be inside a larger > -register. This parameter allows the read and write type to specified. > +register. This parameter allows the read and write type to be specified. > It may be 1, 2, 4, or 8. The default is 1. > > Since the register size may be larger than 32 bits, the IPMI data may not > @@ -481,8 +481,8 @@ If your IPMI interface does not support interrupts and is a KCS or > SMIC interface, the IPMI driver will start a kernel thread for the > interface to help speed things up. This is a low-priority kernel > thread that constantly polls the IPMI driver while an IPMI operation > -is in progress. The force_kipmid module parameter will all the user to > -force this thread on or off. If you force it off and don't have > +is in progress. The force_kipmid module parameter will allow the user > +to force this thread on or off. If you force it off and don't have > interrupts, the driver will run VERY slowly. Don't blame me, > these interfaces suck. > > @@ -583,7 +583,7 @@ kernel command line as:: > These are the same options as on the module command line. > > The I2C driver does not support non-blocking access or polling, so > -this driver cannod to IPMI panic events, extend the watchdog at panic > +this driver cannot do IPMI panic events, extend the watchdog at panic > time, or other panic-related IPMI functions without special kernel > patches and driver modifications. You can get those at the openipmi > web page. > @@ -610,7 +610,7 @@ Parameters are:: > ipmi_ipmb.retry_time_ms=