[bug report] i2c: break out ACPI support into separate file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello i2c devs,

This code generatates the following static checker warning:

	drivers/i2c/i2c-core-acpi.c:615 i2c_acpi_space_handler()
	warn: assigning signed to unsigned: 'gsb->status = status' 's32min-s32max'

drivers/i2c/i2c-core-acpi.c
   584          case ACPI_GSB_ACCESS_ATTRIB_BLOCK:
   585                  if (action == ACPI_READ) {
   586                          status = i2c_smbus_read_block_data(client, command,
   587                                          gsb->data);
   588                          if (status >= 0) {
   589                                  gsb->len = status;
   590                                  status = 0;
   591                          }
   592                  } else {
   593                          status = i2c_smbus_write_block_data(client, command,
   594                                          gsb->len, gsb->data);
   595                  }
   596                  break;
   597  
   598          case ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE:
   599                  if (action == ACPI_READ) {
   600                          status = acpi_gsb_i2c_read_bytes(client, command,
   601                                          gsb->data, info->access_length);
   602                  } else {
   603                          status = acpi_gsb_i2c_write_bytes(client, command,
   604                                          gsb->data, info->access_length);
   605                  }
   606                  break;
   607  
   608          default:
   609                  dev_warn(&adapter->dev, "protocol 0x%02x not supported for client 0x%02x\n",
   610                           accessor_type, client->addr);
   611                  ret = AE_BAD_PARAMETER;
   612                  goto err;
   613          }
   614  
   615          gsb->status = status;
                ^^^^^^^^^^^^^^^^^^^^
Status can be a negative error code, and we're saving it to a u8.  I
think returning success is intended on this path, so that's probably
fine.

   616  
   617   err:
   618          kfree(client);
   619          ACPI_FREE(ares);
   620          return ret;
   621  }

regards,
dan carpenter



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux