On 2/25/2014 10:32 PM, Michal Nazarewicz wrote: > This reworks the way SuperSpeed descriptors are added and instead of > having a magick after full and high speed descriptors, it reworks the > whole descriptors block to include a flags field which lists which > descriptors are present and makes future extensions possible. > > Signed-off-by: Michal Nazarewicz <mina86@xxxxxxxxxx> > --- > Manu, if you could include it in your series, adjust your user space > client and test it, it would be wonderful. :] > I have tested this with my userspace client. It works fine. I checked both DESC_MAGIC and DESC_MAGIC_V2 with and without passing ss_descs. I faced one issue when I was using MAGIC_V2 and specified ss_count as 0. This resulted in driver treating ss_count as start of descs blob. Later noticed that this is now changed and depending on the flags (descriptors) passed, these fields may or may not be present. I see that you have explicitly mentioned the same in functionfs.h. This looks fine to me. Additionally, there were could of typos (mentioned below) which I have fixed in the patch. > > #define FUNCTIONFS_SS_DESC_MAGIC 0x0055DE5C can be removed. > + * | | fs_count | LE32 | number of full-speed descriptors | > + * | | hs_count | LE32 | number of high-speed descriptors | > + * | | ss_count | LE32 | number of high-speed descriptors | s/full/super > + * | | fs_descrs | Descriptor[] | list of full-speed descriptors | > + * | | hs_descrs | Descriptor[] | list of high-speed descriptors | > + * | | ss_descrs | Descriptor[] | list of high-speed descriptors | s/full/super > + * > + * Depending on which flags are set, various fields may be missing in the > + * structure. Any flags that are not recognised cause the whole block to be > + * rejected with -ENOSYS. This is what I was talking about. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
