| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20130906221425.GA10152@google.com>
Date: Fri, 6 Sep 2013 16:14:25 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Yijing Wang <wangyijing@...wei.com>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"James E.J. Bottomley" <JBottomley@...allels.com>,
Gavin Shan <shangw@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
Hanjun Guo <guohanjun@...wei.com>,
Jiang Liu <jiang.liu@...wei.com>,
Anil Gurumurthy <agurumur@...cade.com>,
Vijaya Mohan Guvva <vmohan@...cade.com>,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH v2 1/6] scsi/bfa: use pcie_set/get_readrq to simplify code
On Thu, Sep 05, 2013 at 03:55:25PM +0800, Yijing Wang wrote:
> v1->v2: use pcie_get/set_readrq to simplify code
> a lot suggestd by Bjorn.
>
> Use pcie_get_readrq()/pcie_set_readrq() to simplify
> code.
>
> Signed-off-by: Yijing Wang <wangyijing@...wei.com>
> Cc: Jiang Liu <jiang.liu@...wei.com>
> Cc: Anil Gurumurthy <agurumur@...cade.com>
> Cc: Vijaya Mohan Guvva <vmohan@...cade.com>
> Cc: "James E.J. Bottomley" <JBottomley@...allels.com>
> Cc: linux-scsi@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> ---
> drivers/scsi/bfa/bfad.c | 48 +++++-----------------------------------------
> 1 files changed, 6 insertions(+), 42 deletions(-)
I applied all these with some tweaks to my pci/yijing-pci_is_pcie-v2
branch [1]. This will be rebased after v3.12-rc1, and may be amended
if any patches are picked up by others.
Hints (not just for you; I hope other people pay attention, too,
because I'm obsessive and I pay attention to these details):
- Include a "[PATCH v2 0/6]" email. That's a good place for you to
put an overall description of the series, and a good place for
responses like this one that apply to the whole series.
- Pay attention to the order of your patches. Yours seemed random,
and I reordered them so the core PCI ones are first and the arch
and driver ones are later. That way I can easily drop the later
ones if they are picked up by other maintainers.
- Don't put "v1->v2" comments in your changelogs. Those are fine
in the "[0/6]" email, but they're useless in the git changelog, and
I strip them out when I see them. Or you can put them after the
"---" line, in which case they get stripped out automatically.
- Run "git log --oneline" on the files you touch. You should follow
the existing convention, including spacing, brackets, capitalization,
etc. I changed most of your subject lines for this reason.
- Write titles that are sentences, starting with a verb, as suggested
by Ingo [2]. You did this already; I just made changes for
consistency of capitalization and the like.
- Use real function names, not things like "pcie_capability_xxx".
That makes it easier to search logs.
- Be consistent about writing function names. Some of your logs
included, e.g., both "pci_bus_set_ops" and "dev_info()". I prefer
to always include the parentheses when writing a function name,
but at least be consistent.
- Don't put "Cc: <mailing-list>" in your changelog. That tag is
useful to show that a *person* has had the opportunity to comment
on a patch but declined to do so. I don't think it's meaningful
for mailing lists. If it were, every single commit would have
that tag, since every single commit should appear on the relevant
list. I suspect you probably do this so that something like
"git send-email --signed-off-by-cc" will automatically send mail
to the right lists. But that's a one-time convenience at the
cost of useless info in the changelog that's there forever.
- Put Signed-off-by, Acked-by, etc., tags in this order as suggested
by Ingo [2]:
Reported-by:
Tested-by:
Signed-off-by:
Acked-by:
Reviewed-by:
Cc: stable@...r.kernel.org # v3.11+
Cc: others
[1] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-pci_is_pcie-v2
[2] http://lkml.kernel.org/r/20120711080446.GA17713@gmail.com
> diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
> index f8ca7be..0a458db 100644
> --- a/drivers/scsi/bfa/bfad.c
> +++ b/drivers/scsi/bfa/bfad.c
> @@ -766,50 +766,14 @@ bfad_pci_init(struct pci_dev *pdev, struct bfad_s *bfad)
> bfad->pcidev = pdev;
>
> /* Adjust PCIe Maximum Read Request Size */
> - if (pcie_max_read_reqsz > 0) {
> - int pcie_cap_reg;
> - u16 pcie_dev_ctl;
> - u16 mask = 0xffff;
> -
> - switch (pcie_max_read_reqsz) {
> - case 128:
> - mask = 0x0;
> - break;
> - case 256:
> - mask = 0x1000;
> - break;
> - case 512:
> - mask = 0x2000;
> - break;
> - case 1024:
> - mask = 0x3000;
> - break;
> - case 2048:
> - mask = 0x4000;
> - break;
> - case 4096:
> - mask = 0x5000;
> - break;
> - default:
> - break;
> - }
> -
> - pcie_cap_reg = pci_find_capability(pdev, PCI_CAP_ID_EXP);
> - if (mask != 0xffff && pcie_cap_reg) {
> - pcie_cap_reg += 0x08;
> - pci_read_config_word(pdev, pcie_cap_reg, &pcie_dev_ctl);
> - if ((pcie_dev_ctl & 0x7000) != mask) {
> - printk(KERN_WARNING "BFA[%s]: "
> + if (pcie_max_read_reqsz > 0 && pci_is_pcie(pdev)) {
> + int max_rq = pcie_get_readrq(pdev);
> + if (max_rq > 128 && max_rq < 4096 && is_power_of_2(max_rq))
I think you meant to validate pcie_max_read_reqsz (the module parameter),
not max_rq. I made this change on my branch.
> + printk(KERN_WARNING "BFA[%s]: "
> "pcie_max_read_request_size is %d, "
> - "reset to %d\n", bfad->pci_name,
> - (1 << ((pcie_dev_ctl & 0x7000) >> 12)) << 7,
> + "reset to %d\n", bfad->pci_name, max_rq,
> pcie_max_read_reqsz);
> -
> - pcie_dev_ctl &= ~0x7000;
> - pci_write_config_word(pdev, pcie_cap_reg,
> - pcie_dev_ctl | mask);
> - }
> - }
> + pcie_set_readrq(pdev, pcie_max_read_reqsz);
> }
>
> pci_save_state(pdev);
> --
> 1.7.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists