> On 02.12.2015, at 14:32, Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Wed, Dec 02, 2015 at 02:04:24PM +0100, Martin Sperl wrote: > >> The bigger question (based on your comments to Patch 2/3) is: > > I haven't even looked at your reply ot that yet. > >> Do you want to follow the devres approach (i.e: hiding >> "struct spi_res" after allocation and returning "void *" >> to the data-payload only in spi_res_alloc)? > >> Or do you prefer to have "struct spi_res" as an explicit member of >> a structure (i.e. in Patch 2/3 "struct spi_res_replaced_transfers")? > > I wasn't aware that was an issue? Here the section from your reply to the other patch I am referring to: > On 01.12.2015, at 22:29, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> >> +/* the spi_resource structure used */ >> +struct spi_res_replaced_transfers { >> + spi_res_release_t release; >> + struct list_head replaced_transfers; >> + int inserted; >> + struct spi_transfer xfers[]; >> +}; > > This quite clearly isn't a struct spi_resource, nor does it contain > one… As said: it could also get written as: +/* the spi_resource structure used */ +struct spi_res_replaced_transfers { + struct spi_res resource; + spi_res_release_t release; + struct list_head replaced_transfers; + int inserted; + struct spi_transfer xfers[]; +}; But we loose the ability to just allocate memory the way we use devm_kmalloc. Martin-- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html