lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 May 2019 05:55:07 +0000
From:   Joel Stanley <joel@....id.au>
To:     Vijay Khemka <vijaykhemka@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andrew Jeffery <andrew@...id.au>, Arnd Bergmann <arnd@...db.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "openbmc @ lists . ozlabs . org" <openbmc@...ts.ozlabs.org>
Subject: Re: [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional

On Fri, 18 Jan 2019 at 20:12, Vijay Khemka <vijaykhemka@...com> wrote:
>
> Hi Andrew,
> Thanks for this review, I will have a follow up patch for this return values.

Did you send a follow up patch to fix the return values?

Greg, is there any reason why you did not merge this one? 5.2 will
have device trees that depend on this patch's behavior.

Cheers,

Joel

> On 1/17/19, 8:58 PM, "Andrew Jeffery" <andrew@...id.au> wrote:
>
>     Hi Vijay,
>
>     Thanks for doing the work to fix the driver. Some minor queries/points
>     below.
>
>     On Thu, 17 Jan 2019, at 08:31, Vijay Khemka wrote:
>     > Makiing memory-region and flash as optional parameter in device
>     > tree if user needs to use these parameter through ioctl then
>     > need to define in devicetree.
>     >
>     > Signed-off-by: Vijay Khemka <vijaykhemka@...com>
>     > ---
>     >  drivers/misc/aspeed-lpc-ctrl.c | 58 +++++++++++++++++++++-------------
>     >  1 file changed, 36 insertions(+), 22 deletions(-)
>     >
>     > diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-
>     > ctrl.c
>     > index a024f8042259..332210e06e98 100644
>     > --- a/drivers/misc/aspeed-lpc-ctrl.c
>     > +++ b/drivers/misc/aspeed-lpc-ctrl.c
>     > @@ -68,6 +68,7 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
>     > unsigned int cmd,
>     >           unsigned long param)
>     >  {
>     >   struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
>     > + struct device *dev = file->private_data;
>     >   void __user *p = (void __user *)param;
>     >   struct aspeed_lpc_ctrl_mapping map;
>     >   u32 addr;
>     > @@ -90,6 +91,12 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
>     > unsigned int cmd,
>     >           if (map.window_id != 0)
>     >                   return -EINVAL;
>     >
>     > +         /* If memory-region is not described in device tree */
>     > +         if (!lpc_ctrl->mem_size) {
>     > +                 dev_err(dev, "Didn't find reserved memory\n");
>     > +                 return -EINVAL;
>
>     I feel like EINVAL isn't quite right - it's pretty generic, and the parameter
>     value changes its validity with the devicetree context. My gut instinct
>     would be to use EINVAL for parameter values that violate assumptions
>     of the driver rather than violate configuration of the driver. Maybe ENXIO
>     ("No such device or address") is an improvement: "I can't map that device
>     because there's no such device or address"?
>
>     > +         }
>     > +
>     >           map.size = lpc_ctrl->mem_size;
>     >
>     >           return copy_to_user(p, &map, sizeof(map)) ? -EFAULT : 0;
>     > @@ -126,9 +133,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file
>     > *file, unsigned int cmd,
>     >                   return -EINVAL;
>     >
>     >           if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
>     > +                 if (!lpc_ctrl->pnor_size) {
>     > +                         dev_err(dev, "Didn't find host pnor flash\n");
>     > +                         return -EINVAL;
>
>     See the error code discussion above. Also, this is userspace's error not
>     the kernel's, so I think dev_err() is a bit harsh. Probably best to just let
>     userspace log the error if it thinks the it is concerning.
>
>     > +                 }
>     >                   addr = lpc_ctrl->pnor_base;
>     >                   size = lpc_ctrl->pnor_size;
>     >           } else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
>     > +                 /* If memory-region is not described in device tree */
>     > +                 if (!lpc_ctrl->mem_size) {
>     > +                         dev_err(dev, "Didn't find reserved memory\n");
>     > +                         return -EINVAL;
>
>     as above.
>
>     > +                 }
>     >                   addr = lpc_ctrl->mem_base;
>     >                   size = lpc_ctrl->mem_size;
>     >           } else {
>     > @@ -196,17 +212,17 @@ static int aspeed_lpc_ctrl_probe(struct
>     > platform_device *pdev)
>     >   if (!lpc_ctrl)
>     >           return -ENOMEM;
>     >
>     > + /* If flash is described in device tree then store */
>     >   node = of_parse_phandle(dev->of_node, "flash", 0);
>     >   if (!node) {
>     > -         dev_err(dev, "Didn't find host pnor flash node\n");
>     > -         return -ENODEV;
>     > - }
>     > -
>     > - rc = of_address_to_resource(node, 1, &resm);
>     > - of_node_put(node);
>     > - if (rc) {
>     > -         dev_err(dev, "Couldn't address to resource for flash\n");
>     > -         return rc;
>     > +         dev_dbg(dev, "Didn't find host pnor flash node\n");
>     > + } else {
>     > +         rc = of_address_to_resource(node, 1, &resm);
>     > +         of_node_put(node);
>     > +         if (rc) {
>     > +                 dev_err(dev, "Couldn't address to resource for flash\n");
>     > +                 return rc;
>     > +         }
>     >   }
>     >
>     >   lpc_ctrl->pnor_size = resource_size(&resm);
>     > @@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct
>     > platform_device *pdev)
>     >
>     >   dev_set_drvdata(&pdev->dev, lpc_ctrl);
>     >
>     > + /* If memory-region is described in device tree then store */
>     >   node = of_parse_phandle(dev->of_node, "memory-region", 0);
>     >   if (!node) {
>     > -         dev_err(dev, "Didn't find reserved memory\n");
>     > -         return -EINVAL;
>     > - }
>     > +         dev_dbg(dev, "Didn't find reserved memory\n");
>     > + } else {
>     > +         rc = of_address_to_resource(node, 0, &resm);
>     > +         of_node_put(node);
>     > +         if (rc) {
>     > +                 dev_err(dev, "Couldn't address to resource for reserved memory\n");
>     > +                 return -ENOMEM;
>
>     Wow, I think this is an abuse of ENOMEM. Its description is "Out of memory"
>     which doesn't really reflect the problem here.
>
>     Not really your fault though, maybe we'll fix that with some follow-up patches.
>
>     Cheers,
>
>     Andrew
>
>     > +         }
>     >
>     > - rc = of_address_to_resource(node, 0, &resm);
>     > - of_node_put(node);
>     > - if (rc) {
>     > -         dev_err(dev, "Couldn't address to resource for reserved memory\n");
>     > -         return -ENOMEM;
>     > +         lpc_ctrl->mem_size = resource_size(&resm);
>     > +         lpc_ctrl->mem_base = resm.start;
>     >   }
>     >
>     > - lpc_ctrl->mem_size = resource_size(&resm);
>     > - lpc_ctrl->mem_base = resm.start;
>     > -
>     >   lpc_ctrl->regmap = syscon_node_to_regmap(
>     >                   pdev->dev.parent->of_node);
>     >   if (IS_ERR(lpc_ctrl->regmap)) {
>     > @@ -258,8 +274,6 @@ static int aspeed_lpc_ctrl_probe(struct
>     > platform_device *pdev)
>     >           goto err;
>     >   }
>     >
>     > - dev_info(dev, "Loaded at %pr\n", &resm);
>     > -
>     >   return 0;
>     >
>     >  err:
>     > --
>     > 2.17.1
>     >
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ