On Mon, Aug 01, 2022 at 05:24:02PM +0530, Viresh Kumar wrote: > On 27-07-22, 10:58, Kent Gibson wrote: > > > diff --git a/bindings/rust/tests/line_request.rs b/bindings/rust/tests/line_request.rs > > > + #[test] > > > + fn set_bias() { > > > + let offsets = [3]; > > > + let mut config = TestConfig::new(NGPIO).unwrap(); > > > + config.rconfig(Some(&offsets)); > > > + config.lconfig(Some(Direction::Input), None, None, None, Some(Bias::PullUp)); > > > + config.request_lines().unwrap(); > > > + config.request(); > > > + > > > + // Set single value > > > + assert_eq!(config.sim().val(3).unwrap(), GPIOSIM_VALUE_ACTIVE); > > > + } > > > + } > > > > Test reconfigure() failure modes. > > What are we specifically looking to test here ? I am not sure I understood which > failures modes I should target. > reconfigure() can return E2BIG if the configuration is too complex to encode into uAPI structures. There are only 10 attribute slots in the uAPI config, so more than 11 lines with distinct configs can't be encoded. You want to test that you propagate that error correctly. I typically test this by giving each line a different debounce value. > > Test you can reconfigure all values for all attributes (not all values > > for debounce obviously - just the flags). > > This I have done now, with request.reconfigure_lines(). > > > Similarly for request_lines (ideally in chip.rs) > > Isn't this same as the above one? I am not sure again what I should test here. > The request_lines() could be considered sufficient to test the conversions for both request_config and line_config objects. But testing request_lines() and reconfigure_lines() doesn't just test those conversions, it checks that the functions don't mess with the config along the way. If you want to take that as a given then sure, just testing the config variants for request_lines() will do. Cheers, Kent. > I have pushed my current changes here, if it helps: > > git@xxxxxxxxxx:vireshk/libgpiod.git master > > -- > viresh