On Sun, 8 Nov 2020 23:38:10 +0100 Tobias Waldekranz wrote: > On the 6352, doing a VTU GetNext op, followed by an STU GetNext op > will leave you with both the member- and state- data in the VTU/STU > data registers. But on the 6097 (which uses the same implementation), > the STU GetNext will override the information gathered from the VTU > GetNext. > > Separate the two stages, parsing the result of the VTU GetNext before > doing the STU GetNext. > > We opt to update the existing implementation for all applicable chips, > as opposed to creating a separate callback for 6097. Though the > previous implementation did work for (at least) 6352, the datasheet > does not mention the masking behavior. > > Signed-off-by: Tobias Waldekranz <tob...@waldekranz.com> > --- > > I was not sure if I should have created a separate callback, but I > have not found any documentation that suggests that you can expect the > STU GetNext op to mask the bits that are used to store VTU membership > information in the way that 6352 does. So depending on undocumented > behavior felt like something we would want to get rid of anyway. > > Tested on 6097F and 6352.
I'm unclear what this fixes. What functionality is broken on 6097? Can we identify the commit for a fixes tag?
