Re: [PATCH 1/2] x86/amd_nb: Add PCI device IDs for family 17h, model 71h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 19, 2019 at 06:30:56PM +0300, Marcel Bocu wrote:
> On 19/07/2019 16:27, Guenter Roeck wrote:
> > Hi Marcel,
> > 
> > On 7/19/19 12:40 AM, Marcel Bocu wrote:
> >> On 18/07/2019 22:33, Guenter Roeck wrote:
> >>> On Thu, Jul 18, 2019 at 09:26:16PM +0300, Marcel Bocu wrote:
> >>>> The AMD Ryzen gen 3 processors came with a different PCI IDs for the
> >>>> function 3 & 4 which are used to access the SMN interface. The root
> >>>> PCI address however remained at the same address as the model 30h.
> >>>>
> >>>> Adding the F3/F4 PCI IDs respectively to the misc and link ids appear
> >>>> to be sufficient for k10temp, so let's add them and follow up on the
> >>>> patch if other functions need more tweaking.
> >>>>
> >>>> Signed-off-by: Marcel Bocu <marcel.p.bocu@xxxxxxxxx>
> >>>> Tested-by: Marcel Bocu <marcel.p.bocu@xxxxxxxxx>
> >>>>
> >>>
> >>> How is this version of the patch series different to the first version ?
> >>
> >> They seem pretty much identical except for the macro's name (71h vs 70h)
> > 
> > Normally (or at least so far) the device ID specifications are for a group
> > of models, not just for one chip in the group. Traditionally, AMD uses the
> > same PCI ID for model numbers 7xh, so 70h would probably be more appropriate.
> > Of course, that is hard to say without documentation from AMD, and I don't
> > see anything published for Ryzen 3000.
> 
> Makes sense. Thanks for giving me some historical background!
> 
> > 
> >> and the fact that I already Cc:ed the x86 crew. I had checked this
> >> weekend if there were patches already for this, but I guess Vicki sent
> >> his patches right after I checked. Sorry for the noise!
> >>
> >> Could anyone add Vicki Pfau (I don't have his email address because I
> >> subscribed to this list after he sent his patches), and then we can ask
> >> him if he already submited his patches to x86 or not.
> >>
> >> In any case, whatever patchset gets selected for inclusion, I suggest we
> >> both sign off on the commit (I do not care about authorship). I will
> >> anyway try to follow up with other patches to access the chipset's
> >> temperature and the fan speed.
> >>
> > 
> > Wouldn't that require patches to the Super-IO chip on your board ?
> > That seems orthogonal to this patch series (and to the R3000 CPU).
> 
> Yes, but what I meant is that I don't mind not having authorship on
> these patches since most of my work will be on adding new features.
> Sorry for not being clear.
> 
> > 
> >> Sorry again for the noise!
> > 
> > Sorry myself, I didn't realize that the patches were from different people
> > since they looked similar.
> 
> I can't blame you for that! Could anyone in this thread add Vicki Pfau
> to figure out what's the best course of action?
> 
Copied. Can the two of you sort this out ?

Note that Vicki's patch series is in patchwork:
	https://patchwork.kernel.org/patch/11043277/
	https://patchwork.kernel.org/patch/11043271/

> We could merge his patches (if he contacted the x86 crew), make a v2 of
> mine (71h -> 70h, add his Signed-off-by?) and merge, or some other option?
> 
Either case, we'll need feedback from x86 maintainers. They are not exactly
happy if anyone pushes a patch into arch/x86 without their approval.

Guenter

> Marcel
> 
> > 
> > Guenter
> > 
> 



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux