Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1543144
| From | Stuart Yoder <stuart.yoder@nxp.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [PATCH v3 3/9] bus: fsl-mc: dpio: add APIs for DPIO objects |
| Date | 2016-12-16 01:20 +0100 |
| Message-ID | <sOOpH-4ik-1@gated-at.bofh.it> (permalink) |
| References | <sJVBw-3XH-23@gated-at.bofh.it> <sK0rw-7f6-17@gated-at.bofh.it> <sK0rv-7f6-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> > +#define DPIO_CMD(id) ((id << DPIO_CMD_ID_OFFSET) | DPIO_CMD_BASE_VERSION) > > Paranthesis around 'id'? In all cases these are opcode values and will never be an expression. If we really need to future proof these definitions, we should do it for all objects not just DPIO. I'd like to see consistency across objects and don't want to see DPIO gratuitously diverge. So, my suggestion is to have an offline discussion and if we think the change is needed, submit a patch for all objects currently supported. > > + /* prepare command */ > > + cmd.header = mc_encode_cmd_header(DPIO_CMDID_OPEN, > > + cmd_flags, > > + 0); > > + dpio_cmd = (struct dpio_cmd_open *)cmd.params; > > + dpio_cmd->dpio_id = cpu_to_le32(dpio_id); > > + > > + /* send command to mc*/ > > + err = mc_send_command(mc_io, &cmd); > > + if (err) > > + return err; > > + > > + /* retrieve response parameters */ > > + *token = mc_cmd_hdr_read_token(&cmd); > > Nit: maybe we should drop these repetitive "prepare / send / retrieve" comments > as the code is pretty self explanatory. The 'send' comment certainly isn't needed given that the function is 'mc_send_command()'. For the others, I think having some comment is helpful, even though a bit repetitive. Stuart
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
RE: [PATCH v3 3/9] bus: fsl-mc: dpio: add APIs for DPIO objects Stuart Yoder <stuart.yoder@nxp.com> - 2016-12-16 01:20 +0100
csiph-web