Message ID | 20200820171020.5df4683b@xhacker.debian |
---|---|
Headers | show |
Series | regulator: mp886x: two features and dt json convert | expand |
On Thu, Aug 20, 2020 at 05:10:51PM +0800, Jisheng Zhang wrote: > Implement the .set_ramp_delay for MP8867 and MP8869. MP8867 and MP8869 > could share the implementation, the only difference is the slew_rates > array. This doesn't apply against current code, please check and resend.
On Thu, 20 Aug 2020 22:05:13 +0100 Mark Brown wrote: > On Thu, Aug 20, 2020 at 05:10:51PM +0800, Jisheng Zhang wrote: > > Implement the .set_ramp_delay for MP8867 and MP8869. MP8867 and MP8869 > > could share the implementation, the only difference is the slew_rates > > array. > > This doesn't apply against current code, please check and resend. I found the reason, the three patches in v2 were applied to for-next tree. Should I renew patches based on for-next? Since the "mps,switch-frequency" binding isn't released and used, I think I can send new patches to convert mps,switch-frequency to mps,switch-frequency-hz. Thanks
On Fri, Aug 21, 2020 at 10:17:29AM +0800, Jisheng Zhang wrote: > I found the reason, the three patches in v2 were applied to for-next tree. > Should I renew patches based on for-next? Since the "mps,switch-frequency" > binding isn't released and used, I think I can send new patches to convert > mps,switch-frequency to mps,switch-frequency-hz. Yes, please - for-next is best for anything that isn't a bug fix.